Adversarial Review

In plain words: before a change can ship, Forge runs it past one or more automated reviewers ("lenses"), then makes a second, skeptical pass that actively tries to prove each flagged problem is real before it's allowed to block anything — the way a second opinion catches what the first doctor missed, rather than just rubber-stamping it. The result is a signed proof-of-review ("receipt") that later delivery steps check for, instead of re-reviewing from scratch every time.

Forge ships a bounded native review lifecycle. Review is risk-tiered, adversarially verified, and produces a content-bound receipt — and its delivery gates are enforced controls: they return non-zero until the receipt validates.

Glossary: lens, refuter, receipt, Judgment Day

• Lens — one specific angle of automated review (readability, reliability, resilience, or security/risk). A small change might get one lens; a payments change gets all four.
• Refuter — a second, independent check that actively tries to disprove a finding before it's allowed to block your change. This exists because a single automated reviewer can be overzealous; the refuter is the sanity check on the sanity check.
• Judgment Day — a stricter mode that swaps the single refuter for two independent "blind" judges who don't see each other's verdict, used when even more confidence is warranted.
• Content-bound receipt — proof that review passed for one exact version of the code, cryptographically tied to its contents. Change so much as a character afterward and the receipt no longer applies.

Lifecycle

forge review start
forge review finalize
forge review validate --gate <gate>

Risk-tiered lens selection

Lens selection is deterministic, driven by the risk of the diff:

Risk	Lenses
Low	0 lenses
Standard	exactly 1 focus lens
High (touches an auth / update / security / payments hot path, or >400 changed lines)	the full 4R set

The 4R set is review-risk, review-reliability, review-readability, and review-resilience.

Adversarial verification

• Severe findings go through a read-only refuter batch — an adversarial check that a severe finding is real before it can block.
• Judgment Day mode uses two independent blind judges instead of the refuter batch.
• Only findings that are introduced / behavior-activated / worsened — with concrete evidence — may block. Pre-existing findings become follow-ups rather than blockers.

Blocking requires evidence

A finding cannot block delivery just because a lens raised it. It must be new or worsened by this change and backed by concrete evidence. Everything else is routed to follow-ups.

Content-addressed receipts and the delivery gates

A finished review produces a content-bound receipt with a bounded correction budget. Delivery gates re-derive live Git evidence and validate that same receipt:

forge review validate --gate <post-apply|pre-commit|pre-push|pre-pr|release>

These gates never reopen review and never spend a new budget — they check the existing receipt against the live tree. If the content the receipt was issued for still matches, the gate passes; otherwise it returns non-zero.

This is an enforced gate

forge review validate --gate <gate> is one of Forge's four enforced controls. It returns non-zero until the content-bound receipt validates against live Git evidence — it bounds delivery, regardless of what the agent narrates.

Where review fits

Review is the delivery Sensor: the circuit-breaker bounds iterations, the budget bounds spend, and review bounds what actually ships. See the enforcement doctrine for the full picture.

Next steps

• The enforcement doctrine — the four enforced controls and how review fits.
• The forge CLI — the full forge review start|finalize|validate synopsis.
• The circuit-breaker — the iteration gate that bounds the implement loop.
• Spend Budget — the spend gate that runs alongside review.
• Change Governance — how reviewed changes move to delivery.