Compliance Catalog

Full index of AdCP protocols and specialisms an agent can claim — what each one means, which compliance storyboards run, and where to find the source YAML.

Every AdCP agent declares its supported_protocols and specialisms in get_adcp_capabilities. Each declaration maps to a compliance bundle at /compliance/{version}/ that the storyboard runner executes to verify the claim.

supported_protocols is not exhaustive. The accounts surface (sync_accounts, list_accounts, sync_governance) is a foundation implicit in every media_buy, creative, and signals agent and is intentionally not a supported_protocols value. See Accounts tasks for the full account surface.

This page is the human-readable index of that taxonomy. The machine-readable equivalent is /compliance/{version}/index.json.

Universal storyboards

Every agent runs every storyboard in /compliance/{version}/universal/ regardless of which protocols or specialisms it claims. A few are capability-gated — they only run when the agent advertises the relevant capability — but the storyboard is still universal in scope: any agent claiming the capability is graded by it. Failing a universal storyboard fails overall compliance.

Storyboard	Purpose
capability-discovery	get_adcp_capabilities shape, protocol/specialism declarations, version advertising
comply-controller-mode-gate	Sandbox/live isolation for sellers that expose comply_test_controller on a shared endpoint — live-mode principals must be refused before scenario dispatch
schema-validation	Request and response schema conformance, ISO 8601 timestamps, temporal invariants
schema-validation-signals	Response schema compliance for signals — required fields on every signal; gated on get_signals
version-negotiation	Release-precision adcp.supported_versions advertisement and response-envelope adcp_version echo; advisory in 3.1, promoted in later cuts
v3-envelope-integrity	v3 protocol envelopes MUST NOT carry the v2 legacy task_status or response_status fields — status is the single canonical lifecycle field in v3.
error-compliance	Structured error shape, published error codes, transport binding, no existence leaks across tenants
error-compliance-signals	Error handling for signals protocol — nonexistent signal IDs, missing fields, VERSION_UNSUPPORTED, transport binding; gated on get_signals + activate_signal
stale-response-advisory	STALE_RESPONSE wire placement — advisory rides in errors[] on a populated success response with transport success preserved; stale-cache forcing steps gated on comply_test_controller with force_upstream_unavailable
idempotency	idempotency_key scoping, replay semantics, IDEMPOTENCY_CONFLICT, replayed: true, declared TTL
read-tool-idempotency	Read-only task wrappers accept the 3.1 every-request idempotency_key envelope without strict request-wrapper rejection; includes the 3.1 omitted-key grace probe.
canonical-format-validate-input	Canonical-format validate_input result semantics — structural pass/fail across required slots and unvalidatable_nondeterministic for seeded product declarations. Gated on agents that advertise validate_input; the seeded-product branch also requires comply_test_controller seeding support.
security	Authentication baseline — unauth rejection, static-credential enforcement (Bearer API key or HTTP Basic), OAuth discovery + RFC 9728 audience binding. See Authentication.
webhook-emission	Outbound webhook conformance — stable idempotency_key across retries; RFC 9421 webhook signing (or HMAC fallback if the buyer opted in). Runs for any agent that accepts push_notification_config on any operation.
notification-config-event-scope	sync_accounts.accounts[].notification_configs[] semantic validation — account-level subscribers reject media-buy-anchored notification types (scheduled, final, delayed, adjusted, impairment) even though they are valid values in the shared notification-type enum.
notification-config-lifecycle	Account-level notification_configs[] lifecycle on sync_accounts: paused registration, durable list_accounts echo, subscriber-keyed replacement, and clear-all semantics.
notification-config-rejections	Semantic notification_configs[] request rejection path for duplicate subscriber_id values.
wholesale-feed-products	Product wholesale feed versioning — bootstrap responses carry wholesale_feed_version/cache_scope, and matching if_wholesale_feed_version probes return unchanged without product rows.
wholesale-feed-signals	Signals wholesale feed versioning — bootstrap responses carry wholesale_feed_version/cache_scope, and matching if_wholesale_feed_version probes return unchanged without signal rows.
wholesale-feed-product-webhooks	Account-level notification_configs[] registration for agents that advertise product wholesale feed webhook events.
wholesale-feed-signal-webhooks	Account-level notification_configs[] registration for agents that advertise signal wholesale feed webhook events.
wholesale-feed-bulk-webhooks	Account-level notification_configs[] registration for agents that advertise wholesale_feed.bulk_change.
pagination-integrity	cursor ↔ has_more invariant verified by walking a paginated list_creatives response from a continuation page through to terminal.
get-signals-pagination-integrity	cursor ↔ has_more invariant verified by walking a paginated get_signals response under a broad query — page 1 must be non-terminal against any non-trivial signal set, page 2 follows the cursor.
pagination-integrity-list-accounts	cursor ↔ has_more invariant verified by walking a paginated list_accounts response — storyboard bootstraps three accounts via sync_accounts, then asserts page 1 is non-terminal and page 2 is terminal with no stale cursor.
pagination-integrity-creative-formats	cursor ↔ has_more invariant verified by walking a paginated list_creative_formats response — storyboard seeds two creative formats via seed_creative_format, then asserts page 1 is non-terminal and page 2 is terminal with no stale cursor.
get-media-buys-pagination-integrity	cursor ↔ has_more invariant verified by walking a paginated get_media_buys response — storyboard seeds three media buys via seed_media_buy, then asserts page 1 is non-terminal and page 2 is terminal with no stale cursor.
content-standards-pagination-integrity	cursor ↔ has_more invariant verified by walking a paginated list_content_standards response — storyboard bootstraps three content standards configurations via create_content_standards, then asserts page 1 is non-terminal and page 2 is terminal with no stale cursor.
collection-lists-pagination-integrity	cursor ↔ has_more invariant verified by walking a paginated list_collection_lists response — storyboard bootstraps three collection lists via create_collection_list, then asserts page 1 is non-terminal and page 2 is terminal with no stale cursor.
property-lists-pagination-integrity	cursor ↔ has_more invariant verified by walking a paginated list_property_lists response — storyboard bootstraps three property lists via create_property_list, then asserts page 1 is non-terminal and page 2 is terminal with no stale cursor.
deterministic-testing	comply_test_controller state-machine verification — skipped if capabilities.compliance_testing.supported: false.
signed-requests	RFC 9421 transport-layer request-signing verification — skipped if request_signing.supported: false.
billing-gate-dispatch	sync_accounts.billing rejection dispatch — BILLING_NOT_SUPPORTED (capability gate, with error.details.scope) vs BILLING_NOT_PERMITTED_FOR_AGENT (per-buyer-agent commercial-relationship gate, with the clamped rejected_billing + suggested_billing shape). Capability phase skipped when the seller supports all three billing values; per-agent phases skipped when the test kit does not declare commercial_relationship: passthrough_only.

