Case studyLevel 5 · AdmissibilityDrift & repair

The validator that won't let the AI be wrong about Susan

Susan processes invoices every Tuesday. Your AI knows none of this — and will happily generate a confident, plausible workflow that has never existed.

The anecdote

Susan processes invoices every Tuesday. She routes them to Jim in procurement first, because of a PO check. She cares more about the cost-center field than anything else. She takes a chocolate break at 4pm on Wednesdays. Your AI knows none of this — and worse, it will happily generate a confident, plausible workflow for "automate Susan's job" that has never existed: invoice goes straight to the approver, cost-center check skipped, Jim never mentioned. It doesn't know. It performs knowing.

The fix that actually works isn't "give it more context." You can paste fifty pages of Susan's procedures into the window and it'll still contradict page 23, because reading is not the same as understanding compositionally. The fix is to constrain how the AI is allowed to talk about Susan. Every claim it makes has to decompose into parts that are each individually validated, all the way down. "Susan's invoices go through Jim for PO validation" is admissible because every piece of that composition is real. "Susan's invoices go straight to the CFO" is inadmissible — not because it sounds wrong, but because the composition doesn't close: there's no validated path from Susan's invoices to the CFO. The system catches it. Immediately.

What it reveals (the shape of the deeper rung)

• **There's a thing that sits between the AI and reality and gates what gets admitted.** New claims are proposed; the gate checks them against a typed model of what's allowed; claims that don't compose are not admitted as knowledge — they're held aside until repaired or they sit there forever, never participating in anything downstream.
• The model is built up, not declared. You start with almost nothing ("what is an invoice? what's a 'Susan'?") and add validated observation on validated observation until you have a model the AI must respect. Each layer verified before the next is trusted.
• An error is an instruction, not a dead end. When a claim is rejected, the rejection tells the AI exactly what's missing and how to fix it — "you said X requires Y, and Y has never been observed; observe Y first" — and primes it to repair rather than just fail. The failure message is the next prompt.

What you can take from it right now

The distinction is the gift: your AI doesn't know your domain, it performs knowing it — and the cure isn't more documents, it's whether claims have to compose from validated parts. Just holding that distinction changes how you evaluate every AI output you depend on, and it's free.

Honest caveat. What this doesn't cover: the ontology the gate checks against, and the mechanics of decomposing a claim at every depth so a malformed one can never slip through.

Distilled from: admissibility engineering · l5 admissibility · admissibility · l6 concentration