A FAILURE WITH NO ERROR
A feature in the practitioner dashboard stopped returning data. Notably, nothing failed. No console errors, no rejected requests, no exceptions. The page loaded, the query executed successfully, and the results were simply empty — as though the records did not exist.
The records existed. They were visible in the database, and the client-facing views returned them correctly. Only the practitioner's role received nothing.
That combination — data present, query succeeding, results empty, behavior varying by role — is the signature of a row-level security failure. Row-level security has a defining property: it fails silently by design. The database is not malfunctioning. It is doing precisely what it was instructed to do — declining to return rows for which the current role holds no policy.
WHERE AI-ASSISTED DEBUGGING PROVED ITSELF
What distinguished this session was the ability to present the entire problem at once: the failing query, the table schema, and every policy on the table — with a plain-language description of the symptom. The analysis came back in seconds: one policy verified ownership in a way that served clients reading their own rows, but provided no path granting the practitioner role access to rows owned by other users. Every comparable table carried that access policy. This one did not.
Policy review is a category of work where machine analysis outperforms manual reading. Each policy is a small logical expression; the defect lives in the gap between them — in what none of the policies cover. A person reads policies sequentially and holds the rest in memory. The model evaluates them as a single logical system and identifies the omission directly.
The accurate division of labor: AI located the defect faster than manual review would have. It could not determine what the correction should be — because the correction was not a syntax question. It was a security decision.
WHY THE FIX REMAINED A HUMAN DECISION
The expedient "fix" would have been to relax the policy until the query returned rows. In a platform holding client health information, that is how data exposure is engineered. The questions that determined the correct policy were ones no model had the authority to answer:
- Should the practitioner role access all client records in this table, or only clients under an active coaching relationship?
- Should access be granted through a broad role-based policy, or scoped narrowly to the relationship itself?
- Does the same omission exist on other tables — and which of those omissions are intentional?
Those answers derive from how the business operates, not from the codebase. The platform serves one practitioner today and may serve several tomorrow; the policy we wrote encodes a decision about the business's structure. No volume of context in a prompt contains that decision.
WHAT THIS CHANGED IN OUR STANDARDS
- Access policies are reviewed as a system, not individually. The defect existed in no single policy — it existed in what the set failed to state. Every table's policies are now evaluated together, and AI performs that review well.
- Silent failures have a defined diagnostic order. Empty results, no errors, role-dependent behavior: access control is examined first, not last. That single heuristic recovers hours.
- AI proposes; accountability remains human — most strictly at the security layer. Wherever access control is concerned, the model drafts and explains, and the engineer who understands the business approves. That is not a formality. It is the operating model.
Technology should expand human ability, not replace human judgment. Debugging at the security layer is where that principle stops being a statement and becomes a procedure.
The platform in question is documented in BN — 001. If you are building a system where access control carries real consequences, that is the work we do.