Capability-gated rows (deterministic-testing, signed-requests) are skipped only when the agent advertises the capability as false; they cannot be claimed and partially implemented. Declaring supported: true and failing the storyboard is non-conformant — declare false rather than ship a partial implementation. The billing-gate-dispatch and comply-controller-mode-gate rows are precondition-gated rather than ordinary capability-gated rows: each phase grades not_applicable when its precondition is not met. Sellers wanting full coverage of the per-agent billing gate SHOULD ship a test kit with commercial_relationship: passthrough_only declared so the per-agent phases run.

Protocols

Top-level agent capability claims. An agent claims a protocol by listing it in supported_protocols and must pass the protocol’s baseline storyboard plus every universal storyboard.

supported_protocols uses snake_case; compliance paths and specialism IDs use kebab-case. See Naming conventions below for the full mapping.

supported_protocols value	Compliance path	Purpose
media_buy	protocols/media-buy/	Campaign creation, package management, delivery optimization, conversion tracking
creative	protocols/creative/	Creative asset management, format discovery, rendering
signals	protocols/signals/	Audience signal discovery and activation
governance	protocols/governance/	Property governance, brand standards, compliance
brand	protocols/brand/	Brand identity, rights discovery, rights acquisition — small protocol today, growing with rights licensing work; see brand-rights specialism.
sponsored_intelligence	protocols/sponsored-intelligence/	AI-mediated commerce and conversational sponsored experiences

