# 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](/harness/overview): they return non-zero until the receipt validates.

::: details 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

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

```mermaid
flowchart LR
    A[review start] --> B[lenses run]
    B --> C[refuter / Judgment Day]
    C --> D[review finalize]
    D --> E[content-bound receipt]
    E --> F[review validate --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.

::: info 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:

```sh
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.

::: warning This is an enforced gate
`forge review validate --gate <gate>` is one of Forge's four [enforced controls](/harness/overview). It returns non-zero until the content-bound receipt validates against live Git evidence — it bounds **delivery**, regardless of what the agent narrates.
:::

::: tip Where review fits
Review is the delivery Sensor: the [circuit-breaker](/harness/circuit-breaker) bounds iterations, the [budget](/harness/budget) bounds spend, and review bounds what actually ships. See the [enforcement doctrine](/harness/overview) for the full picture.
:::

## Next steps

- [The enforcement doctrine](/harness/overview) — the four enforced controls and how review fits.
- [The forge CLI](/reference/cli) — the full `forge review start|finalize|validate` synopsis.
- [The circuit-breaker](/harness/circuit-breaker) — the iteration gate that bounds the implement loop.
- [Spend Budget](/harness/budget) — the spend gate that runs alongside review.
- [Change Governance](/features/governance) — how reviewed changes move to delivery.