Skip to main content
Status: Request for Comments Last Updated: April 19, 2026

​
Two words, not three

AdCP conformance has two load-bearing terms. A third (one you’ll hear in the wild) is a trap.
  • Conformant — the agent meets the normative rules. Defined by the storyboards this document indexes.
  • Verified — AAO has tested the agent recently and issued a signed attestation. Gated on active membership and a live heartbeat. The AAO Verified badge carries one of two qualifiers: (Spec) for storyboard-conformance against a test deployment or dev endpoint, (Sandbox) for storyboard-conformance against the seller’s real production endpoint under account.sandbox: true flagging. An agent can earn either or both.
  • “Compliant” — self-attested, unverified, no external check. Don’t claim it; don’t design for it. This document uses conformant and verified exclusively.
Put differently:
  • Conformance is a property of the agent’s wire behavior.
  • Verification is a time-bounded third-party attestation. (Spec) attests wire-format conformance against any registered endpoint; (Sandbox) attests the same storyboard suite passes against the seller’s real production endpoint under sandbox-flagged traffic. Same storyboards, different attestation surface.
  • The two axes are independent: a seller without a separate test deployment can earn (Sandbox) directly on production; a test agent that can never serve real impressions earns (Spec) as a complete claim.

​
Storyboard conformance vs. AAO Verified

This page indexes storyboard conformance — the property an agent’s wire behavior has when it matches the spec, verified by storyboards running against seeded test data. Storyboard passing earns the AAO Verified (Spec) or AAO Verified (Sandbox) qualifier (or both) on an agent’s badge, depending on where the runner targeted. A second axis — AAO Verified (Sandbox) — verifies the seller’s real production endpoint correctly handles the full storyboard suite under account.sandbox: true flagging. (Sandbox) is the stronger claim: a seller can pass (Spec) on a test deployment while their production stack has a broken sandbox gate (real-world side effects under flagged traffic, missing account-mode verification, etc.) — (Sandbox) closes that gap. The two qualifiers share one brand mark — AAO Verified — and an agent can earn either or both. (Spec) and (Sandbox) are independent: each independently demonstrates conformance through different evidence. (Spec) attests wire-format conformance against any registered endpoint; (Sandbox) attests the production code path correctly tolerates sandbox-flagged traffic. See AAO Verified for the qualifier model and the Sandbox framing verdict; the rest of this page indexes the storyboards that back both qualifiers.

​
Test surfaces and the storyboard loop

Every seller exposes a test surface — the mechanism that lets a storyboard runner exercise the seller’s tools deterministically without triggering real-world side effects. The test surface is what (Spec) is graded against. How a seller stands up that surface depends on where their state-of-record lives; the implementation differs, the goal does not: Both paths earn (Spec) — both prove the seller’s wire format matches the storyboards. The bridge is one implementation of the test-surface pattern, not a separate seller category. A state-local seller without wired seeds and an upstream-proxy seller without a wired bridge are in the same position: storyboards cannot run end-to-end against them. Neither category is what (Sandbox) attests; (Sandbox) is the separate axis covering whether the seller’s production stack honors account.sandbox: true without real-world side effects.

​
Distinguishing fixture-merged from upstream-derived responses

When a response passes through the SDK’s TestControllerBridge, the SDK stamps a _bridge: { callback, tool, merged_count } marker on the response. Marker presence on a step means the response content was merged from a seeded fixture after the seller’s handler returned; marker absence means the response came from the seller’s adapter end-to-end (or from a local DB the runner seeded directly). The marker is advisory metadata for runners and downstream leaderboards — it is not part of the wire contract. Sellers MUST NOT emit it, and conformance checks ignore it. The leading underscore marks the field as SDK/runner-stamped metadata reserved for testing tooling; future fields with the same prefix follow the same rule. Marker design: adcp-client#1775. Shipped: adcp-client#1786. Leaderboard policy that consumes the marker: adcp-client#1782.

​
Three signals — don’t conflate them

Adopters often read these three controls as the same thing. They answer different questions: These are runtime controls on individual storyboard steps — distinct from the (Spec) and (Sandbox) verification qualifiers, which describe what a storyboard pass attests over time. A storyboard pass can carry any combination of the three signals.

​
Storyboards are the truth

Rather than restate every MUST in prose — which would inevitably drift from the executable suite — the storyboards ARE the conformance specification. This document is a navigational index to them, grouped by the declaration that obligates the storyboard to run. Every normative rule in the suite has exactly one home: the storyboard YAML at /compliance/latest/. Changes to what “conformant” means happen there, in a versioned release, tested against real agents. If a rule isn’t in a storyboard, it’s not part of conformance. This is deliberate. A separate prose spec that restates storyboard rules creates two sources of truth. Two sources of truth drift. We pick one: the suite.
The @adcp/sdk package also ships TypeScript files under testing/scenarios/ that pre-date storyboard-driven comply(). They are not the conformance spec — see Storyboards vs. scenarios for which is which.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the referenced storyboards and prose sections below are to be interpreted as described in RFC 2119.

​
Conformance is layered

