# Evidence and Verification Contract

## Purpose

Convert implementation claims into observable checks and retain the evidence
needed to assess them later.

## Claim-to-proof discipline

Every non-trivial change should be expressible as:

```text
Claim: the behavior expected after the change.
Observable: a result that would be different if the claim were false.
Check: the smallest test, command, fixture, or inspection that observes it.
Evidence: the exact result, target, and source version.
Invalidation: a later mutation that makes the evidence stale.
```

A successful build proves compilation and linkage. It does not by itself prove
runtime behavior, context delivery, data preservation, update semantics, or UI
rendering.

## Test selection

- Prefer an executable behavioral test that naturally reaches the changed path.
- Use a regression fixture that reproduces the actual failure mode.
- Test both the desired outcome and the important negative condition.
- Keep a focused test close to the defect; run a broader build/test layer when
  risk or repository policy requires it.
- Source-string checks are acceptable for narrow wiring or explicitly forbidden
  regressions, but are weak evidence of behavior and should not substitute for
  a runtime harness.

## Verification states

- `planned`: a claim has a proposed check but no result.
- `passed`: a current check directly supports the claim.
- `failed`: a check disproved the current implementation or exposed a gap.
- `stale`: a later relevant mutation invalidated an earlier pass.
- `unknown`: no meaningful proof has yet been selected or completed.

## Non-coercion rule

Verification evidence should guide completion truth. It must not become a
generic tool gate that prevents exploration, editing, or legitimate diagnosis.
An incomplete proof is a visible fact, not permission to fabricate a failure.