The Verification Doctrine
Status: Complete · When generation is cheap and trust is low, the scarce discipline is verification. This is the doctrine that makes P3 operational.
For most of software's history, writing the code was the hard part and checking it was an afterthought you bolted on at the end. That ratio inverted. When generating a plausible-looking 400-line slice costs seconds and a few cents, the act of generation stops being the bottleneck and stops being the achievement. The expensive, scarce, defensible thing is now the opposite act: deciding whether that output is actually correct, actually safe, and actually what the spec asked for — and being able to prove it rather than feel it.
This is the 2026 center of gravity. Generation became a commodity; trust did not. The gap between "the model produced something" and "I can stake my name on it" is exactly the gap SAE is built to close. Verification is not a phase at the end of the lifecycle. It is the doctrine the whole framework is organized around.
You do not have to take SAE's word for it. The industry signals all point the same direction, and they are worth stating honestly — as directional reported signals, not laws:
- Developers do not trust the output they accept. Large practitioner surveys through 2024–2025 consistently report that while the large majority of developers now use AI coding tools, only a minority say they actually trust the accuracy of what comes out — and the share reporting active distrust has been rising even as adoption climbs. Usage went up; confidence went down. That is the crisis in one sentence.
- Review is becoming the bottleneck. Engineering-metrics vendors and team retrospectives increasingly report that pull-request review time and review load have grown as AI-assisted output volume rises. More code, generated faster, lands on the same number of human reviewers — and the queue, not the keyboard, is where time now goes.
- "Looks right" is not "is right." The recurring theme in incident write-ups is plausible-but-wrong output: code that compiles, reads cleanly, passes a glance, and is subtly incorrect. The cheaper generation gets, the more of this there is to filter.
Reality check. These are industry signals, framed directionally — survey numbers move year to year, vendors measure different populations, and "trust" is self-reported. Do not quote any single figure as established fact. The robust, repeatable claim underneath them is the one SAE relies on: generation got cheaper and faster while trust got scarcer. That trend is what the doctrine is engineered against, and it does not depend on any one statistic being precise.
The takeaway is not "AI bad." It is that the constraint moved. If you optimize your workflow for more generation you are pouring water into the bottleneck. The leverage is on the verification side — which is exactly where P1 (clarity is the binding constraint) predicted the cost would migrate.
SAE's verification is not white-box (the reviewer sees and trusts everything about how the code was made) and it is not black-box (the reviewer sees only inputs and outputs and knows nothing of intent). It is grey-box, and the distinction is load-bearing.
| Mode | What the verifier knows | Failure mode |
|---|---|---|
| White-box | The full authoring context — every assumption the writer made | Inherits the writer's blind spots; rationalizes the same way the writer did |
| Black-box | Only the surface behaviour; no intent | Can't tell "wrong" from "different"; has no oracle for correct |
| Grey-box (SAE) | The spec and the interfaces — partial knowledge of intent — judged from a fresh context | Correlated error only when the spec itself is wrong |
The Guardian is the grey-box verifier. It is given partial, deliberate knowledge: the relevant specs/<slice>.md (P2) and the contracts at the slice boundary (P4) — enough to know what correct means. It is denied the one thing that would poison its judgment: the authoring context. It does not see the Engineer's chain of reasoning, its half-formed assumptions, or its "I'll fix that later" notes. It opens cold, with the spec as its oracle and a single instruction: find what's wrong.
That combination — knows the intent, doesn't know the rationalization, briefed to refute — is the whole trick. The Guardian can tell wrong from merely-different (it has the spec) without inheriting the writer's blind spots (it lacks the writer's context).
The doctrine reduces to a clean pipeline.
Precise specs IN. The input is not a vibe or a ticket; it is a spec precise enough to be an oracle (P2). If the spec is ambiguous, verification has nothing to verify against — you are back to "looks right."
Evidence-based verification OUT. The output of the Guard phase is not an opinion ("LGTM") but evidence: the failing case it tried and the slice survived, the hostile input it ran, the spec clause it mapped each behaviour to, the edge the spec missed. An unrefuted change — one the Guardian genuinely tried and failed to break — is a pass. A change nobody tried to break is not verified, it is merely unexamined.
Humans accountable at exactly TWO points. This is the part people miss. SAE does not put a human in the loop everywhere — that just recreates the review bottleneck the crisis is about. The human is accountable at precisely two moments:
- Authoring the spec — the human decides what is correct. This is where intent enters the system, and it cannot be delegated. Get this wrong and everything downstream is confidently wrong.
- The blast-radius gate on the irreversible (P5) — the human authorizes anything that can't be undone: auth, payments, deletion, schema drops, external sends. Reversible changes flow; irreversible ones stop here.
Everything between those two points — generation, the adversarial Guard pass, diff review, reversible application — is machine work supervised by the operator. The operator still owns the output (P6); ownership is not the same as touching every keystroke. You author the definition of correct, and you guard the door on the things that can't be taken back. Two points, not everywhere.
Reality check. "Two accountability points" is the target shape, not a license to stop reading diffs. The operator reviews far more than two artifacts day to day. The claim is narrower and honest: these two points are the ones where human judgment is non-negotiable and non-delegable. Compress human attention onto them; let evidence carry the rest.
The single most important reason verification must come from elsewhere is correlated error, and it is not a productivity argument — it is a structural one.
When a context generates code, it makes a chain of assumptions: what the inputs look like, what "valid" means, which edge cases matter, how the boundary behaves. Those assumptions are invisible to the context that made them — not because it is lazy, but because they are the lens it is looking through, not an object it can look at. Asking that same context to review its own work is asking it to find a bug it has already, by construction, decided isn't there. Its review will share every assumption its generation did. The errors are correlated: the writer and the self-reviewer fail in exactly the same places, so a second pass adds confidence without adding coverage.
This is the formal content of P3 — the writer never judges its own work. A fresh-context Guardian fails independently: it brings different assumptions, so where the Engineer was blind the Guardian may see — and the union of two independent passes covers more than twice one correlated pass. Independence, not effort, is what buys the coverage.
Doctrine is useless without a repeatable move. Here is what the Guardian actually does, and how much ceremony to spend.
The Guard pass (every non-trivial change):
- Open cold. A separate, clean context with no memory of how the code was written — the fresh-context adversarial review move. Load only the spec and the slice's contracts.
- Refute, don't confirm. Instruct it to assume the code is wrong and find why, defaulting to "broken" when uncertain. "Looks good" is not a verdict; a survived attack is. (Technique 8 in Operator Techniques.)
- Review the diff against the spec. Map each behaviour to a spec clause. Flag anything the diff changed that the spec did not ask for — unrequested scope is a defect, not a bonus. (Technique 10.)
- Probe the gaps the spec didn't cover. Hostile inputs, boundary values, concurrency, the failure paths. Where the spec is silent, that silence is itself a finding — kick it back to the spec (P2).
- Emit evidence, not blessing. Record what was tried and what survived. That record is the artifact; it is what makes the verification auditable later.
How much ceremony — single-vote vs multi-lens:
| Change profile | Verification | Why |
|---|---|---|
| Reversible, low blast radius, low entropy | Single-vote — one fresh-context refutation pass | One independent lens already breaks correlated error; more is ceremony theatre |
| High blast radius (auth, money, data) or high entropy | Multi-lens — several independent passes, each a different lens (correctness, security, reproduces, performance) | A single blind spot can pass one reviewer; diverse lenses cover what one cannot. (Perspective-diverse review, technique 9.) |
| Irreversible | Multi-lens plus the human blast-radius gate | Independent review and a named human authorization before it touches production |
The rule of thumb: scale verification to blast radius and entropy, never below single-vote for anything non-trivial, never skip the human gate on the irreversible. A one-line typo fix does not earn a three-lens panel; a payments migration does not get a glance.
Grey-box verification with adversarial independence defeats correlated error of execution — the Engineer's blind spots. It does not defeat correlated error of intent.
Reality check. If the spec is wrong, the Engineer builds the wrong thing correctly and the Guardian — judging against that same wrong spec — confirms it is correctly wrong. Both agree, both are independent, both are mistaken, because they share the one thing the Guardian is given: the spec (P2). The shared oracle is the shared blind spot. This is the residual failure mode the doctrine cannot engineer away, and it is exactly why the first of the two human accountability points — authoring the spec — is the one that can never be delegated. Verification proves the code matches the intent. It cannot prove the intent was right. That remains on the operator, and SAE does not pretend otherwise.
This is the price of the model and it is paid openly: the better your verification, the more it concentrates risk onto the quality of your specification. Which is the whole point — it pushes the scarce human judgment to the one place it actually belongs.
See also: First Principles (P2, P3, P5, P6 — the canon this doctrine operationalizes) · Operator Techniques (the concrete Guardian moves) · Module 3 — The Digital Org Chart (the Guardian role) · Risks, Security and Governance (the blast-radius gate) · KPIs and Metrics (measuring spec-drift) · Glossary (Context Entropy, Adversarial Independence).