Every agent satisfies the universal layer. Each supported_protocols claim adds a protocol baseline. Each specialisms claim adds a specialism baseline. Agents MUST NOT declare a capability whose storyboards they do not pass. See the Compliance Catalog for the full taxonomy and Validate Your Agent for how to run the suite locally.

​
Universal conformance

Every agent MUST pass every storyboard below. Agents that declare capabilities.compliance_testing.supported: true MUST implement the full test controller; a partial controller is non-conformant, so declare false rather than ship one. Agents that declare request_signing.supported: true MUST implement the full RFC 9421 verifier per the request-signing profile; a partial verifier is non-conformant, so declare false rather than ship one.

​
Protocol conformance

A supported_protocols claim obligates the protocol’s baseline storyboard.

​
Specialism conformance

A specialisms claim obligates the specialism’s storyboard in addition to its parent protocol baseline. The catalog lives at /compliance/latest/index.json; the human-readable index is the Compliance Catalog. Specialisms carry a status — stable (verified pass/fail), preview (storyboard not yet defined; runner emits passed: null), deprecated (scheduled for removal). Agents MAY claim preview specialisms, but preview claims do not yield a pass/fail verdict.

​
Outside the wire

Some requirements can’t be verified by a storyboard because they’re operator-level, not wire-level. They remain part of running a conformant agent, but the suite can’t attest to them. Operators MUST self-assess against these; third-party frameworks (SOC 2, ISO 27001) are the usual attestation path.
  • Secret storage — credentials SHOULD live in a KMS or equivalent. The wire shows only whether auth succeeds, not where the key was stored.
  • Credential rotation and revocation — the operator MUST have a documented path to revoke a compromised credential in under an hour. The wire can’t observe the runbook.
  • Personnel and physical security — who can touch production, break-glass custody, employee offboarding. Entirely outside the protocol.
  • Governance agent due diligence — when the operator relies on a third-party governance agent, the buyer SHOULD treat it as a processor with multi-customer blast radius and assess its posture. The storyboards verify correct JWS handling by the seller but cannot vouch for the governance agent itself.
  • LLM subprocessor posture — if the agent uses an LLM provider, the DPA with that provider governs whether prompts, brand assets, or creative metadata may be retained. The protocol can’t see upstream DPA terms.
  • Incident response — AdCP emits the signals worth watching (IDEMPOTENCY_CONFLICT spikes, failed governance verifications, SSRF rejections); detection, alert routing, and response are operator concerns.
  • Data residency configuration — whether and how EU / UK data is kept in-region is typically declared in the agent’s capabilities or contract; the wire records the declaration, not the underlying infrastructure.
Full operator checklist: Security Model § What to verify before going live.

​
Conformance vs external assurance

Conformance is wire-level correctness. SOC 2, ISO 27001, and NIST CSF are operational assurance. They answer different questions and neither substitutes for the other. Two practical consequences:
  1. Storyboard pass evidence MAY support specific external control objectives. It is not a substitute for an audit.
  2. External certification does not imply AdCP conformance. SOC 2 Type II says nothing about whether create_media_buy responses validate.

​
How to claim conformance

  1. Declare supported_protocols and specialisms in get_adcp_capabilities.
  2. Pass every storyboard the declaration obligates — universal + protocol baselines + specialism baselines — at a specific AdCP major version.
  3. Keep declaration and behavior in sync. An undeclared capability the suite happens to test is separate from a declared capability that fails. Both are non-conformant.
Conformance is per-version; the suite is per-version. A 3.0-conformant agent is not thereby 3.1-conformant. For third-party attestation, run the heartbeat against AAO and earn an AAO Verified badge. The badge is a signed claim that AAO tested the agent recently and the pass still holds. Buyers filtering on verified get a smaller set than conformant — fewer agents, fresher attestation, a named party on the hook.

​
What this document does not do

  • Define individual MUSTs. The storyboards do. If a rule isn’t in a storyboard, it isn’t part of conformance.
  • Grant or revoke certification. The AgenticAdvertising.org certification program runs on top of this; conformance is necessary but not sufficient.
  • Publish reference test vectors beyond those already in the suite. The Reference Test Vectors index catalogs the vector sets that ship today; broader task-level corpus lands incrementally between 3.0 GA and 3.1, scoped in #2383.

​
When a storyboard fails

When a failure surfaces a disagreement between the spec, the mock, and an SDK, the section below gives the triage order. For symptom-to-cause lookup, see the links at the end of this section.

​
Mock-server authority and failure triage

The adcp mock-server is the reference wire implementation for stable surfaces. Use this triage order when a storyboard failure implicates the mock or an SDK: Triage order: spec → mock → SDK. The storyboards (and the schemas they reference) are canonical. The mock interprets the storyboards. The SDK consumes the protocol via the mock. Scope. This triage order applies to stable surfaces only. Experimental surfaces (see Experimental Status) are under active revision; mock behavior there is not yet authoritative. Spec ambiguity vs. spec silence. When spec text exists but is ambiguous, the mock’s behavior pins the authoritative interpretation — that pinning is normative even if the prose has not yet been tightened. When the spec is entirely silent on a point and the mock has no behavior for it, the chain breaks; open a known-ambiguities issue instead of treating the mock as authoritative.

​
Further reading