One client can never read another's file.

Intake, scheduling, session notes — built from a plain-language description, and held until the database proves each client's records stay sealed.

A crossed record in a small practice is a board complaint. The inspection here treats it that way.

Isolation lives in the database.

Your app's records live in a database provisioned for it alone; no other customer's data shares it. Inside it, every table that holds client records carries a row-level security policy — a rule the database applies to every query, whatever the app code above it does.

A gate called rls checks that the policy is present on every sensitive table, on every build. A missing policy stops the build right there.

A live attack, before every release.

A policy on paper proves little until something tries to get past it. So a second gate, rls-enforce, stands up a real database and seeds two separate clients. Signed in as the first, it tries to read the second client's notes; signed in as the second, it tries the first's. Both reads must come back empty.

One leaked row blocks the build. The full inspection line — all twelve gates — is on the trust page.

What a hold looks like.

When a gate fails, the build is held. It does not deploy, and there is no switch to make it. You see the findings in plain English, and from there you can run the fix loop again or change the request.

Because session notes classify as protected health information, the compliance gate adds its own requirements: sign-in in front of the records, and a working way to delete a client's file on request.

None of this makes your practice HIPAA-compliant, and we won't tell you it does — that determination belongs to your counsel. The gates handle the technical part and show their work.

The tools a practice runs on.

Most practices start with an intake form or a scheduler. Session notes usually come next. You describe the tool the way you'd say it out loud, and the same twelve gates inspect whatever gets built.