Support for the compliance test controller is declared via the capabilities.compliance_testing block on get_adcp_capabilities, not via supported_protocols. Compliance testing is an RPC surface for the test harness, not a functional protocol.

An agent can claim multiple protocols — a full-stack media-buy platform might list media_buy, creative, and signals. The runner executes all matching baselines.

Specialisms

Specific capability claims. Each specialism lives under exactly one protocol. An agent claiming a specialism must pass the specialism’s storyboard in addition to the parent protocol’s baseline — e.g. claiming sales-guaranteed requires media_buy in supported_protocols.

Specialisms carry a status:

• stable — fully specified storyboard. Compliance runner executes every phase; AAO Verified means the agent demonstrably passed.
• preview — ID and scope are reserved; the storyboard is a placeholder while the underlying protocol surface stabilizes. Agents may claim these; the runner emits a result of { status: "preview", passed: null, reason: "storyboard not yet defined" } instead of a verified pass/fail. AAO badges render preview specialisms with a distinct indicator.
• deprecated — retained for backward compatibility but scheduled for removal in a future major. Runner emits { status: "deprecated", passed: <boolean>, reason: "..." } — still executes the storyboard if one exists, but warns the claim should be migrated.

Status is declared per-specialism in the YAML frontmatter and surfaced in /compliance/{version}/index.json.

Specialisms are grouped below by parent protocol.

What changed in 3.0. sponsored_intelligence was promoted from a specialism to a full protocol (declare it in supported_protocols, not specialisms). audience-sync moved from governance to media-buy to match its tool family. broadcast-platform was renamed to sales-broadcast-tv and social-platform to sales-social. property-governance and collection-governance split into sibling property-lists and collection-lists specialisms.

media-buy

Specialism	Status	Purpose
sales-guaranteed	stable	Guaranteed media buys with human IO approval
sales-non-guaranteed	stable	Non-guaranteed auction-based media buys
sales-proposal-mode	deprecated	Deprecated in 3.1. Drop this claim and replace with sales-guaranteed + media_buy.supports_proposals: true. See #3823.
sales-catalog-driven	stable	Catalog-driven commerce with conversion tracking
sales-broadcast-tv	stable	Broadcast linear TV with guaranteed inventory and FCC cancellation rules
sales-social	stable	Social media advertising platform with self-service flows
governance-aware-seller	stable	Seller composes with the buyer’s campaign-governance agent after baseline registration — calls check_governance and propagates approvals, conditions, and denials unchanged. Optional claim for the full governance-check loop.
audience-sync	stable	Syncs buyer-provided audience segments into a platform for activation (uses sync_audiences, list_accounts)

Coming in 3.1. sales-streaming-tv (CTV / streaming), sales-exchange (programmatic SSP / exchange), and sales-retail-media (retail media network) are scheduled for 3.1. Sellers in those categories should claim sales-guaranteed or sales-non-guaranteed at 3.0 GA.

audience-sync moved from the governance protocol to media-buy to match its tool family. If your agent claims audience-sync but only declares governance in supported_protocols, add media_buy to supported_protocols — the runner now expects the media-buy baseline to run alongside the audience-sync storyboard.

creative

Specialism	Status	Purpose
creative-ad-server	stable	Creative ad server with tag-based delivery
creative-generative	stable	Generative creative agent producing assets on demand
creative-template	stable	Creative template and transformation agent

signals

