The shortcut at the review desk
Imagine you are the reviewer choosing a record for a development decision. A spreadsheet labels it “unflagged,” making it tempting to cite the row as evidence that the current requirement is satisfied. That shortcut can support the wrong conclusion: the label may describe an earlier check. The example below is hypothetical; its fields and values are illustrative, not reported test results.
What happened to R-17
Record R-17 contains a blank reviewer field. Under specification v1, that field was optional, so a completed check saved “unflagged” with checked_version=v1. Specification v2 then makes reviewer mandatory for records used in this decision.
You open the review sheet after v2 takes effect. In this example, opening the sheet displays the saved result without running the check again. R-17 still looks acceptable. Run the v2 check, however, and the empty reviewer field fails. The changed requirement explains the different outcome.
Check the rule behind the label
A saved status is like a tick in an older rulebook. It records a conclusion under particular instructions. Here, the failure comes from reusing a result after its governing rule changes.
Before citing R-17, compare checked_version with the specification governing this decision. Inspect reviewer in the exact record being selected. A version mismatch fails the check; a blank mandatory field also fails it. Fill the missing field from an authorized source or exclude the record. Rerun the current checks on any corrected record, then keep the new result with its specification version.
When the earlier result still applies
Change the hypothetical question: you are documenting whether R-17 met v1 when the original decision was made. If that decision explicitly used v1 and you have its unchanged record snapshot and completed check, the earlier result can support that limited claim. Decision rule: match the requirement version and record snapshot to the claim. Use a current check for a current claim.