The writer cannot be the only judge.

Suppose an AI agent writes a feature, rereads its own diff and reports that the work is complete. That report may be right. The problem is that the review begins with the same instructions, assumptions and interpretation that produced the code. A mistaken reading can survive both passes because nothing new has challenged it.

That is why I separate creator from verifier. The creator produces the artifact. The verifier decides whether it meets an acceptance contract, a fixed list of observable conditions written before the work began. Separation does not require pretending that either model has pride, sunk cost or a desire to pass. It simply gives the second pass a better chance of using different evidence instead of repeating the first pass.

Useful independence has four parts. Give the verifier a separate context without the creator's reasoning, a separate role whose job is to find unmet conditions, the same acceptance contract the creator received, and access to deterministic evidence such as tests, type checks, database state or browser output. These controls matter more than merely changing the model name.

A different model or provider can add diversity, but it is not automatically independent. Two models can accept the same vague requirement, trust the same faulty fixture or overlook the same domain rule. Conversely, two isolated runs of one capable model can disagree when the second receives a tighter contract and better evidence. The two-net picture is therefore a useful aspiration, not a guarantee: independence is designed through information and authority, not purchased with a model switch.

For consequential work, authority must be separate too. The creator should not be able to mark its own gate complete, rewrite a failing criterion or discard inconvenient output. The verifier reports against the contract, and a deterministic gate decides whether the workflow advances. That turns separation from a polite request into an operating control.

Consider a creator asked to add subscription cancellation. Before it writes code, the contract says that an authorised customer can cancel an active subscription, a repeated request changes nothing, an unknown subscription returns the agreed error, and exactly one audit event is recorded. The creator receives that contract and implements the endpoint.

The verifier receives the contract, the resulting code and a clean test environment, but not the implementation conversation. It exercises all four cases, inspects the response, subscription record and audit log, then reports each condition as pass or fail with evidence. A test runner can block release if any required case fails. The verifier may suggest more cases, but it cannot silently redefine success.

Suppose the repeated-cancellation case creates a second audit event. The isolated verifier detects two records where the contract permits one and attaches the database evidence to a failed verdict. The release gate blocks the change. The creator then makes the operation idempotent, meaning the same request can be repeated without changing the result, and the verifier reruns all four cases before the gate can pass.

This is real work, not a rubber stamp. Its share varies with risk, system maturity and the quality of existing tests, so there is no universal orchestration-to-validation percentage. The preserved chart is too precise for the evidence behind it and should be read only as a reminder to budget verification as part of delivery, not as a benchmark.