Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

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 classified wrong-circuit when 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.