Open the guide

How to review AI-built work when you cannot inspect every line.

A practical way to review AI-built work without pretending to perform a code audit.

What evidence do I need before I approve an AI-built artifact?

Status
working
Version
0.1
Reviewed
Jul 28, 2026
Read the work

What this gate is for

AI can let you build beyond your ability to inspect every line. That does not remove your responsibility. It changes the kind of review you need.

This gate does not certify code quality, security, legal compliance, or production readiness. It helps you decide what evidence to demand and whether the next move should be to proceed, investigate, revise, pause, or stop.

Use it before approving a prototype, workflow, agent, website, analysis, or automation.

Gate 1: Consequence

Write one sentence:

If this works, who will do what differently, and why does that matter?

Ask:

  • Is the desired change specific?
  • Is the problem real without mentioning AI?
  • Would we still want the consequence if a different tool produced it?

If you cannot name the consequence, do not review the implementation yet. Choose revise or stop.

Gate 2: Boundary

Ask the builder to show:

  • exactly what changed
  • what did not change
  • what the AI or agent produced
  • what a person reviewed
  • which systems, users, and data are affected

You do not need to understand every file. You need to understand the boundary of the decision you are making.

If the boundary keeps expanding during the explanation, choose revise.

Gate 3: Proof

Ask for evidence proportionate to the downside:

  • Can I see the artifact working?
  • Can I see the changed files or configuration?
  • Which checks actually ran?
  • What did those checks prove?
  • What important thing did they not prove?
  • Does live behavior match the report?

Do not accept:

  • “the agent said it passed”
  • screenshots without a current URL or state
  • a successful build presented as evidence of usefulness
  • a task marked complete without inspectable results

If proof is missing but the consequence still matters, choose investigate.

Gate 4: Downside and recovery

Ask:

  • How can this fail?
  • Who or what is harmed if it is wrong?
  • Is the change reversible?
  • What is the rollback?
  • What data, money, reputation, access, or customer trust is exposed?

If the downside is material and the rollback is unclear, choose pause.

Gate 5: Ownership

Name one person who owns:

  • the decision to release
  • the response when it fails
  • the next review date
  • the decision to scale, revise, pause, or stop

“The model”, “the agent”, and “the vendor” are not accountable owners.

If no person owns the downside, choose pause.

Make the decision

Proceed

Choose proceed when the consequence is clear, the boundary is contained, proof is proportionate, the downside is understood, rollback exists, and an owner is named.

Proceed means approve the next bounded step. It does not mean scale automatically.

Investigate

Choose investigate when the problem matters but one or more factual questions remain unanswered.

Name the missing evidence and who will return it. Do not use investigate as an indefinite holding state.

Revise

Choose revise when the consequence is worthwhile but the current intervention is too broad, too complex, poorly bounded, or aimed at the wrong constraint.

Return with a smaller intervention and a clearer proof plan.

Pause

Choose pause when ownership, downside, privacy, security, or rollback is not adequate for the next move.

State what must become true before work resumes.

Stop

Choose stop when the consequence is not valuable, the problem is invented, the cost exceeds the likely value, or continued building has become avoidance.

Stopping is a successful review outcome when it prevents unjustified work.

The one-page review record

Complete this before the decision:

Desired consequence:
Current constraint:
Change boundary:
Evidence inspected:
Important uncertainty:
Material downside:
Rollback:
Accountable owner:
Decision:
Next review or action:

Do not calculate an aggregate score. A strong demo cannot cancel an absent owner. Good code cannot cancel an irrelevant consequence. A low-risk prototype does not need enterprise ceremony.

The weakest consequential gate determines the next move.

See the fieldwork

Read the first experiment that produced this review gate.

Open the instrument

One-page review record

Decision