When a Check Doesn’t Run
“The Last Deterministic Thing: The Unified Capture Layer” closed out my series on the expanded validation boundary - a deep dive into each component of the COU x probabilistic model x harness x HITL equation. The capture layer is the instrument that makes it all operational and inspectable.
The three definitions of determinism, as explored in detail in "The Last Deterministic Thing: The Unified Capture Layer”
There is a crack in the logic that has to be acknowledged: capturing what happened isn't enough on its own, because a check that never runs leaves nothing behind — and a missing record doesn't read as a failure. It reads as nothing wrong. This matters most at the transition points: when a suggestion becomes an action, and when an action enters the official record.
The Missing State
There are three states capture must distinguish between for every check:
Passed
Failed
Did not run
The third one is where the blind spot lives. If a system records only pass/fail, a check that crashed silently looks identical to a check that passed. The absence of a “fail” reads as success.
The fix? Record the expected check-set per decision. That way a missing check is identifiable as missing, not erased altogether. This gets even sharper across an org boundary, where the gate runs through a vendor's infrastructure; that's its own piece.
When the Check Can’t Be Recorded, What Happens?
A risk-based approach is appropriate here; not every action requires the same response when capture fails. The type of response is tiered by what the action touches (action class):
Record-Affecting: All record affecting actions must capture and block synchronously. This ensures the data integrity of the formal record. If an action is attempted and capture is not possible, it cannot occur.
Advisory (Pre-Review):"Capture is still synchronous, but a capture failure blocks only finalization, not the draft — it degrades to “produce draft, flag capture-incomplete, block commit” rather than halting.
Internal (A retry, an intermediate agent step in the workflow): At this tier, the capture may be asynchronous, but a retry must still be captured. Otherwise, the record shows only “success”, and key context on the failed attempts is lost.
The same blind spot appears when a check runs, fails, and is retried. Capture needs to record attempts, not outcomes; this is the distinction between runtime data and the validated context.
As Dr. Dennis Janning describes in his own framework “Think - Do - Approve” for AI in GxP environments, when an idea or candidate becomes an action, and when an action becomes an approved record, we need a ledger recording the transitions.
In his framework, the model explores and suggests actions, the validated infrastructure executes within defined boundaries, and, where consequence warrants it, a qualified human decides, and can refuse, to commit an action to the record. The gate is tiered by consequence rather than appliec uniformly, and an approval that can’t be refused isn’t one.
We found a common thread between our frameworks at the transition layer, where the unified capture layer captures each check. In Janning’s words, “the audit trail should not merely record the event afterward. Capture should be part of the transaction itself.”
The ALCOA++ Answer
An audit tells you what happened. Check capture embeds integrity structurally. For large language models and agents, it enforces data integrity structurally, in real time. The runtime context’s write to the immutable store must be append-only (not modify, not delete). If the plane that generates records can also alter them, the store isn’t immutable. That’s not a control.
All of this is Step 6 of the probabilistic validation lifecycle — continuous monitoring — with a sharper requirement than “watch the surfaces”: watch for the checks that were supposed to fire and didn't.
