Reuse verification until its assumptions change

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

Use case

Parser tests passed for current code, fixtures and locked dependencies, then README wording changed. Retain parser evidence while checking documentation; executable examples may affect a different scope.

Mechanism

Record command, code/test/dependency identity, environment and scope for successful checks. Assess whether edits change those assumptions. Pure prose needs documentation checks; parser logic, fixtures or behavioral examples need affected-path tests. Shared dependencies/external state can invalidate evidence without source changes. Record reuse reasons and rerun triggers, stopping purposeless repeats once requirements pass.

Bad example

Repeatedly run the unchanged full build for reassurance, or never test an executable example because only README changed.

Good example

Retain success bound to unchanged parser/fixtures and check pure README wording as documentation. Revalidate affected examples, inputs, dependencies or logic. State reuse scope and invalidation rules instead of extending an old pass over new code.

Why the change matters

Evidence is useful when assumptions still hold, not because it repeats. Invalidation rules direct effort to actual changes while preventing under-testing consequential documentation edits.

Observable expectation

Teaching prose-only edits reuse parser results; altered date syntax in an example needs that input checked; dependency upgrades require reassessment even with unchanged code. Distinguish reuse from new execution rather than refreshing old timestamps.

Limits

Nondeterminism, service state, platform configuration or security databases can require refresh. Reuse is not a test ban; required project checks still apply. Resolve uncertain assumptions rather than infer impact from filenames.