Request review while the decision is still reversible.

A review often arrives at one of two bad times. At the beginning, there may be little evidence to inspect. At the end, the approach may already be spread across code, data and documentation. The useful moment sits between them: enough has been built to expose the important choices, but changing direction is still affordable.

I call that moment a review checkpoint: a planned pause before completion where another person or agent examines one consequential decision against agreed success criteria. It is not a request for general encouragement, and it is not necessarily a release approval. Its purpose is to find errors while the work still has options.

People can become attached to work they have polished, but that is not a universal law and it is not the main control. Early review works because information has arrived while decisions remain reversible. The discipline of finishing a branch well begins by placing checkpoints before the expensive commitments, not by guessing how defensive its author will feel.

“Looks good?” is difficult to answer well because it hides the decision. A practical request supplies five things: the context, the success criteria, the risk, the evidence already collected and one exact question. Success criteria are observable conditions the work must meet. Evidence might be a test result, browser recording, database query or before-and-after example.

Here is a complete hypothetical request made at a checkpoint for an automatic invoice-reminder feature:

Context: Finance currently sends reminders manually. The proposed job selects invoices seven days overdue and sends one reminder each morning.
Success criteria: paid, disputed and opted-out invoices receive nothing; an eligible invoice receives no duplicate reminder; every send is recorded.
Primary risk: a payment may arrive after the job selects an invoice but before it sends the message.
Evidence: the four eligibility tests pass; rerunning the job does not duplicate a reminder; a staging run records the expected audit event.
Exact question: “Could an invoice paid during that selection-to-send gap still receive a reminder? Please trace that path and name the test that would prove your answer.”

The reviewer traces the path and answers: “Yes. The duplicate guard prevents a second reminder, but eligibility is checked only when the invoice is selected. Recheck payment and dispute status immediately before sending, then add a test that inserts a payment between selection and send.” The author makes that change, the new test fails on the old version and passes on the revision, and the checkpoint closes with evidence. The review changed the design before the job was enabled for customers.

This is harness engineering in a modest form. The request shapes what the reviewer can inspect, and the evidence gives disagreement somewhere concrete to land. The exact question focuses attention without forbidding the reviewer from raising another serious risk.

The same structure helps a human reviewer or an AI verifier. An agent can inspect code and run evidence-producing tools, but a fluent answer is not itself evidence. For consequential work, the reviewer should report what it examined, what passed or failed and what remains uncertain.