Problem
A review can be correct about the files it saw and still say little about a later build. If the candidate changes after review, its earlier approval no longer describes the same work.
Method
Record which candidate each reviewer inspected, what evidence they used and their verdict. Keep the builder separate from the independent review. When a relevant file changes, identify the affected checks and repeat them against the new candidate.
Verification and receipts
A useful review record joins the candidate identity, scope, checks, objections and final disposition. “Reviewed” without that context is too broad. The earlier draft refers to the Semmy review sequence; its public receipt extract has not yet been cleared.
Production behaviour
Before publication, compare the reviewed candidate with the version actually released. A successful build or a pushed branch alone does not prove that customers are using that version.
Failure modes and rollback
Reviewers can share blind spots. A hash identifies bytes, not correctness. A rollback also needs a known earlier candidate and a check that its dependencies still work. These are reasons to keep test evidence and human decisions alongside the verdict.
Limits
Two independent reviews can expose different problems, but this draft does not measure a reduction in defects. It makes no claim that a particular model score predicts reliability.
Disclosure
Publish the review scope and a safe evidence summary. Keep private prompts, customer records and operational detection rules out of the article and its attachments.
Your next step
See the work in context.
Explore the projects and questions behind the approach.
Explore our work ↗How plans work ↗