Documentation Index
Fetch the complete documentation index at: https://agenticadvertisingorg-changeset-release-main.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
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./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 |
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 |
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 |
idempotency | idempotency_key scoping, replay semantics, IDEMPOTENCY_CONFLICT, replayed: true, declared TTL |
security | Authentication baseline — unauth rejection, API key enforcement, 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. |
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. |
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 rows are precondition-gated rather than capability-gated: each phase grades not_applicable when its precondition is not met (the seller supports all three billing values; or the test kit does not declare a passthrough-only caller). Sellers wanting full coverage of the per-agent 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.
| 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 — accepts sync_governance, calls check_governance, and propagates approvals, conditions, and denials unchanged. Optional claim; sellers that don’t claim it skip the governance scenarios as not_applicable. |
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.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 |
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 |
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) |
| 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: 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"]
}
- Runs every storyboard in
/compliance/{version}/universal/
- For each protocol in
supported_protocols, runs the baseline at /compliance/{version}/protocols/{protocol}/ (snake_case → kebab-case)
- Runs each claimed specialism’s storyboard at
/compliance/{version}/specialisms/{id}/
- 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.
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 |
{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 |
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.
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 agent builds the segment on demand from models, composites, or buyer-supplied inputs. Use this when no adagents.json authorization chain applies — the segment is agent-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 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. 