Check reference

Check the evidence required by each obligation

A requirement can have tests and still lack the kind of evidence its obligations need. This check evaluates the required evidence cells for each obligation-bearing requirement.

What the check observes

The required set combines class and project evidence rules with a nominal positive-witness floor at implementable levels. Stakeholder acceptance is a separate level of evidence. Ordinary nominal or negative annotations establish that a witness is declared; they do not themselves show a passing run. Lemma, race, and fuzz claims additionally require eligible carriers and durable passing execution provenance for the claimed lane.

Read a complete cell as a specific claim

Evidence state	What it supplies	What it does not establish
Ordinary nominal or negative witness annotation.	A declared link to a requirement, obligation class and evidence kind.	That the test ran, passed or asserts the right behavior.
Lemma, race or fuzz annotation alone.	A claim about a typed verification method.	Eligible evidence without the required carrier and passing execution provenance.
Eligible typed carrier with current passing provenance.	Support for that required cell under the configured method and scope.	The completeness of all obligations or correctness of the whole system.
Reviewed suppression, exemption or tracked debt.	An explicit disposition that may change how a required cell is evaluated.	A newly executed pass or a fixed defect; inspect the reason and scope.

Read the resolved evidence requirements before treating a missing race or lemma result as a universal error. Language support and configured execution methods matter. For example, the current implementation can relax the race requirement for a non-Go context without a configured race/ThreadSanitizer method; Go or an explicitly configured method retains it. Explicit project opt-in can also require that evidence. Such a relaxation does not produce race evidence.

Example: a concurrency test ran without the race detector

Illustrative case. In a Go implementation context, the requirement carries concurrent, and a test has a race annotation. A normal test run cannot establish that the race lane was used. The evidence needs the configured race-capable command and its valid run record.

Obligation: concurrent
Required cells: nominal + race
Nominal witness annotation: present
Race annotation: present
Eligible race carrier and passing run provenance: still required

Resolve the finding

Inspect which requirement/class/evidence cell is missing and read the class's intended verification method.
Write or correctly link a witness that exercises the governed behavior. For typed lanes, run the configured producer and retain its current provenance.
Keep required but unfinished evidence as visible debt. A suppression means non-applicability, while a known-issue disposition records unresolved behavior and must not be described as a fix.

Run and interpret

proof audit --check obligation_evidence_complete --verbose

The check defaults to warning; project.audit.evidence_strict: true promotes its findings to errors. The fuzz execution lane is opt-in through the audit or verify fuzz option; an annotation does not run it. Overlay-audit mode also requires source triples to fall within accepted verification scope.

Complete cells do not prove the assertions are strong enough. Ordinary annotation presence, actual execution, requirement satisfaction, and closure of a defect class are separate claims. A focused evidence check also cannot establish that the requirement's obligations were complete in the first place.

Continue from here

Check witness grounding. Inspect normalized evidence profiles.

Bring one requirement whose evidence count looks complete but whose behavior remains uncertain. Bring a change to Proof.