Re-verify delivered work before you accept it
How to rule on work someone else reports as done: re-run the gates in your own environment, go to the source for load-bearing figures, look at the running thing rather than the builder's screenshots, and write a verdict that says what you personally checked.
Use when
- Use this when a delegate — an AI session, a contractor, another team — reports the work is done and hands you a summary of passing checks.
- Use this before writing any verdict that goes on a permanent record as accepted.
- Use this when the evidence offered for a visual or live change is the builder's own screenshots.
The failure
You accept a green number nobody reproduced. The count came from an environment you never ran, the pages were judged from captures the builder chose, and the one figure the whole acceptance rests on was copied out of the summary rather than derived from the source. The gap surfaces later in production, where it costs more and the record already says accepted.
The outcome
A written verdict carrying your own counts and measurements, which states what you re-verified yourself and which claims you took on report.
The Practice — 6 rules
Re-run the gates in your own environment
Run the delegate's own checks yourself before you read their summary of them. Print the counts and record them as a delta from the last accepted run, so the figures stay comparable across rounds.
Why A number that has never been reproduced outside the environment that produced it says nothing about the system, only about the report.
Go to the source for anything load-bearing
Read the security-critical and correctness-critical files in full rather than skimming the diff. Any figure the acceptance rests on is re-derived from the artifact that generates it — count the entries in the file yourself; do not lift the count out of the summary.
Why A diff shows what moved rather than what the code now does, and a quoted figure tells you what the delegate believed was there.
Look at the running thing, not at their captures
For anything visual or live, open the running system yourself, at the real widths and against the real origin. The builder's screenshots show the frames the builder chose, in the environment the builder had.
Why Reviewing a capture reviews the capture; the artifact a stranger will meet is the running one.
Measure before you rule
When something looks off-centre, off-axis or wrong, take the actual numbers before you write the finding. Measurement acquits as often as it convicts: an apparent offset can be an artifact of the capture tool, and some headless browsers crop a narrow window rather than reflowing it, so narrow screenshots lie. Put the measurements into the record, so the next round can be held to them.
Why A finding written from an impression sends the next session chasing a defect that may not exist, and spends the authority you need for the findings that are real.
Reconcile a difference; do not pick a side
When your numbers disagree with the delegate's, find out why before you rule. Re-run the disagreeing part in isolation, name the cause, and record both figures with the reconciliation between them. A single failing check that turns out to be a timeout under parallel load is a different verdict from a regression, and both differ from calling the report wrong.
Why The discrepancy usually carries the most useful finding in the review, and discarding either number throws it away.
Write the verdict, including what you did not check
State in the verdict what you personally re-verified — the checks you ran, the files you read in full, the widths you looked at — and state which claims you are accepting on report. Where you had to produce a proof the delegate could not supply, say that too.
Why Months later nobody can tell reproduced evidence from repeated evidence unless the verdict separated them at the time.
Limits — do not use this when
- Do not use it on work you are still shaping in conversation; this is an acceptance method and it needs a finished claim to test.
- Do not use it where you cannot reach the running system or the source. Re-verification you cannot actually perform is theatre; write that you accepted on report instead.
- This establishes whether the reported work is real. It does not tell you whether the work was worth doing.
- Re-verification does not move responsibility onto the delegate. Once you write accepted, the result is yours.
- Scale the effort to what the claim carries. A small change does not earn a full re-run of everything; a figure the whole acceptance rests on does.
Verify — evidence that it helped
- The verdict contains at least one number you produced yourself rather than quoted.
- Every load-bearing figure in the verdict can be traced to the artifact that generates it.
- You can name the widths and the origin at which you looked at the running system.
- Any difference between your numbers and the delegate's is explained in the record rather than resolved silently.
- A later reader can tell from the verdict alone which claims were reproduced and which were taken on report.