Specialism	Status	Purpose
signal-owned	stable	Owned signal agent exposing first-party segments
signal-marketplace	stable	Marketplace signal agent reselling third-party data

governance

Specialism	Status	Purpose
content-standards	stable	Content standards enforcement (brand safety, policy compliance)
property-lists	stable	Property list governance — curated inclusion and exclusion lists for targeting and delivery compliance
collection-lists	stable	Collection list governance — curated inclusion and exclusion lists of content programs (shows, series, podcasts) for program-level brand safety
governance-delivery-monitor	stable	Campaign delivery monitoring with drift detection
governance-spend-authority	stable	Conditional spend approval and human-in-the-loop governance

Coming in 3.1. measurement-verification (third-party viewability, attribution, brand-safety, and SI-outcome verification) is scheduled for 3.1 under a dedicated measurement protocol.

brand

Specialism	Status	Purpose
brand-rights	stable	Brand identity and rights licensing (talent, music, stock media)

Choosing a sales specialism

The sales-* specialisms are not mutually exclusive — a hybrid platform with both a guaranteed direct desk and an auction floor should claim both sales-guaranteed and sales-non-guaranteed. Follow the steps below to resolve your claim.

sales-proposal-mode is deprecated in 3.1. Do not claim it for new agents. Existing agents that declare it must drop it entirely and replace it with sales-guaranteed + media_buy.supports_proposals: true in get_adcp_capabilities. See #3823.

1. Is your inventory channel-specific?

   Three specialisms apply to specific delivery channels and have their own storyboards. If you only sell one of these channel types, claim only the matching specialism. If you also sell general display or video inventory outside these channels, continue to Step 2.

   If you operate…	Claim
   Broadcast linear TV with FCC cancellation rules	sales-broadcast-tv
   Catalog-driven dynamic ads (product listings, restaurant menus, hotel listings, local commerce)	sales-catalog-driven
   Social platform with platform-managed creative	sales-social

2. What purchase model do you support?

   If you sell…	Claim
   Guaranteed media (IO approval, fixed pricing)	sales-guaranteed → see Step 3
   Auction / PMP non-guaranteed	sales-non-guaranteed
   Both guaranteed and non-guaranteed	sales-guaranteed + sales-non-guaranteed

3. Set media_buy.supports_proposals (sales-guaranteed only)

   media_buy.supports_proposals is a boolean in the media_buy capabilities block of your get_adcp_capabilities response. It gates whether the proposal_finalize compliance scenario runs.

   If you…	Set
   Accept RFPs, generate proposals, and finalize to committed status before IO	media_buy.supports_proposals: true
   Sell direct-buy guaranteed only (auction PG, retail SKU, quoted-rate — no RFP flow)	media_buy.supports_proposals: false (or omit — default is false)

   // Full-service guaranteed seller — proposal lifecycle graded
   {
     "supported_protocols": ["media_buy"],
     "specialisms": ["sales-guaranteed"],
     "media_buy": {
       "supports_proposals": true
     }
   }
   

   // Direct-buy guaranteed seller — proposal scenario skipped as capability_unsupported
   {
     "supported_protocols": ["media_buy"],
     "specialisms": ["sales-guaranteed"],
     "media_buy": {
       "supports_proposals": false
     }
   }
   

creative

Specialism	Status	Purpose
creative-ad-server	stable	Creative ad server with tag-based delivery
creative-generative	stable	Generative creative agent producing assets on demand
creative-template	stable	Creative template and transformation agent

signals

Specialism	Status	Purpose
signal-owned	stable	Owned signal agent exposing first-party segments
signal-marketplace	stable	Marketplace signal agent reselling third-party data

governance

Specialism	Status	Purpose
content-standards	stable	Content standards enforcement (brand safety, policy compliance)
property-lists	stable	Property list governance — curated inclusion and exclusion lists for targeting and delivery compliance
collection-lists	stable	Collection list governance — curated inclusion and exclusion lists of content programs (shows, series, podcasts) for program-level brand safety
governance-delivery-monitor	stable	Campaign delivery monitoring with drift detection
governance-spend-authority	stable	Conditional spend approval and human-in-the-loop governance

