Check reference

Require property examples only where they are used

Z3-derived fixtures make a model easier to inspect and test. property_fixtures_exist checks their presence only where the project explicitly treats them as required artifacts.

The default is opt-in

The check is disabled by default. Enable project.checks.property_fixtures_exist.enabled and list components under project.verification.fixture_evidence.components to require examples for applicable Z3-backed variables. A variable-file read or parse error in the opted-in scope is a failure to evaluate the policy, not permission to assume no fixtures are needed.

Illustrative example: a quota boundary

A model separates quota available from quota exhausted. Concrete examples near the boundary help a reviewer see whether equality belongs to the exhausted case.

quota_used  quota_max  Expected modeled case
9           10         available
10          10         exhausted
11          10         exhausted

These values are illustrative. They are neither solver output nor evidence that the implementation handled them. If the input domain excludes usage above the maximum, explain that assumption explicitly and test the boundary where the assumption is enforced.

Generate examples, then review their use

Fix unreadable declarations first. Generate the property fixtures for the named component and review their values, provenance and expected outcomes. A source test should then feed appropriate cases into the implementation and assert the intended behavior. Store the actual test result separately from the generated JSON.

proof proptest specs/system quota --source z3 --output tests/quota/
proof audit --check property_fixtures_exist --verbose

If the examples are only an optional debugging aid, revise the controlled-evidence configuration rather than manufacturing unused files.

Do not infer a proof from file presence

The proof results live in property, constraint-coverage and behavioral-implication checks. A missing fixture does not mean a theorem failed; a present fixture does not mean a theorem succeeded. Freshness is also separate: examples generated before a domain change can be present but obsolete. Keep these distinctions visible in review so one green artifact check does not stand in for the rest of the evidence.

Follow the evidence

Require these fixtures only when someone or some test actually consumes them.

Review one property-fixture workflow. Bring the model, generated examples and consuming tests so we can distinguish artifact presence from proof results and executed evidence.

Inspect property verdicts · Check generated evidence freshness