If every round of checking finds a new kind of problem, the work is probably not getting worse. The checking is too narrow. One dimension at a time guarantees an endless stream of findings. One independent audit against a fixed checklist ends it.
I learned this on a data-heavy deliverable that went through round after round of "check it again." The fix was not a better round. It was a checklist written before the work started, run once by someone who had not built it, followed by a rule that the file is final.
The moment: round after round
The deliverable was a large sheet: many rows, each with a price, a size, a store, a date and a source link. After the first build, someone asked for a check of the prices. Problems turned up, and they were fixed.
Then the conversation moved to the links, and the next round checked links. New problems. Fixed. Then sizes came up, and the next round checked sizes. More problems. Then the totals. Each round looked at whatever had just been discussed, and each round found a new class of problem nobody had looked for before.
From the outside it felt like the sheet was full of holes. From the inside it felt like the work would never end. Both feelings had the same cause.
Why narrow checks never end
A round that checks one column finds the problems in that column. It says nothing about the other columns. So the next round, pointed at a different column, finds problems that were there all along. They are not new. They are newly looked at.
Keep going one column at a time and you get a stream of findings that only stops when you run out of columns, if anyone keeps track of which columns are done. Usually nobody does. Fixes in one round can also break something a previous round had already passed, and no later round looks back.
There was a second problem. The same hands that built the work also checked it. A builder checks what they meant to do. They know which column a value was supposed to come from, so they read it as right. A fresh reviewer, with only the brief, sees what is actually there.
New findings every round usually mean narrow checks, not bad work. The fix is a full check, once, by someone else.
Write the checklist first
The checklist comes before the build, not after the first complaint. It covers every column and every rule of the deliverable, in plain language. For a price sheet it might say:
- Price: regular and sale in the right columns, no member or coupon prices.
- Size and count: match the package photo, one unit throughout.
- Store and date: present on every row, matching the page shown.
- Link: opens the store's own product page.
- Totals: every average recomputed independently, small samples labeled.
Written before the work starts, the checklist does a second job: it tells the builder what done means. Most of the errors a late audit would catch never get made.
Have someone else run it
Give the checklist to reviewers who did not build the work. Give them the brief, but not the build notes. The notes explain what the builder intended, and the point is to check what is there.
Split the rows into batches so each reviewer checks every column on their own rows. Do not split by column. Splitting by column brings back the narrow check in a new form.
Run the totals as a separate audit. Someone recomputes every summary figure from the rows, independently, and compares it with the sheet.
Reviewers report. They do not edit the deliverable. A reviewer's opinion goes in a verdict column, never into the answer, for the same reason I give in A Flag Should Be a Question, Not a Decision.
Five verdicts, with evidence
Every row gets a verdict, and every verdict carries its evidence: a screenshot, a quote from the page, the recomputed number.
- Pass. The row meets every line of the checklist.
- Error. The row was wrong when it was made. It gets fixed.
- Drift. The row was right when it was made, and the source has changed since. It gets a dated note, not a fix.
- No link. The source cannot be opened. The row stays, marked.
- Unverifiable. The reviewer cannot confirm or refute it. That is a valid verdict, and it is disclosed, not hidden or guessed.
Drift deserves its own verdict because it is not a mistake. Prices and pages change. Treating every change as an error is how a finished file gets reopened forever.
Fix, re-verify, freeze
After the verdicts are in, the steps are short:
- Fix errors only. Log drift. Send disputed calls to the person who owns the rule.
- If a reviewer's finding contradicts the original brief, it goes to the brief owner, not into the file.
- Recalculate the totals and re-verify every row that was fixed.
- Declare the file final, and put the date on it.
The last step is the one that ends the loop. Final means the file is reopened only on new instructions from its owner, not because someone has an idea for one more check. Later differences go in a notes log for the next version.
Where this fits with QA checklists
This is a close cousin of the problem in QA Checklists That Reset When Work Reopens. That piece is about rework slipping past a checklist that was only run once. This one is about the opposite failure: checking that never stops because there is no fixed checklist at all. Both have the same fix. Write the standard down, run all of it, and record when it was run.
What goes wrong
- Reviewers check only what they were told about. The full-column checklist catches this.
- The builder grades their own work. Use fresh reviewers with the brief only.
- Batches split by column. Split by row so every reviewer sees every column.
- Unverifiable rows quietly filled in. Keep the verdict and disclose it.
- Reopening forever. Final and dated, reopened only on new instructions.
The full method, with the checklist template, the verdict sheet and the freeze rule, is in The Final Check Playbook (PDF).
The takeaway
Write the acceptance checklist before the work starts, and have someone else run it. Every row, every column, one verdict each: pass, error, drift, no link or unverifiable.
Fix the errors, log the drift, re-verify what you fixed, and freeze the file with a date. Then stop. The next round of checking belongs to the next version.
Checking one thing at a time never ends. One full audit against a fixed checklist, then a final, dated file, does.