Evidence-Bound Verification Rule

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

You have changed a patch and need to report its verification status. This teaching project uses node --test tests/retry.test.mjs for the affected retry behavior. The check must cover the changed revision, and its exit code and results are readable. A passing record for an older revision does not automatically cover this patch.

Mechanism

Name the rule: without matching verification evidence, do not claim a pass. Identify the relevant check, execute the full agreed command, inspect the exit code, failures and scope, then state the result. Report failure when it fails and unverified with a reason when it cannot run. Respect higher-priority execution restrictions and adjust the delivered status rather than inventing a pass.

Bad example

After finishing the patch above, try to run node --test tests/retry.test.mjs if there is time. If it looks fine, say it passes.

Good example

Verification rule: before claiming this patch passes, run node --test tests/retry.test.mjs and inspect its exit code, test count and failure output. Identify the command and revision. Claim a pass only when the result supports it. Report failed cases, or unverified plus the reason if execution is unavailable or explicitly restricted. After another relevant code change, recheck the affected behavior.

Why the change matters

Try and looks fine permit confidence to replace an observed status. A named rule binds the claim to a check and revision, letting readers distinguish code written, a check executed and a check passed.

Observable expectation

Classify three teaching records: exit 0 with 3/3 passing means this check passed; exit 1 with 2/3 passing means failure; a missing command means unverified with the environment gap reported.

Inspect the actual command and revision in the report, and reject a pass derived from failure or non-execution. Even a pass covers only the behavior examined, not every platform or the entire system.

Limits

Bind the rule to relevant agreed checks, not unrelated full suites justified by forceful wording. User restrictions, missing environments and valid existing evidence affect execution steps but do not turn unknown results into known ones. The teaching records are not actual test results from this project.