Check reference

Check whether a witness reaches its implementation

An annotated test can assert a constant and exercise no product behavior. obligation_witness_grounded looks for witnesses that do not reach the implementation they claim to support.

What the check observes

A direct reference to an implementation symbol passes the static grounding filter. Suspects are checked for eligible test carriers, then supported tests run individually under coverage to intersect executed spans with the requirement's implementation symbols. Go coverage production is wired; unavailable build or language support remains advisory. Per-witness isolation prevents one real test's coverage from hiding another test that reaches nothing.

Example: the assertion never calls the product

Illustrative case. A test declares a lifecycle witness but only copies true into another variable. The annotation is present and the assertion passes, yet no implementation is exercised.

// SW-REQ-042:lifecycle:nominal
func TestLifecycle(t *testing.T) {
    started := true
    configured := started
    if !configured { t.Fatal("not configured") }
}
// Repair: call the governed implementation and assert its result.

Resolve the finding

  1. Read whether the finding concerns a non-test carrier, an empty execution, a wrong implementation link, or missing coverage.
  2. Move an invalid claim to a real test, correct a mislinked requirement, or write a witness that exercises the actual behavior.
  3. Use an out-of-process evidence type only when the evidence genuinely has that shape. Retain unavailable coverage as a limitation instead of counting it as verification.

Run and interpret

proof audit --check obligation_witness_grounded --verbose

This implementation-stage check defaults to warning. Evidence types marked coverage_trackable false are exempt; shipped examples include integration, fuzz, and differential evidence. Suspect execution can build and run tests.

Grounding is weaker than a sufficient oracle. A static reference is accepted without the coverage step, and executing one relevant line does not prove the assertion checks the requirement. A passing test can still accept incorrect output. Review assertions, input partitions, and regression relevance separately.

Continue from here

Check evidence-cell presence. Design meaningful assertions.

Bring a test that is linked to a requirement but may not test its promise. Bring a change to Proof.