Adversarial Review Loop

Adversarial Review Loop

Produce artifacts that survive hostile scrutiny by hiring your own hostile scrutiny first. The author of an artifact is the worst-positioned person to find its flaws: they know what everything is supposed to mean, they anchor on their own choices, and their context is contaminated by hours of drafting. This skill fixes that by spawning reviewers who have none of that context and every incentive to reject.

The loop was extracted from a government-proposal workflow where it repeatedly caught blockers the drafting agent could not see (a missing mandatory form, an hour model 2.4x too light, claims a public URL contradicted). It generalizes to anything.

The Loop

Run heavy adversaries at milestone endpoints, not after routine edits. A review milestone is a coherent artifact state worth grading: the first complete draft, the end of a substantial rewrite or repair batch, and the final readiness gate. Batch sentence, paragraph, table, and formatting changes; run cheap deterministic/source checks while editing; then freeze one revision for the next clean-room review. Do not spend a new adversarial call on each incremental change. Break this rule only when a single edit materially changes a compliance, price, security, legal, or safety boundary and immediate independent review would prevent substantial rework.

For proposal/bid reviews, the reviewer must receive the complete controlling package: listing/detail record, solicitation, all attachments, amendments, notices, Q&A, pricing forms, and incorporated terms. If the source package is incomplete, stale, or unbalanced, the artifact cannot receive CLEAN or be called submission-ready; return the source gap as a blocker before judging proposal compliance.

1. Build the artifact (or receive it).
2. Spawn a fresh clean-room reviewer on the graduated model ladder below. It returns findings and a verdict.
3. Judge the review yourself — it is adversarial input, not gospel. Fix the real findings; reject the bad ones with a written rationale.
4. Batch all accepted repairs into the next coherent milestone artifact, then repeat from step 2 with a brand-new reviewer. Never send a revision back to the reviewer who requested it — an agent that suggested fixes will approve its own suggestions, and its context is now contaminated by round one.
5. A round passes only when the adversary explicitly returns CLEAN with zero controllable findings. "Looks good," a score, silence, timeout, or gated-only prose without a verdict is not a pass.
6. After a value-tier reviewer passes, graduate the exact rebuilt artifact to a fresh flagship reviewer. Stop only when the flagship reviewer returns CLEAN, or when every remaining finding is genuinely impossible or authority-gated (missing credentials only the user holds, evidence that does not exist, decisions only the user can make).
7. If the flagship finds a controllable defect, fix it, return to fresh value-tier rounds until clean, then graduate again to a new flagship reviewer. Never ask the same reviewer to approve its own fix.
8. Keep a dated loop log: round number, model tier, reviewer roles, sources given, findings, fixes made, findings rejected and why, residual gated items. Report the round count when done — "clean in 3 rounds; flagship clean in round 4" is information about the artifact.

Graduated Model Ladder

• Use a capable value-tier model for iterative defect discovery and repair; select whatever mid-tier model your runtime offers at medium/high reasoning.
• Do not spend the flagship model on every early round. Continue with fresh value-tier reviewers until one explicitly returns CLEAN.
• The graduation reviewer uses the strongest available flagship model and high enough reasoning for the consequence level: maximum reasoning for proposal-final, production, security, financial, or legal-adjacent artifacts.
• Model cost never relaxes clean-room, source-first, or output-contract requirements. The flagship is a final independent gate, not a ceremonial confirmation.

Reviewer Construction (this is where the value lives)

• Match the ladder. Value-tier reviewers must still be capable enough to reason over the full source package. The final graduation reviewer must be the strongest available model. Record the observed model/tier in the loop log; do not pretend a requested model ran when the runtime did not confirm it.
• Clean room. The reviewer gets NO chat history, no drafts, no prior reviews, no author reasoning. Contaminated context reproduces the author's blind spots — the whole point is a mind that hasn't seen the sausage being made.
• Source-first briefing. Give the reviewer: (a) the controlling sources — the spec, RFP, brief, requirements doc, design system, or user instructions the artifact must satisfy; (b) the artifact itself; (c) verified facts it needs (truth files, constraints, deadlines). Never give it your conclusions, your price, your rationale — those anchor it.
• Hostile mandate. Prime it explicitly: its job is to find reasons to reject. Ask for evaluator-visible weaknesses, unsupported claims, contradictions with sources, internal inconsistencies, missing mandatory items, math errors, and layout/rendering defects. Tell it not to pad: "if something is fine, don't mention it."
• Anti-churn clause. Instruct reviewers to flag only defects that cost real outcomes — points, money, users, correctness, credibility — not taste. Without this, each fresh reviewer restyles the artifact to personal preference and the loop never converges. Style feedback is allowed only when the role explicitly owns style (see roles).
• Output contract. Numbered findings, each with severity (BLOCKER / MAJOR / MINOR), exact location, why it costs something, and a concrete fix. Then a verdict: CLEAN, or NOT CLEAN with the fixable count. Then a separate list of impossible/authority-gated items so they don't recirculate as "findings."
• Tell it what NOT to flag. List the known authority-gated items up front (signatures pending, decisions the user owns) so rounds don't waste findings on them.

