Review policy

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:

⚠ 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. It takes two switches, and neither alone changes a merge:

1. The order declares the class: a - verify-class: 3 bullet says this work is one where nothing else would tell you it shipped broken. ⛔ A value outside the closed set is not treated as "no class": it makes the merge refuse until the order is corrected.
2. The fleet decides what that class costs there, in its configuration:

saphan config set fleet.verify.class.3 twice     # or: once — the default when the key is absent

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. Which model belongs to which family is declared under [fleet.verify.family]. When the class applies, saphan merge refuses until both verdicts are on the record, and one reject is decisive on its own.

Why it is a configuration key and not a built-in rule: an organisation sets its own verification requirements per class of change, and a key is easy to change and to set to your own requirements.

It degrades rather than blocks

Two preconditions have to hold for twice to mean anything: the fleet must actually be able to run reviewers on two model families, and the key must say twice.

⛔ Absent either, the class degrades to one review — silently and legally. It never refuses work for want of a second reviewer the fleet does not have: a verification policy that halts a fleet it cannot satisfy would be abandoned within a week, and an abandoned policy protects nothing. ⚠ The opposite case is not a degradation: a configuration file that exists but cannot be read makes saphan merge refuse, because a policy you declared and the engine failed to read must never be quieter than no policy.

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.

What the record demands before a verdict counts

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

1. the review actor writes its verdict in the reviewed work's own channel;
2. the verdict is brought home into the record, which mints a durable, content-addressed copy;
3. 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.