Version Matrix

This document is non-normative. It maps specification versions to the reference implementations and the conformance profiles each one claims, so an evaluator can tell at a glance which artifact implements which version of the protocol and where that claim is verified. The authoritative versioning policy is VERSIONING.md; dated release notes are in CHANGELOG.md.

The matrix

Reading the rows

Spec v0.1.0 (Final). The contents of this repository's main branch: RFCs 0001–0008 at status Final, RFC-ACDP-0009 reserved, the JSON Schemas under schemas/json/, and the conformance fixtures under schemas/conformance/. v0.1.0 is wire-frozen — clarification rounds add prose and fixtures, never wire changes.

Spec v0.2.0 (Final). Merged on main as Draft (2026-07-04) and promoted to Final on 2026-07-05 per RELEASE.md, the conformance pack having passed against two independent interoperating implementations (acdp-rs and acdp-verifier-py — see CHANGELOG.md). It is a backward-compatible minor version: every v0.1.0 body, signature, and content_hash remains valid. Headline additions: RFC-ACDP-0010 registry receipts (registry-signed binding of ctx_id / lineage_id / origin_registry / created_at / content_hash / producer-key fingerprint, closing the RFC-ACDP-0008 §9.1 registry-honesty gap for receipt-bearing responses), did:key producers, the hash-divergence corpus (can-012), and the acdp-registry-receipts profile. One parse-surface caveat: the previously closed publish response gains the OPTIONAL registry_receipt member.

acdp-rs (reference SDK — producer, consumer, verification core).

• 0.1.x implements spec v0.1.0: the acdp-consumer profile (client, WebResolver, CrossRegistryResolver, strict verification) plus the producer and server-side validation building blocks.
• 0.2.x implements the spec v0.2.0 surface (then Draft): receipt minting/verification (RFC-ACDP-0010), did:key resolution, divergence diagnostics, and the explicit-acdp_version builder default.
• 0.3.x is the same v0.2.0 protocol surface refactored into a fine-grained Cargo workspace; no wire-visible change.
• 0.5.x implements the spec v0.2.0 + v0.3.0 Final surface plus the v0.4.0 RFC-ACDP-0015 witness-cosigning types: require-mode conformance passes the executed rcpt/lhr/log/rev/wit bindings.
• 0.8.x (crates.io acdp 0.8.3, current) carries that same protocol surface on the current workspace layout — no wire-visible change over 0.5.x. The language bindings carry the witness build/verify/quorum surface and are tagged and published in lockstep with the crate: acdp-node on npm at 0.8.3, acdp-py on PyPI at 0.8.3.

Where conformance is verified: the SDK's own conformance suite (tests/conformance.rs) executes the spec's golden vectors and fixtures directly — point ACDP_SPEC_DIR at a checkout of this repository (the matching branch for 0.2.x/0.3.x) and run cargo test --test conformance. The suite skips silently when ACDP_SPEC_DIR is absent — set ACDP_REQUIRE_CONFORMANCE=1 (as the SDK's conformance CI job does) to turn a missing spec checkout into a hard failure, so a green run proves the fixtures actually executed.

acdp-registry-rs (reference registry). Implements the spec as a running service: it advertises the acdp-registry-core and acdp-registry-discovery profiles by default, and — with a [receipt] signing key configured — the v0.2.0 acdp-registry-receipts profile (signed, atomically-persisted publish receipts, self-hosted did:web document, did:key producers). Current main serves all three v0.3.0 profiles (acdp-registry-head-receipts, acdp-registry-transparency-log, acdp-registry-lifecycle) end-to-end. It also aggregates RFC-ACDP-0015 witness cosignatures, serving verified ones as the witness_signatures member on transparency-log checkpoints (0.4.0). Cross-registry retrieval of foreign ctx_ids is available as a feature, but the registry does not currently claim the acdp-registry-federated profile.

Where conformance is verified: the registry's own harness (crates/acdp-registry-server/tests/conformance.rs) executes the behavioral fixture families (pub-*, vis-*, ret-*, idem-*, …) against a live in-process registry — the half of the suite that scripts/conformance-runner.py in this repo deliberately does not execute (it runs only the arithmetic/cryptographic vectors — can-* / lin-* / sig-* / fp-* and the keypair-bearing rcpt-* / lhr-* / log-* / wit-* / rev-* goldens; see schemas/conformance/README.md).

Rules of thumb

• Pinning a library? acdp = "0.1" gives you frozen v0.1.0 semantics; 0.2/0.3 carry the v0.2.0 surface; 0.5 and later carry the v0.2.0 + v0.3.0 Final surface plus the v0.4.0 witness-cosigning types — the current release is 0.8.3 across crates.io, npm, and PyPI (full family lockstep).
• Talking to a registry? Read its /.well-known/acdp.json: acdp_version and profiles are the authoritative statement of what it implements — not this table.
• Writing a new implementation? Target v0.4.0 (Final; v0.1.0/v0.2.0/v0.3.0 remain Final and wire-frozen); the optional 0.2.0/0.3.0/0.4.0 surfaces (receipts, did:key, head receipts, transparency log, lifecycle, witness cosigning) are profile-gated — adopt them as you need them.