The failure mode
A worker reports that tests passed. A reviewer sees the report and approves. Meanwhile the source has changed, or the test ran against a different build. Both people may be acting honestly, yet the approval is attached to the wrong artefact. The missing element is not more confident prose; it is a stable relationship between input, check and output.
A minimal evidence bundle
Keep the source version, command, exit status, relevant output, observation date and checked scope. A hash identifies bytes; it does not prove the bytes are correct. A successful HTTP response proves reachability; it does not prove every interaction works. A browser screenshot supports a visual claim but cannot prove backend authorization. Match each claim to the observation that can actually establish it.
Handle drift explicitly
Freeze criteria before the check. If the artefact changes, mark version drift and repeat the relevant checks on the new version. Keep the earlier receipt as historical evidence instead of silently replacing it. This makes disagreement resolvable: reviewers compare the same version and the same acceptance criteria rather than debating incompatible summaries.
Try it in the operator path
The learning exercise below asks whether an implementation can be accepted from a specification alone and what to do when a checked source changes. These are small decisions with large operational consequences. The goal is a repeatable review habit. Completing the exercise is browser-local practice, not a professional certification.
Sources and boundaries
Adapted from the project operator wiki and recorded engineering evidence, observed 15 October 2026. Practical recommendations are distinguished from scoped implementation results.
Read the related evidence wiki →