MACP Conformance Levels
This page defines what an implementation claims when it says it conforms to MACP, and which fixtures back each claim. The fixtures live in [`schemas/conformance/`](../schemas/conformance/README), and each spec release also ships them as a pinned bundle (see [Pinning a release bundle](../schemas/conformance/README#pinning-a-release-bundle)).
This page defines what an implementation claims when it says it conforms to MACP, and which fixtures back each claim. The fixtures live in schemas/conformance/, and each spec release also ships them as a pinned bundle (see Pinning a release bundle).
Levels are informative. The normative requirements are in the RFCs; a level names a set of fixtures that exercise them, so that two implementations can compare claims.
Levels
Each level includes everything in the level above it.
| Level | Fixtures that must pass | What it shows |
|---|---|---|
| Core | session_start_reject_paths.json, and the commitment-hash vectors cmt-hash/cmt_hash_001–010 | SessionStart validation (RFC-MACP-0001 §7) and the canonical commitment hash, both computing it and verifying it (RFC-MACP-0013) |
| Core + Decision | every decision_*.json | the Decision Mode (RFC-MACP-0007), including empty tallies, vetoes and finalize-decline |
| Standard modes | every proposal_*.json, task_*.json, handoff_*.json and quorum_*.json | all five standard modes (RFC-MACP-0007 through RFC-MACP-0011) |
The ext.multi_round.v1 extension mode has its own fixtures (multi_round_*.json). An implementation that supports it MAY add "+ multi_round" to its claim; it is not part of any level.
Passing a fixture means the harness rules in schemas/conformance/README.md hold: each message is accepted or rejected as the fixture says (with expected_error_code where given), and the final state, resolution and mode state match.
Profiles
A level says what passes. A profile says how the implementation was driven, because the same semantics can ship in two shapes.
| Profile | How fixtures are driven | Notes |
|---|---|---|
| Server | over the network, through MACPRuntimeService (RFC-MACP-0006 §3) | the shape most adopters run |
| Embedded (library) | in-process, by calling the implementation's acceptance and replay API directly, with no MACPRuntimeService endpoint | a runtime that embeds an implementation as a library; RFC-MACP-0001 §7.6 item 5 already applies acceptance obligations to such runtimes. See Embedding MACP as a library |
A claim names both, for example "Standard modes, Server profile" or "Standard modes, Embedded profile". An Embedded claim SHOULD also state the semantics revision it was tested at (RFC-MACP-0003 §3.2), since that revision decides which rules replay applies.
Verifier role
Some implementations do not run sessions at all but check results, for example an SDK that verifies a CommitmentRef it received. Such an implementation claims the Verifier role by passing the commitment-hash vectors cmt_hash_001–010. The role is listed separately because it is not a runtime level.
Making a claim
Until the conformance runner from the adoption roadmap ships, implementations self-report: they run the fixtures in their own CI and link that suite from IMPLEMENTATIONS.md. To be listed, open a pull request that adds a row with the level, profile, the spec commit or bundle version you test against, and a link to the CI job or test file that runs the fixtures.