Proof · Engineering practice

How do I know every requirement has code and test coverage?

Start with an explicit inventory of applicable requirements. For each one, check the implementation link, required evidence, observed result and current revision. Report every missing or deferred obligation. Completeness is always relative to that inventory; a promise omitted from it cannot count as covered.

See the example Bring a change

The valid-payload test leaves rejection unverified

Illustrative requirement SYS-REQ-116: malformed input must be rejected without changing the store. A happy-path test only checks that a valid payload is accepted. Even if it executes most of the parser, it does not establish the rejection promise.

Case	Assertion	Initial evidence state
Valid payload	Accepted; intended record stored	Nominal test linked; inspect current run.
Malformed payload	Error returned; store unchanged	Negative case missing.
Partial write before failure	No partial mutation remains	Additional rollback scenario required if the interface permits partial processing.

// SYS-REQ-116:malformed_input:negative
func TestRejectsMalformedWithoutWriting(t *testing.T) {
    // Arrange a store with a known record and a malformed payload.
    // Call the real parser/store boundary.
    // Assert an error AND compare the complete store state before/after.
}

This is a test outline, not an executed result. Fill in the project’s real boundary, run it and retain its output. An annotation attached to an empty or unrelated test does not substantiate the requirement.

Check each required evidence cell

proof catalog show malformed_input
proof audit --check obligation_evidence_complete --verbose
proof audit --check tests_pass

The catalog, project overrides and requirement’s own evidence list determine the required cells. obligation_evidence_complete checks the class/evidence annotations and applicable provenance. Typed lemma, race and fuzz evidence needs durable run provenance. Ordinary nominal and negative annotations do not by themselves establish a passing execution.

Inspect both missing cells and the meaning of the existing tests. A requirement may need evidence at the system or interface level, rather than only unit tests on its children. For a testable stakeholder criterion, keep the direct acceptance evidence visible.

Include omissions and authorized exceptions

Reconcile the inventory with contracts, user-visible behavior, dependencies, hazards and earlier defects. Proof can hold recovered candidate intent beside retained requirements; resolve new or conflicting promises under the applicable policy before treating them as approved.

When a required test is not ready, record the gap and its owner. A justified non-applicability decision is different from deferred required work. Ordinary deferrals remain warnings. Tripwire-backed KnownIssue dispositions have their own policy and visible status; neither disposition is evidence that the behavior is fixed.

A clean set of existing links also cannot discover every missing requirement. Review the scope itself, particularly negative paths and assumptions that changed.

Make CI enforcement match the claim

proof audit --fail-level warn

This makes the severity threshold explicit. The CLI default is currently warn, with project configuration able to override an unspecified flag. To prevent merging on a failed audit, require the job for the candidate revision and restrict bypass permissions. Protect approved requirements, evidence and policy from unauthorized edits.

For review, keep the inventory and full results behind a concise summary. See the sample verification report and requirement-link consistency.