Roles — fit the reviewer(s) to the artifact

One reviewer with one hostile mandate is the default. Give the reviewer a formal role when the artifact has distinct failure surfaces, and use SEPARATE clean rooms when two roles would contaminate each other (an estimator who has seen the price is no longer estimating).

• Proposal / bid: one reviewer as the buyer's evaluator (compliance, scoring rubric, claims vs. evidence) and, separately, a CTO/head-of-delivery producing an independent effort estimate with no dollars — compare it against the artifact's claimed effort. A CFO/risk officer and a sales/capture agent complete the pricing picture when price is at stake.
• Website / UI / visual design: a design reviewer and a content reviewer, both instructed to trend STRONGLY toward minimalism — less content, fewer elements, more whitespace, peace on the eyes. Their mandate: everything that can be removed is a finding; every element that fights another element is a finding. Visual artifacts must be reviewed with eyes: render to screenshots/PDF pages and inspect them — text extraction cannot see overflow, collisions, or misalignment.
• Software: a maintainer-reviewer (correctness, edge cases, tests, readability of the diff) and, where exposure exists, a security reviewer with an attacker's mandate.
• Documents / decks / analysis: the intended audience as a role ("tired evaluator at noon," "board member with four minutes"), plus a fact-checker who verifies every claim against the cited sources — following URLs and opening files, not trusting the text.

Fixed-Layout Visual Gate

PDFs, proposals, buyer forms, contracts, resumes, and decks require an eyes-on render pass before the value-tier CLEAN can graduate:

1. Rasterize every final page at a readable print resolution (normally 144-200 DPI). Inspect a contact sheet for sequencing/density and each page full-size for clipping, overlap, overflow, broken tables, orphaned headings, blank pages, bad page breaks, and diagram-label escape. This is the fixed-layout analogue of responsive-design; do not run a ten-viewport suite for print.
2. Inspect forms and signature pages at higher zoom. Typed inputs must sit inside their intended fields with consistent vertical centering, horizontal alignment, font size, and padding. Checkboxes/radio marks must be centered and unambiguous.
3. Any placed signature must preserve aspect ratio and sit naturally on or immediately above the buyer's signature line, without floating far above it, crossing labels, obscuring the line, or colliding with the printed name/title/date. Dates and initials must align with their own fields.
4. Compare the rendered exact buyer form to its blank original so field placement, pagination, labels, and legal text remain intact. Text extraction/OCR and PDF metadata checks cannot pass this gate.
5. After any visual repair, rebuild and rerender every affected page. Record the render directory, resolution, pages inspected, and result in the loop log.

Escalation and Convergence

• If two consecutive fresh reviewers find new BLOCKERs, stop patching: the artifact's foundation is wrong. Rebuild the failing section rather than sanding it.
• If a fresh reviewer contradicts the previous round's accepted fix, the main agent decides — that's the orchestrator's job. Log the conflict and the ruling.
• Typical artifacts come clean in 2–4 rounds. If you're past round 5 on fixable findings, either the anti-churn clause is missing from your reviewer prompts or the artifact needs the rebuild rule above.

Variant: pre-work anchors

The same clean-room machinery works BEFORE building, not just after: for estimates, pricing, sizing, or plans, spawn independent clean-room agents (e.g., effort estimator, risk officer, win-focused seller) who each answer without seeing your draft numbers, then orchestrate their anchors into the decision. An author who prices first and reviews later will drag every reviewer toward their anchor; agents who never saw the anchor cannot be dragged.

Reporting

When the loop ends, tell the user: rounds to clean, the most consequential findings caught (with severity), what was rejected and why, and any residual authority-gated items with exactly what the user must do about them.