Coming in 3.1. measurement-verification (third-party viewability, attribution, brand-safety, and SI-outcome verification) is scheduled for 3.1 under a dedicated measurement protocol.

brand

Specialism	Status	Purpose
brand-rights	stable	Brand identity and rights licensing (talent, music, stock media)

sponsored-intelligence

Specialism	Status	Purpose
sponsored-intelligence	preview	Agent claim for SDKs that dispatch on specialism ID. The graded storyboard is the sponsored-intelligence protocol baseline; this specialism reserves the wire ID and promotes to stable when the SI tools graduate from x-status: experimental.

Cross-resource invariants

In addition to per-step validations, specialisms declare cross-step and cross-resource invariants the runner observes across the full storyboard run. These catch state inconsistencies that no single response shape would surface.

Invariant	Scope	Specialisms
status.monotonic	Single-resource — rejects status transitions observed across steps that aren’t on the spec lifecycle graph.	All specialisms with a stateful resource lifecycle.
impairment.coherence	Cross-resource — verifies that media_buy.impairments[] stays in sync with referenced resources. Forward: every entry references a currently-offline resource. Inverse: any offline resource referenced by a non-terminal buy appears in impairments[]. Health-iff: on a non-terminal buy, health == "impaired" iff impairments[] is non-empty (strict iff — stale drift fails). Out of scope: all three rules relax on terminal-status buys (sellers MAY leave impairments[] and health in whatever state held at the terminal transition); materiality is schema-enforced via package_ids: minItems: 1.	audience-sync, creative-ad-server, creative-template, creative-generative, sales-catalog-driven. Driven by the media_buy_seller/dependency_impairment scenario (creative-track via force_creative_status); audience-track and catalog-track follow once the compliance test controller adds force_audience_status / force_catalog_item_status. Grades not_applicable on storyboards that don’t observe both a resource transition and a media-buy snapshot read.

Invariants are declared in the specialism YAML’s invariants: array and documented inline with the rule they enforce. See media-buy lifecycle § Compliance for the full impairment.coherence contract.

How to claim

Declare your protocols and specialisms in get_adcp_capabilities:

{
  "supported_protocols": ["media_buy", "creative"],
  "specialisms": ["sales-guaranteed", "creative-template"]
}

The storyboard runner:

1. Runs every storyboard in /compliance/{version}/universal/
2. For each protocol in supported_protocols, runs the baseline at /compliance/{version}/protocols/{protocol}/ (snake_case → kebab-case)
3. Runs each claimed specialism’s storyboard at /compliance/{version}/specialisms/{id}/
4. For preview specialisms, emits a warning instead of a pass/fail verdict — AAO Verified badges render preview specialisms with a distinct indicator

Implement the tools AND claim the specialism. An agent that wires all of a specialism’s required tools but omits the kebab-case ID from capabilities.specialisms[] will be graded “No applicable tracks found” by the runner — tracks_passed = 0, tracks_failed = 0, tracks_skipped = 1. This is a silent pass at the step level and a silent fail at the track level. The fix is to add the specialism ID (e.g., "creative-generative") to your get_adcp_capabilities response.

If any stable storyboard fails, your agent is not compliant for that claim. See Validate Your Agent for how to run the suite locally. For a detailed walkthrough of how the runner resolves specialism manifests into graded scenarios — including how capability flags like media_buy.supports_proposals gate individual scenarios — see How grading works.

Naming conventions

Four casings coexist in the taxonomy. Which one applies depends on where the identifier is read:

