5. Evidence and examination

5.1 Match evidence to the claim

Evidence supports a claim under identified conditions. It does not become stronger through repetition, formatting or a more formal record name.

Verification examines conformity to specified requirements. Validation examines fitness for intended use. A structural check can establish that an artifact follows a schema. It cannot establish that the represented engineering meaning is correct.

A source comparison can establish fidelity to the source while leaving the source itself unverified. Several agents can agree because they inherited the same mistaken assumption. The common basis may need independent examination.

For every consequential claim, ask what observation or reasoning could establish it. If the proposed check answers a different question, change the examination or qualify the claim.

5.2 Select assurance by consequence and detectability

A routine reversible edit may need only inspection or direct exercise. A wrong numerical result, data loss or permission error may remain plausible until serious consequences occur. These conditions justify stronger and often independent checks.

Consider what the check detects, whether another check already covers it, its cost, and whether the failure would otherwise become visible in time. A cheap oracle that usually passes can still protect an important boundary.

Testing every component broadly after every change can consume effort without adding warrant. Testing only the edited file can miss a consumer whose behavior depends on it. Affected selection should follow actual dependencies, including shared fixtures and indirect inputs.

Required professional, contractual and project examinations remain applicable. Proportionate verification is not permission to discard an inconvenient adopted criterion. It is a way to choose suitable assurance within authority and to expose conflicts when requirements need reconsideration.

5.3 Preserve independence where it matters

When reviewing, examine the actual candidate and governing criteria. Do not merely confirm the author's account. When arranging review of your own work, give the reviewer access to that basis. Independence includes preparation and assumptions, not only a different agent name.

Where several contributors use one oracle, independently inspect the oracle's relevant assumptions and coverage when consequence warrants it. Agreement with a shared basis establishes consistency, not the basis's correctness.

A reviewer returns a precise finding, its evidence and consequence. The contribution owner repairs the work. The reviewer who raised the finding normally checks the repair and affected behavior. A new reviewer is useful for a concrete competence, independence or assumption problem, not as a routine review of reviews.

Review must not become an approval stop above every harmless operation. Arrange it where the risk and governing requirements need it. Small work can remain small while still receiving adequate examination.

5.4 Identify the actual candidate

A result needs an identifiable subject. A moving branch name alone may be insufficient. A commit, retained artifact revision or other stable identity can identify what was examined.

Record the relevant inputs and environment at the level needed for the claim. A browser exercise does not establish native application behavior unless the required equivalence is itself supported. A fixture result does not prove the live integration used that fixture's assumptions.

Retain raw output only when a consumer needs it for examination or recovery. Keep bulky captures in suitable artifact storage when that meets the requirement. The current change record can point to them without copying every byte into the project tree.

Where evidence is missing, describe the limit. Absence from a searched folder does not prove an operation never occurred. A retrospective account can direct further inquiry without becoming contemporaneous evidence.

5.5 Reuse evidence without overstating it

Earlier evidence can remain valid when its relevant conditions have not changed. Examine changes to the requirement, inputs, implementation, check and environment before deciding whether a rerun is necessary.

Mechanical result reuse needs a trustworthy identity for the inputs that affect the result. A cache hit must identify the earlier result and must not claim that new tests ran. Near matches are not equivalent merely because they are convenient.

Human or agent assessment may still be needed where the relationship cannot be captured by a reliable executable condition. A tool should report facts and uncertainty rather than infer unsupported completion.

Repeated checking is justified by a changed or unresolved claim. It is not justified solely because another stage, agent or PR now carries the work. This distinction reduces cost while preserving the meaning of evidence.

5.6 Handle failures without changing the question

A failure can arise from the product, the test, the environment or the test's own assumptions. Preserve the observed result, establish a reproducible condition where possible, and identify the cause before claiming a repair.

Do not silence a failure by changing the expected result without a substantive reason. If the accepted criterion is wrong, bring that conflict to the person authorized to change it. A newly passing result does not itself authorize the criterion change.

A rerun that passes after a suspected timing race is evidence about variability. It does not prove the race was repaired. Report the distinction and choose further work according to consequence.

Continue unaffected work while a failure is investigated. A blocked acceptance claim need not become a claim that the whole project cannot proceed.