Verifying the Record, Not the Model
There are two questions you can ask about an AI system working inside a regulated process, and almost everyone is asking the first one.
The first: was the model right?
The second: is the record of how this decision was reached true, complete, and reconstructable by someone who was not in the room?
These sound like versions of the same question. They are not. They have different failure modes, different evidence, and only one of them survives an inspection eighteen months later, when the person who ran the model has left the company and the model has been retrained twice.
NexTrial builds for the second question. Not because the first does not matter, but because the industry has poured its attention into it and left the second almost unattended. A great many systems now produce regulatory work. Very few check the record of how that work came to exist.
This is the doctrine underneath the Three-Gate Verification System. It is not a new architecture. It is the reasoning the existing one was built from, written down so it can be argued with.
Vera checks the record
Vera is the verification agent. She does not draft, and she does not decide.
Her whole function is to answer the second question, which means her operating rules are narrower than they would be for a system whose job is to be right.
Verify. Recompute, never trust. Every check begins from recomputed primitives. Never a stored summary. Never a cached result. Never another component's assurance that it already handled it. A verifier that accepts what it is handed is not verifying. It is agreeing, and agreement is not evidence.
This reads as pedantry until you watch how systems fail. They rarely fail at the check. They fail one layer below it, where something was assumed to have been checked already, by a component nobody has looked at since the migration.
Solve. A failed check is not a dead end. When a check fails, Vera localizes the failure to the exact step, classifies it, and records it as a finding. A data gap means evidence is absent, which is a coverage boundary and not a violation. A code defect is checkable, wrong, and ours to fix. A tamper indicator means the record was altered after signing, which is an escalation and not a remediation. Collapsing all three into a red light destroys the only information that matters.
The principle underneath is the one the industry is worst at:
The check that finds a break is succeeding, not failing.
We trained a generation of clinical research professionals to fear findings, and then quietly built systems that do not look too hard. That is the most expensive habit in the field.
Guide. Every output carries its next step. What would resolve this finding. What can still be relied on in the meantime. What to re-check after the fix lands. A problem reported without a path forward is not a verification result. It is anxiety with a timestamp.
Why the gates are separated
Most systems sold into regulated work have one layer. A model produces an output and the output is the product. Confidence lives inside the same process that generated the thing you are being asked to trust.
The Three-Gate Verification System separates that into three, and the separation is the entire point.
Gate 1 proposes. A model applies versioned rules to a specific document and produces a determination. This gate contains a model, because interpreting regulatory text against a protocol is a judgment task. It runs at zero temperature against an explicitly versioned rule set, so the same input, the same rule version, and the same document produce the same determination every time. Reproducibility is not a nice property here. It is the precondition for everything downstream. A stochastic decision cannot be verified, only re-sampled.
Gate 2 proves. This gate contains no model at all. It establishes machine-checkable properties over the record itself, using formal methods, so that certain statements about the record are proven rather than asserted.
Where that stands today, stated exactly: Gate 2 is shipped and is in first validation with one sponsor. The formal verification layer inside it is built and in testing. It is not in production, and it covers a subset of the properties we intend to prove rather than the whole set. We say it that way because the alternative is to write "formally verified" and let the reader supply a scope we have not earned.
Gate 3 decides. A named human, whose attestation is cryptographically bound to the exact state of the record at the moment they signed, not to a later one. Not a compliance formality. Not a fallback for when the machine is unsure. A structural requirement, for reasons that land at the end of this piece.
A model that proposes and also certifies its own proposal has produced something that reads like assurance and was generated by the same process that produced the thing under review. Under inspection, "we asked another model and it agreed" is not evidence. It is a second opinion from the same mind.
What Vera actually checks
Verification runs in layers, and each proves something the others cannot.
Primitives. Recompute the cryptographic signature on each record. Confirm each record links to its predecessor. Confirm the text being cited is the text that was signed. Records are append-only. Nothing is edited, only superseded, because an edited record cannot answer a question about the past.
Structure. This is where bi-temporality earns its keep, and it remains the most underrated idea in regulated data architecture. Every record carries two independent time axes: when the fact was true in the world, and when the system learned it. Without both, you cannot answer the question an inspector actually asks, which is not what do you know now but what did you know then. A system with one clock reports the current state. A system with two reconstructs the state of knowledge at the moment a human signed.
Provenance. Every artifact claims a lineage:
SOURCE DOCUMENT → PAGES → EXTRACTION → DETERMINATION → RULE SET VERSION → HUMAN ATTESTATION → TIMESTAMP
Verification is walking that claim backward, confirming every hop independently, in reverse order, trusting no intermediate summary.
Claims. What the output is permitted to say. This is the layer almost nobody designs.
The claim vocabulary
Vera does not say "this is valid."
She says what was checked, enumerates the checks, and names what she did not cover.
A verification claim without its coverage caveat is a defect, not a footnote.
That requires a controlled vocabulary, because the words are where overclaiming happens.
Evidenced. An artifact exists and is bound to a specific obligation.
Partial. Some evidence exists. Insufficient to close.
Open. No artifact was located. Open is never a violation, because absence of located evidence and evidence of absence are different findings, and confusing them is how automated compliance tools destroy their own credibility.
Conditional. The highest positive state a machine may reach on its own.
Determined. Requires a named human.
Fixing that ceiling in the architecture rather than in the interface copy is what makes it real. The machine is structurally incapable of issuing the strongest form of a claim.
Write the exclusions down first
One more discipline, and it travels further outside this industry than anything else here.
Before a verification runs, write down every gap you already expect it to find. Every place the lineage is incomplete. Every known weakness in coverage. Commit that list, dated and signed into the same record, before the first check executes.
An exclusion named in advance is a boundary.
An exclusion named after the check finds it is an excuse.
The difference is invisible in the output and total in what the output is worth. It also produces the metric that matters, which is not how many findings came back but how many were novel. Expected findings confirm you understood your own system. Novel findings are the verification earning its keep.
What this looks like under inspection
A protocol arrives. A determination is made about which regulatory obligations apply, in which jurisdiction, on which pathway. Documents are drafted against those obligations. A human reviews and signs. The study proceeds.
Eighteen months later an inspector asks the question every one of us has been asked. How did you arrive at this?
The answer that survives is not "our system is highly accurate." It is the walk. This obligation came from this version of this rule set. It was applied to this protocol, from this source document, at these pages, whose text is signed and recomputable today. The determination was produced at zero temperature and can be regenerated identically. It carries these proven properties and these unproven ones. This named person reviewed it, and their attestation is bound to that exact state of the record. Here is what was checked. Here is what was not.
That is not a better answer than the accuracy claim. It is a different kind of answer. It is the kind you can hand to someone who does not trust you and have it still work.
The limit we will not engineer around
There is a floor under all of this, and naming it is better than letting someone find it.
When Vera signs her own result and writes it to the record, that result is signed by the same infrastructure she exists to check. Verification of her own prior output is recomputation under the same trust assumptions, not independent attestation. Whoever holds the signing keys sits outside the boundary of what the chain can prove. Stronger answers exist ahead of us, countersignature by an independent party and anchoring to an external immutable reference among them, and they are ahead, not here.
We say that plainly because a doctrine that exempts itself is not a doctrine. It is marketing with axioms.
It is also exactly why the last gate is a person. The machine can prove what was checked. It cannot certify itself. The signature that closes the loop has to come from outside the system, from someone accountable in a way that no key, no chain, and no certificate can be.
If you are building AI into a regulated process
Six things, and none of them require buying anything.
Build the layer that checks separately from the layer that decides. Make the deciding layer reproducible. Give the checking layer no model at all. Publish your vocabulary and refuse to exceed it. Write your exclusions down before you run. Name your own limits in public, because the alternative is that someone else names them for you, at the worst possible moment, in a room you do not control.
Provenance is the whole game. Not confidence. Not accuracy scores. The unbroken, recomputable answer to how this came to be true, held by a system honest about the edges of what it checked.
The model proposes. The proof disposes. The human decides.
FAQ
How do you make an AI-assisted regulatory decision admissible under inspection?
By producing a record that can be walked backward independently. The obligation traces to a versioned rule set, the rule set traces to a source document at specific pages whose text is signed and recomputable, the determination is reproducible from the same inputs, and a named human attestation is bound to the exact state of the record at the moment of signing. Accuracy is not the argument. Reconstructability is.
What is the difference between verifying an AI model and verifying the record of its decision?
Verifying the model asks whether the output was right. Verifying the record asks whether the account of how the output came to exist is true, complete, and reconstructable by someone who was not present. The two have different failure modes and different evidence. Only the second survives an inspection years later, after the model has been retrained and the operator has left the company.
Can an AI system certify its own output?
No. A model that produces a determination and also attests to that determination has generated its assurance from the same process that produced the thing under review. Under inspection this is a second opinion from the same source, not independent evidence. The layer that checks has to be separated from the layer that decides, and the final signature has to come from a named person accountable outside the system.
What is a coverage caveat in a verification claim?
The explicit statement of what a verification did not cover. A verification result that reports what was checked without naming what was excluded is incomplete, because the reader cannot tell the difference between a clean check and a narrow one. In a controlled vocabulary the caveat is structural rather than editorial.
Why does a verification architecture still require a named human?
Because the system cannot certify itself. When a verifier signs its own result into the record, that signature rests on the same infrastructure the verifier exists to check, and whoever holds the signing keys sits outside what the chain can prove. The signature that closes the loop has to come from someone accountable in a way that no key and no certificate can be.
Steven Thompson is the founder of NexTrial.ai, building Trial Activation Intelligence for clinical research.