A check that cannot see the thing it is trusted for

An external FHIR subject-matter expert pressure-tested the public product on 2026-08-27 — one day after an internal truth programme closed GO — and returned "Not Yet": two Critical findings, eight High, five Medium, one Low, with a recommendation not to let engineers rely on the tool for real implementation decisions. Every one of the seventeen was measured against the code rather than accepted, and every one was real at some level: 10 CONFIRMED, 7 PARTIAL, 0 REFUTED. Both Criticals were wrong-workflow defects on the public teaching surface — an inquiry fixture validated as a submission, and an adaptive-form transcript that taught an invented operation contract.

The suite was green throughout, and that is the finding. The same shape recurred in four independent places during remediation: a check that cannot see the thing it is trusted for. 5,757 unit tests passed while `next build` failed on a scope error, because the gate did not build. A washer-disclosure guard stayed green over the sentence it existed to forbid, because the guard's own docblock had classified that sentence as a legitimate denial. A new finding field was invisible to every committed golden, because the report stabiliser projects a fixed field list and anything outside it cannot move a fixture. And a control asserted that a copy projection was CALLED while never asserting what it composed into — so "Paste FHIR FHIR resource JSON" reached production with its test green. None of these is a missing test. Each is a present test measuring one layer away from the claim it was credited with.

• Reading a stale board column as current state. The remediation plan recorded a P2 finding as blocked on a ticket that had merged 26 days earlier; nothing had stamped its card, so `column: building` was load-bearing and wrong. This is the second time the same shape has cost this estate real work.
• Propagating a doctrine inversion across five merged files. I asserted that a 'Next free per prefix' pointer line CLAIMS an id, when three merged sources — the mint README, a ledger row, and a note one day older — say the opposite. As written the rule would have forbidden four ids the wave needed.
• Reporting a wave complete without counting it. I told the owner ten tickets were merged 'bar this one' when eight of ten were; two had never been built. The claim was cheap to check and I did not check it.
• Building on a premise the evidence had already overturned. One ticket's recorded decision was 'repair the fixture and re-pin to READY'; its own captured findings showed a single unresolvable terminology reason, no payload defect to repair, and READY unreachable by any means. The deliverable became the correction, not the build.
• Two edits that looked complete and did nothing. Changing a rule's `defaultSeverity` when its evaluator passes an explicit severity that shadows it; and writing a negative-case arm against a payload excluded by an earlier guard, so the arm passed without ever reaching the code it named.

Three waves and thirty-two tickets, each carrying mutation evidence — a control is not credited until deleting the guarded code turns its named test red. Both Criticals and every High closed on production, then re-probed against the deployed site rather than only in CI, because a fix confirmed in CI is not confirmed on the surface the reviewer actually tested. That re-probe re-confirmed ten behaviours and found one defect the pipeline could not see. The durable lesson is smaller than the ticket count: when a change does not move what you expected it to move, that is the finding — not a clean result.