How It Stays True

For the compliance reviewer

Your real question isn’t “does it have an audit chain?”

It’s “how do I know the audit chain is still there, still keyed, still covering every table, after six months of feature work by people I’ll never meet?” Screenshots and a feature list can’t answer that. Executable, count-agnostic discipline can. Email Triage is a working reference implementation of that discipline — the same posture I bring when a research program retains me to own its technology.

1 · Structural pins

A build that fails when a control goes missing.

Every recurring defect class is answered in two moves: collapse the scattered sites onto a single source of truth, then add a structural pin — an ast.walk / repo-wide test that enforces the invariant across the whole tree. The pin is deliberately count-agnostic: it asserts “every match must have property P,” not “we expect exactly seven sites.” So the next hand-rolled eighth site — the one a human reviewer would skim past — fails CI the moment it lands, from anywhere in the codebase.

Pin guards…	Class
No raw INSERT into a chained audit table outside the one _chain_insert writer — a stray insert would fork the HMAC chain.	audit-chain
Every PHI→LLM egress site sits inside a function that references an allowed HIPAA control (or an explicit allow-list).	hipaa-gate
Every outbound HTTP / SMTP / IMAP / DNS client is built through the egress funnel with a declared intent — raw httpx / smtplib / urllib is banned.	egress
Every credential write routes through the never-clobber-on-blank secret-write SSOT — browser autofill can’t zero a stored token.	secret-handling
Every sqlite3.connect in the source tree goes through the encryption-aware opener — no path can open the DB unencrypted.	db-safety

The taxonomy spans secret-handling, audit-chain, egress, hipaa-gate, db-safety, view-render, ssot-consolidation, route-coverage, and meta-pin. And the pins are themselves censused: a meta-pin fails the build if a pin walks the tree the wrong way. A pin over the pins isn’t paranoia — a control that can silently rot is not a control.

2 · Verify, don’t accept

An audit finding is a question, not a verdict.

External audit reports, structured expert-style reviews, and the project’s own automated census output are never filed as defects on their word. Every cited file:line is re-opened at the current HEAD and assigned one of seven canonical labels:

VERIFIED · STALE · REFUTED · DOWNGRADED · UPGRADED · PARTIAL · DUPLICATE.

The report’s claim is the question; the answer is what the code says today. Empirically about half of findings reshape after that check — a claim that read as critical turns out already-fixed (STALE), or a low note turns out to hide a real gap (UPGRADED). Acting on an unverified finding is how teams “fix” things that were never broken and miss the ones that were.

3 · The review gate

No change to a risk surface reaches main unreviewed.

Any change whose diff touches a medical-scope surface — PHI/HIPAA logic, the audit chain, encryption, auth, egress, LLM prompts, schema/migrations — is blocked from main unless the commit carries a valid review verdict. The gate is enforced twice: once client-side in the commit flow, once server-side in CI, so a bypass has to defeat both. It applies three independent review lenses — distinct evaluative perspectives built into the process, not a staffed committee. In a solo practice they are largely structured AI personas, each held to its own brief, plus the operator’s hardware-key sign-off:

4 · The paper trail

Every finding lands on a permanent, retained register.

Whether a finding is opened by an outside auditor, an automated census, the review panel, or a live incident, it lands on one register keyed to §164.316(b)(1) — ID, title, §-anchor, severity, status, opened/closed, owner, and a rationale link. Every status transition emits an HMAC-chained audit row, and the register is retained for the full §164.316(b)(2)(i) six years in-tree and in git history — and in off-host backup where the operator enables it (off-host backup ships disabled). No closed row is ever silently dropped.

Incident → structural pin lineage

The register records what was found. This is the “how does that not happen again” answer — each real production failure paired with the count-agnostic pin that now fails the build if the shape ever recurs:

• A save button silently wiped OAuth credentials for eight days. Eleven credential-write sites inferred intent from field presence, so autofill clobbered stored secrets. Now: an interprocedural pin forces every form-derived credential write through a never-clobber SSOT — blank preserves, only an explicit clear zeroes.
• A whole feature was dead in production behind 167 green tests. Three files imported names that only existed as function-local imports elsewhere; every unit test injected a fake at the seam, so the real path had zero coverage. Now: a static walker proves every first-party import resolves to a real module attribute, plus a test that drives the un-injected wiring.
• An edit to an already-applied migration downed a deploy. A “behavior-neutral” refactor changed the source of two shipped migrations; the boot-time checksum verifier refused to start. Now: a frozen normalized checksum of every shipped migration body fails CI if an applied body is edited or a new migration ships unpinned.

Each incident bought a permanent, tree-wide guarantee — not a note in a wiki that the next hire never reads.

Honest scope

What this is — and what it isn’t.

This is engineering discipline aligned to the cited rules — not a certification, and not legal advice. It does not by itself make an organization HIPAA- or 21 CFR Part 11–compliant; compliance is a program an organization owns, with its own policies, vendor agreements, validation, and attestations. What the discipline above does give you is something most vendors’ compliance decks can’t: a way to check the claims yourself, in public source, and a build that refuses to let them quietly decay. Confirm applicability with your own compliance counsel.