Verify conformance

A specification declares more than an interface shape. Command outcomes, refused branches, state transitions, emitted events, and invariants become semantic scenarios an implementation can be checked against.

Pages in this guide

1. Synthesize a suite — generate the suite a specification requires.
2. Author scenarios — add scenarios a person wrote, compile them on their own, run a chosen subset, and what they can arrange and expect.
3. Observations — what a suite observes beyond an act's own answer: held state, retries, selection, periodic activity, clocks, event context and binding accessors.
4. Runners and reports — run a suite against a built-in target, a generated Go or TypeScript package or a Rust target, and read the report.
5. Audit a suite with specification mutants — measure whether the suite notices a changed specification, against a built-in target or your own implementation.
6. Explore command sequences and histories — random sequences and concurrent histories.

Where each section went

This guide used to be a single page. Each of its sections is listed here under its old anchor, so an older link still finds it.

• Generate the suite
• Select authored scenarios explicitly
• Expect an external branch in an authored scenario
• Establish backend state in an authored scenario
• Name several instances in one input
• Observe outcomes selected by held state
• Observe retries of the original result
• Observe selection, periodic activity and clock evidence
• Deliver an event with its context
• Run a supported target
• Hold your own implementation to the suite
• Audit the suite with specification mutants
• Explore random command sequences
• Check a concurrent history
• Draw a history as client lanes
• Import a recorded log
• Opt into explicit outcome counts
• Where passed, failed and skipped live
• Opt into declared coverage
• Observe bounded binding accessors
• What the report proves
• A target in Rust