Two axis review

A change can be beautifully built and still be the wrong thing; it can be exactly what was asked and still be built badly. One review that mixes both questions lets each failure hide behind the other's pass. Keep the axes separate.

Axis 1 — Craft

Does the change meet this project's own standards? Documented conventions first; beyond them, watch for the classics: duplicated logic, names that don't say what they mean, one edit scattered across a dozen files, abstractions nobody needed. (The canon here is Martin Fowler's catalog of code smells — flag by name, as judgment calls, never as autopilot rules.)

Axis 2 — Faithfulness

Put the original request next to the diff and check three things:

• Missing — asked for, not there (or half there).
• Uninvited — there, but nobody asked (scope creep hiding as initiative).
• Warped — looks implemented, but numbers/edge behavior/wording differ from what was specified. Check the exact values: limits, thresholds, orderings, legal wording.

The reviewer is never the author

Two passes from one model are one pass with extra steps. It reviews toward the assumptions it wrote with.

• A different model, not just a different chat. Reviewers on both axes come from another model family or another tier than the author. A fresh context on the same model clears the memory, not the blind spot — what it failed to imagine while building is what it fails to look for while judging.

• The reviewer gets the ask, the diff, and the test output — nothing else. No author commentary, no "here's why I did it this way", no defense of the hard part. That narrative is precisely what drags a fresh model back into the author's frame. If a diff can't be judged without the author's story attached, that itself is an Axis 1 finding.

• Review at or above the difficulty of the work. Swap family or swap tier, never drop below the job: top-tier author, flagship reviewer, or the reverse. The smallest model is for mechanical passes — wording checked against the spec line by line, links, formats, checklist coverage. Aim it at architecture or business logic and you have staged a review, not run one.

• Bake it into the default roster. Author on one strong model, reviewer on a different one, as the standing configuration — then heterogeneity survives the day you are rushed and would otherwise have reused whatever was already open.

The same rule from the testing side: red-light-first. Tier assignment: model-tiering.

The orchestrator is an author too

Everything above governs work that was dispatched, which leaves the largest hole open: what the main session writes itself. Postmortems, conclusions, readings of the data, acceptance reports, final external copy — the orchestrator drafts them, checks them, and hands them over with no second party ever in the loop. Rereading them inside the context that produced them is not a review; it is the same blind spot getting a second look at itself.

Send out for review — anything the founder will decide on, or that goes outside:

• Incident postmortems and root-cause writeups.
• Readings of metrics or test data — the numbers, and what you claim they mean.
• Feasibility and go/no-go conclusions.
• Acceptance and sign-off reports ("this is done, here is the proof").
• External copy and public materials in final form.

Don't — or every sentence becomes a dispatch:

• Routine status updates and progress notes.
• Relaying a conclusion a sub-agent already had independently verified — it has been reviewed; don't review the messenger.
• Small reversible changes.

How. Another model family or another tier, same as any reviewer. Hand it the raw material — the original ask, the raw data, the untouched command output — plus the artifact under review. Hand it none of your reasoning and none of your justification. Its one question: where does the conclusion outrun the evidence?

Escape valve. When timing genuinely rules out reviewing first, the artifact reaches the founder stamped not independently reviewed — on the artifact, in plain words, before they act on it. Late is survivable. Unmarked is not.

The report the founder trusts most is the one nobody checked.

Rules

• Run the two axes as separate passes with fresh eyes (two sub-agents, or two sittings) so they can't contaminate each other — and neither pass is run by the model that wrote the change (above).
• Report per axis; don't average them into one score. "9/10 craft" never buys forgiveness for "wrong feature".
• Adversarial rounds cap at 2 (see dispatch-economics). Findings must quote the line they're about.
• Our first run of this review caught a legally sensitive one-word deviation ("we" vs "I" in a compliance sentence) that CI and human eyes had both passed. Exact-wording checks pay.

Success criteria

Two written verdicts, one per axis, each citing evidence, neither produced by the author's model. Every finding is either fixed or explicitly accepted with a reason — none silently dropped. Every artifact the founder will act on either cleared a reviewer from another family or tier, or arrived carrying the words not independently reviewed — there is no third option.