Casing	Layer	Example	Where it appears
snake_case	Wire enums (supported_protocols, delivery_type, channel IDs, signal_type)	media_buy, non_guaranteed, ctv, custom	get_adcp_capabilities response, JSON payloads, generated schemas
kebab-case	Specialism IDs and compliance URLs	sales-broadcast-tv, property-lists, audience-sync	get_adcp_capabilities.specialisms, /compliance/.../specialisms/{id}/ paths
snake_case	Storyboard id: and category: fields	sales_broadcast_tv, audience_sync	Compliance YAML frontmatter, runner output, test reports
Prose / hyphenated	Titles and narrative	”Streaming TV”, “non-guaranteed”	Catalog pages, narrative copy

The kebab↔snake swap between wire specialism IDs and storyboard categories is mechanical identity — hyphens become underscores, nothing more. Variant scenarios within a specialism use {category}/{variant} path form.

Specialism ID (wire)	Channel / tool family	Storyboard category	Variant scenarios
sales-broadcast-tv	channels: ['linear_tv']	sales_broadcast_tv	—
sales-social	channels: ['social']	sales_social	—
audience-sync	sync_audiences tool	audience_sync	—
property-lists	property_list tools	property_lists	—
collection-lists	collection_list tools	collection_lists	—
governance-spend-authority	check_governance, sync_plans	governance_spend_authority	governance_spend_authority/denied
creative-generative	build_creative	creative_generative	creative_generative/seller
brand-rights	get_brand_identity, acquire_rights	brand_rights	brand_rights/governance_denied

The case split is deliberate: supported_protocols is a pre-existing 3.0 field already shipped to production agents, while specialism IDs are new and URL-first (each is a directory name under /compliance/.../specialisms/{id}/). The runner handles the mapping transparently.

Specialism ↔ tool family mapping

The protocol an agent claims does not always match the tool family name a specialism uses:

• audience-sync lives under the media-buy protocol because sync_audiences is a media-buy tool.
• property-lists (specialism ID, kebab-case) maps to the property_list tool family (create_property_list, validate_property_delivery) and storyboard category property_lists.
• sales-broadcast-tv declares channels: ['linear_tv'] — “Broadcast TV” is the prose name; linear_tv is the wire value.

/compliance/{version}/index.json surfaces each specialism’s required_tools so agents can discover the tool families without reading the full storyboard YAML.

Wire enum vs prose

Wire enum values are always snake_case (non_guaranteed, pmax_platform, ctv). Prose renders the same concept with hyphens or spaces (“non-guaranteed auction inventory”, “Connected TV”). When populating a payload, always use the wire form — hyphenated or spaced spellings are editorial only and will fail schema validation.

signal_type values

The signal_type enum in signal responses has three values:

• marketplace — the signal agent is reselling segments published by a third-party data provider (Experian, Peer39, etc.). Buyers can verify authorization via the provider’s /.well-known/adagents.json.
• owned — the signal agent exposes its own first-party segments derived from directly owned data (retailer purchase data, publisher behavioral data, telco location data).
• custom — the signal source builds the segment on demand from models, composites, or buyer-supplied inputs. Use this when no adagents.json authorization chain applies — the segment is source-native, not attributable to a standing upstream provider.

Source of truth

The machine index is published alongside schemas:

Path	Contents
/compliance/{version}/index.json	Enumerated protocols + specialisms + universal storyboards + per-specialism status
/schemas/{version}/enums/specialism.json	Specialism enum used by get_adcp_capabilities.specialisms
/schemas/{version}/enums/adcp-protocol.json	Task-classification enum referenced by tasks-list-request and webhook payloads. Same axis as supported_protocols (kebab-case here, snake_case on the wire).

The build pipeline verifies the specialism filesystem ↔ enum parity and that every specialism’s parent protocol exists in the compliance tree. Drift fails the build.

The catalog on this page is maintained by hand to give human context. The authoritative enumeration is always /compliance/{version}/index.json.

Building an agent that wraps an upstream platform? Storyboards in this catalog grade the AdCP wire contract; they cannot detect adapters that return shape-valid responses without integrating with the upstream. See Validate adapter agents with mock upstream fixtures for the complementary pre-staging gate.