Skip to main content
Status: Request for Comments Last Updated: August 25, 2026

​
What these are

Reference test vectors are machine-readable JSON fixtures pinned to specific wire-format rules in the spec. An SDK whose output matches a vector’s expected_* field byte-for-byte has agreed with the reference on that rule’s wire format — not a conformance claim (only storyboards decide that), but a necessary precondition for interop. An SDK that diverges has an interop bug, even if its own tests pass. Vectors complement storyboards. Storyboards exercise an agent end-to-end to produce a pass/fail verdict; vectors exercise a library in isolation against frozen inputs. A vector tells a signer “this 9421 request MUST produce this signature base”; a storyboard tells an agent “when the buyer sends this request, you MUST respond with a result shaped like this.” Most conformant stacks need both — vectors catch canonicalization drift inside a library; storyboards catch behavior drift at the wire. Vectors are not the conformance specification — the storyboards are. Vectors are reference inputs the storyboards and SDK unit tests consume.

​
Versioning

Every set under static/compliance/source/test-vectors/ is versioned alongside the spec. The copy served at /compliance/{version}/test-vectors/{set}/ is frozen at the GA release of that version; fixes that change a vector’s bytes ship in the next AdCP minor release. /compliance/latest/test-vectors/{set}/ follows the current development snapshot and can move ahead of the most recent GA, so production consumers should pin an immutable version path. Vector sets served under /test-vectors/ are currently unversioned: each file is overwritten in place when it changes. SDKs that consume these fixtures SHOULD vendor a commit-pinned copy, for example fetching from https://raw.githubusercontent.com/adcontextprotocol/adcp/<sha>/static/test-vectors/<name>.json and recording <sha> in their lockfile, until these files are rolled into the versioned compliance tree. SDKs SHOULD fetch versioned paths where available and record the version under test. For pinned versions, the CDN copy at /compliance/{version}/... is the source of truth; /compliance/latest/... is a convenience alias, not a stable pin.

​
Published sets

Start here: where a set includes a README.md, it documents file layout, key material, preconditions (e.g., runner state required for replay vectors), and how to wire the set into an SDK test loop. The source tree is authoritative; the index on this page is a catalog, not an integration guide. Directory CDN paths in the table are base paths for programmatic use — the CDN serves individual files, not directory listings. Browse the tree via the source column.

​
Test keys are public

Every signing vector set ships private key material in keys.json so libraries can exercise signer and verifier roles against identical inputs. These keys are valid only for grading against this suite. Any production verifier that trusts a kid declared in one of the published keys.json files is exploitable — the private key is on the public CDN and anyone can forge signatures under that kid. At time of writing this includes test-ed25519-2026, test-es256-2026, test-gov-2026, test-revoked-2026 (request-signing) and test-ed25519-webhook-2026, test-es256-webhook-2026, test-wrong-purpose-2026, test-response-purpose-2026, test-revoked-webhook-2026 (webhook-signing vectors). Treat every kid that appears in any suite keys.json as untrusted outside grading, present or future. Production signers mint their own keypairs and publish under their own jwks_uri; production verifiers MUST NOT register any test kid in a trust store exposed to live traffic.

​
Scope

The sets above cover both cross-surface wire rules — transport, signing, canonicalization, and discovery — and selected protocol behaviors where deterministic fixtures add value, such as attestation resolution, compatibility projections, and media-buy readback semantics. They complement rather than duplicate the other machine authorities: vectors pin exact inputs, outputs, or edge-case decisions for SDK and library code; conformance storyboards grade agent behavior end to end; and JSON Schemas define request and response shapes. The catalog does not aim to provide generic golden request/response pairs for every task. Implementers derive ordinary shapes from the schemas and confirm wire behavior by running the storyboards against their agent. Task-specific vectors are published only where a stable machine-readable fixture tests semantics that schemas alone cannot express or supports compatibility across SDKs.