Compatibility
Compatibility scenarios (crates/compatibility, pack compatibility) pin
the version-compatibility contracts of the proof pipeline:
CT-COMP-001— a proof generated against a circuit version verifies against the same version (the compatibility baseline).CT-COMP-002— the same proof is refused and classifiedwrong-circuitwhen the request pins a different circuit version.CT-COMP-003— identical statements produce deterministic, reproducible proof artifacts across independent submissions (same statement, distinct envelopes), so artifact stability is checked rather than assumed.
Versioning surface
Circuit and protocol versions are first-class scenario metadata
(metadata.circuit_version, metadata.protocol_version). Scenarios record
the version they target and the verdict they expect from that version —
never from the verifier’s own answer — so a compatibility check stays an
independent oracle (spec §48, §29).
Scope and honesty
Compatibility today is judged against the fixture prover double’s
deterministic version binding. It proves the scenario layer enforces
version semantics. When crucible-prover is wired behind the same adapter,
these scenarios become genuine cross-version checks (e.g. proof generated
by one prover version verifying under another) without rework.