# From Review to Prosecution to **Calibration**

Published: 2026-07-08T17:09:08.000-0400
Tags: agents, llm, ai-development, amm, enterprise, code-review
Canonical: https://www.voodootikigod.com/amm-6-review-prosecution-calibration

> Adversarial review is not a Level 4 luxury. It is the entry requirement for Level 3, and it matures into an instrument with a known error rate.

---

A lot of leaders hear "Level 3" and picture more agents. Agents everywhere! More autonomy, wider deployment, the capability number going up again. That's half right and the less important half. Level 3 is defined by what happens underneath the agents, not by how many of them you're running.

## Adversarial review is not a Level 4 luxury

It's the entry requirement for Level 3. That ordering surprises people, because review, in most enterprise imaginations, is the mature, careful, later-stage thing you add once the exciting capability work is done. In this model it's the opposite: without it, you cannot safely delegate whole tasks to agents at all, because nothing established that the output is correct.

[Adversarial review](/adversarial-review) is what actually replaces the human review bottleneck [described earlier in this series](/amm-2-five-levels): fresh contexts, chartered specifically to refute the work rather than assess it, running until findings converge instead of stopping at whatever a single tired pass happens to catch. It's the same mechanism the ADLC calls [prosecution](/adlc-4-prosecution-not-code-review) when the work under review is code, and the underlying claim is domain-general: a reviewer that shares the builder's context will rubber-stamp the builder's blind spots, sincerely, every time. A reviewer that doesn't share that context is the only thing that can actually see them.

## The verification ladder, walked as an organizational decision

The [Diagonal Law post](/amm-3-diagonal-law) already named these five stages as the vertical axis of the grid. Here they are again, this time as the sequence of decisions an organization actually has to make, not just a taxonomy:

- **V0 - Prevention.** The organization's only control is a policy document. Nothing gets verified because, officially, nothing exists.
- **V1 - Individual judgment.** Whoever ran the prompt decides whether the output is good enough. This is a private, unaccountable, unfalsifiable form of trust, and it's where most companies actually spend their "experimentation phase."
- **V2 - Human review.** A person reads everything before it counts. This is the trust mechanism the organization already had before AI arrived, kept in place unchanged, which is precisely why it becomes the review bottleneck the moment production volume multiplies and reviewer headcount doesn't.
- **V3 - Rails and adversarial review.** Executable tests frozen before implementation exists. Contracts the builder is mechanically prevented from arguing with. Fresh contexts chartered to refute. This is the stage where trust actually relocates from a person's attention to a mechanism, and it's the only stage on this ladder that requires the organization to build something rather than staff or buy something.
- **V4 - Calibrated prosecution.** The gates from V3, now measured rather than trusted on faith.

Notice the shape of that progression: every rung through V2 is a *policy about who looks*. V3 is the first rung that's a *mechanism*, and that's what makes it the load-bearing transition on this entire track. Every capability rung above it is only safe once the verification rung underneath has actually been built.

## What calibration actually means, and why "we have review" isn't an answer

V4 is where review stops being a ritual and becomes an instrument with a known error rate, and the mechanism is specific: planted defects, drawn from a held-out, severity-stratified bank the reviewed system cannot see, run through the gate the same way real work runs through it. What comes back is a number: what fraction of real, categorized defects did this gate actually catch.

That number matters more than most enterprises expect, because "we have review" and "we know our review catches sixty percent of the security-relevant category and eighty-five percent of the correctness category" are two entirely different claims dressed in the same sentence. The first is a policy. The second is engineering. I watched this distinction get proven the hard way, aiming [prosecution at the review-calibration gate itself](/adlc-9-prosecuting-the-gates): the honesty meter that was supposed to measure review depth turned out to be gameable, and once that was found, the fix was frozen into a test so it couldn't quietly revert. That's not a hypothetical failure mode. It's what happens when nobody adversarially checks the thing that's supposed to be checking everything else.

An audit check that doesn't state the measured quantity and the specific gaming it resists isn't a real audit check. It's a sentiment metric with better production values, exactly the failure this whole model exists to catch elsewhere. "We have a calibration process" is not evidence. The catch rate, per category, with the plant bank held out from the system being measured, is.

## Why this track can't be bought, only built

Every other track in this model has tooling you can procure. Eval platforms, guardrail products, red-team services, all genuinely for sale and genuinely useful. What isn't for sale is the organizational decision this track actually requires: a leader who stops mandating human review of everything, on the basis of evidence rather than optimism, because someone showed them what the machine gates catch.

That's the reason [you cannot leapfrog this ladder](/amm-3-diagonal-law) by buying agents and skipping straight to Level 3. Rails have to be authored by people who learn to write executable specifications. Adversarial review has to be chartered and then believed, which means calibrated. Nobody sells an organization's willingness to actually trust the number a calibration run produces instead of the number a survey produces. That willingness is the whole transition, and it's the reason V2 to V3 is where most enterprise AI programs stall out for months even after the tooling is sitting there, purchased and unused.

Get the verification track right and the economics move next, because a gate you trust is a gate you can stop paying a human to duplicate. That's where this series goes from here.
