Review policy

Which models review, when a review is owed, how a second opinion on a different model is arranged, and what the record demands before a review can open a merge.

Review is not a step somebody remembers. It is a debt recorded against the work, and the merge refuses until the debt is discharged.

A review is owed, or it is not — and the order says which

Each piece of work declares its review mandate:

mandate	what it means
named review	this work owes a verdict from an independent review actor. The merge refuses until that verdict is on the record
master-verify-only	the work is verified mechanically by the master — build, tests, the checks that apply — and parks at ready-to-merge without an independent eye

⚠ The mandate is a property of the work, not of the round. A body of work that runs for several rounds owes one verdict, on its last round — not one per round.

Which model reviews

The reviewer's model is configured per role and per agent backend, not chosen per dispatch. In practice that means a line of configuration decides "reviews on this backend run on this model", and every review dispatch inherits it.

⇒ Two consequences worth having:

A reviewer can be a different model from the executor — deliberately. A second model reading the first one's work catches a class of error that no amount of self-checking does, because the two do not share the same blind spots.
The choice is auditable. The run records which model reviewed, and where that model came from — a configured default or an explicit choice at dispatch.

A second opinion, on a different model — the verification class

Some changes deserve two independent eyes rather than one, and which changes deserve it is your policy, not the product's opinion. A verification class carries that policy:

fleet.verify.class.<class> = twice     # or: once

twice means two reviews, by models of DIFFERENT families, neither reviewer seeing the other's verdict. Two different families rather than two runs of the same model, because two instances of one model share their blind spots — a second opinion from the same family is a second sample, not a second judgement.

Why it is a configuration key and not a built-in rule: an enterprise sets its own verification requirements per class of change. The owner's own reason for the shape: "I like having everything under control this way. It is easy to change and to hand to a customer to configure to their own requirements."

It degrades rather than blocks

Two preconditions have to hold for twice to mean anything: the fleet must actually have seats on two model families, and its owner must have ratified the class for that fleet.

⛔ Absent either, the class degrades to one review — silently and legally. It must never refuse work for want of a second reviewer the fleet does not have. That is a deliberate design choice: a verification policy that halts a fleet it cannot satisfy would be abandoned within a week, and an abandoned policy protects nothing.

What it costs, stated plainly

Doubling review costs money, not time — the second review runs on a seat that would otherwise be idle, so wall-clock is usually unchanged. ⇒ The trade-off is a budget question, which is exactly why it belongs behind a key you set rather than a default somebody chose for you.

⚠ Its state today, so nobody plans on a promise: the class is decided and practised — verification classes have been run with two reviewers of two model families, each blind to the other's verdict. The configuration key is not yet read by the product: today the policy is applied by the person composing the dispatch, one review at a time. When the key lands, the policy stops depending on anyone remembering it — and that is the whole point of writing it down as a key.

What the record demands before a verdict counts

A verdict is not a message — it is a delivery:

the review actor writes its verdict in the reviewed work's own channel;
the verdict is brought home into the record, which mints a durable, content-addressed copy;
the review gate points at that durable copy, and refuses if it points anywhere else.

A verdict that was written and never delivered is invisible to the record — and, worse, indistinguishable from work still in progress. ⇒ Delivery is a step, not a formality.

What review does not do

⛔ A review does not merge. Accept, accept-with-conditions and reject are all recommendations to a human, and the merge remains a human act. accept-with-conditions is mergeable: the conditions become the next piece of work, named and recorded, rather than a reason to hold finished work hostage.