Check reference

Keep required scenario fixtures present

flip_fixtures_exist checks for generated scenarios where a project explicitly requires them. It answers whether that fixture artifact exists, not whether the implementation passed it.

Declare which fixtures are controlled evidence

The check is disabled by default. It applies to components listed in project.verification.fixture_evidence.components after its own enabled flag is set. Active formalized requirements in that scope need their FLIP fixture evidence. Retired, superseded and rejected requirements are excluded. An undeclared component can use generated scenarios as optional help without taking on this evidence requirement.

Illustrative configuration

A team uses generated scenarios when reviewing its retry controller. It opts that component in explicitly rather than treating every generated file in the repository as mandatory evidence.

project:
  checks:
    flip_fixtures_exist:
      enabled: true
  verification:
    fixture_evidence:
      components: [retry]

After a new retry requirement is added, missing fixtures mean reviewers cannot inspect the corresponding generated cases. That is an artifact gap. It is not yet evidence that the implementation is wrong or that an existing test failed.

Generate, inspect, then connect to tests

Generate fixtures for the affected component. Read the signals and expected results, and confirm the scenarios match the intended requirement. Then create or update source tests that drive the actual implementation through those cases. A fixture checked into the repository without a consuming test remains a model example.

proof testgen specs/system retry --engine heuristic
proof audit --check flip_fixtures_exist --verbose

The example selects the heuristic engine deliberately. The command's default engine is Kind2; engine choice affects how cases are produced and should remain visible in review.

Presence is a deliberately small claim

A present fixture can be stale, poorly modeled or unexecuted. Check freshness after formalization changes and inspect alignment with source-native verifying tests. If scenarios are only a development aid, remove the component from the controlled-evidence policy through a reviewed configuration change. Do not treat an absent-policy skip as equivalent to a populated evidence set.

Follow the evidence

Start by deciding whether this component's fixtures are required review evidence or optional examples.

Review one fixture-backed component. Bring its requirements and fixture policy so we can assess which scenarios are missing and how they should connect to tests.

Check fixture freshness · Connect scenarios to tests