> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adcontextprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.
# 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`](/dist/docs/3.2.0-beta.10/protocol/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`](/dist/docs/3.2.0-beta.10/accounts/tasks/sync_accounts), [`list_accounts`](/dist/docs/3.2.0-beta.10/accounts/tasks/list_accounts), [`sync_governance`](/dist/docs/3.2.0-beta.10/accounts/tasks/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](/dist/docs/3.2.0-beta.10/accounts/tasks/sync_accounts) 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 graded 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. Non-executable schemas and support fixtures shipped in the universal bundle are not runner scenarios and do not appear in this table.
| Graded storyboard | Purpose | Source |
| ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `account-identity-reconciliation` | Validates revision-guarded operator identity rekeying, collision safety, and former-key redirects for sellers that advertise identity updates. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/account-identity-reconciliation.yaml) |
| `agent-notification-configs` | Validates the 3.2 agent-level capabilities.changed registration surface: advertised revision fencing, NO\_AUTH rejection, and dry-run clear semantics. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/agent-notification-configs.yaml) |
| `billing-gate-dispatch` | Validates that account.supported\_billing is declared and honored by sync\_accounts, including out-of-set BILLING\_NOT\_SUPPORTED rejection, recovery-value consistency, and the distinct per-buyer-agent BILLING\_NOT\_PERMITTED\_FOR\_AGENT gate. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/billing-gate-dispatch.yaml) |
| `canonical-format-validate-input` | Validates 3.1 canonical-format dry-run semantics: structural pass/fail across canonical slots and unvalidatable\_nondeterministic for seeded products. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/canonical-format-validate-input.yaml) |
| `capability-discovery` | Buyer calls get\_adcp\_capabilities to discover what an agent supports before making any buying or creative decisions. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/capability-discovery.yaml) |
| `collection-lists-pagination-integrity` | Validates the cursor↔has\_more invariant by walking a paginated list\_collection\_lists response from a continuation page to a terminal page. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/collection-lists-pagination-integrity.yaml) |
| `comply-controller-mode-gate` | Verifies that a seller exposing comply\_test\_controller refuses calls from live-mode (non-sandbox) accounts with FORBIDDEN. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/comply-controller-mode-gate.yaml) |
| `content-standards-pagination-integrity` | Validates the cursor↔has\_more invariant by walking a paginated list\_content\_standards response from a continuation page to a terminal page. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/content-standards-pagination-integrity.yaml) |
| `ctv-experience-validate-input` | Validates AdCP 3.2 ctv\_ad\_experience matrix pairings, duration/interactivity constraint profiles, the menu focus/video pairing, and non-blocking activation-copy warnings via validate\_input against seeded CTV products. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/ctv-experience-validate-input.yaml) |
| `deterministic-testing` | Uses comply\_test\_controller to force state transitions and simulate delivery/budget, verifying state machines and reporting. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/deterministic-testing.yaml) |
| `error-compliance` | Validates that agents return properly structured AdCP errors with correct codes, recovery hints, and transport bindings. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/error-compliance.yaml) |
| `error-compliance-signals` | Validates that signals agents return properly structured AdCP errors with correct codes, recovery hints, and transport bindings. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/error-compliance-signals.yaml) |
| `get-media-buys-pagination-integrity` | Validates that get\_media\_buys responses carry a well-formed pagination envelope honoring the cursor↔has\_more invariant. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/get-media-buys-pagination-integrity.yaml) |
| `get-products-pagination-integrity` | Validates get\_products wholesale-mode pagination by walking a seeded product feed from continuation to terminal, while documenting that brief/refine pagination caps returned products in curated results. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/get-products-pagination-integrity.yaml) |
| `get-signals-pagination-integrity` | Validates the cursor↔has\_more invariant on a paginated get\_signals response by walking from a continuation page to the next page under a broad query. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/get-signals-pagination-integrity.yaml) |
| `idempotency` | Validates that mutating requests enforce idempotency\_key — replays return cached responses, key reuse with a different payload returns IDEMPOTENCY\_CONFLICT, fresh keys create new resources, and concurrent retries with the same key produce exactly one resource (first-insert-wins under rule 9). | [YAML](https://adcontextprotocol.org/compliance/latest/universal/idempotency.yaml) |
| `notification-config-event-scope` | Validates that sync\_accounts.accounts\[].notification\_configs\[] rejects media-buy-anchored notification types. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/notification-config-event-scope.yaml) |
| `notification-config-lifecycle` | Validates account-level notification\_configs\[] lifecycle behavior on sync\_accounts: paused registration, durable echo, subscriber-keyed replacement, and clear. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/notification-config-lifecycle.yaml) |
| `notification-config-rejections` | Validates account-level notification\_configs\[] semantic rejection for duplicate subscriber keys. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/notification-config-rejections.yaml) |
| `oauth-setup` | Capability-gated evaluation of an agent's RFC 9728 protected-resource metadata and the complete RFC 8414 authorization-server graph it advertises. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/oauth-setup.yaml) |
| `pagination-integrity` | Validates the cursor↔has\_more invariant by walking a paginated list\_creatives response from a continuation page to a terminal page. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/pagination-integrity.yaml) |
| `pagination-integrity-creative-formats` | When an agent still exposes deprecated list\_creative\_formats compatibility, validates its cursor↔has\_more invariant by seeding two formats and walking pages with max\_results=1. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/pagination-integrity-creative-formats.yaml) |
| `pagination-integrity-list-accounts` | Validates list\_accounts pagination by seeding sandbox accounts, requesting a small first page, and following its cursor once. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/pagination-integrity-list-accounts.yaml) |
| `premium-display-canonical-validation` | Validates AdCP 3.2 seller\_rendered\_stateful\_display supply-mode contracts (components, rendered\_canvases, layered\_source), single-state reveal shape, policy floors, and coordinated\_placements sequence/serving\_policy, alongside transition/canvas coverage and shared-slot resolution. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/premium-display-canonical-validation.yaml) |
| `principal` | Validates the experimental stable-principal-scoped configuration surface: capability discovery, pre-configuration identity readback, NO\_AUTH rejection, dry-run setup, applied lifecycle with readback, idempotent replay, and section clearing. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/principal.yaml) |
| `property-lists-pagination-integrity` | Validates the cursor↔has\_more invariant by walking a paginated list\_property\_lists response from a continuation page to a terminal page. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/property-lists-pagination-integrity.yaml) |
| `read-tool-idempotency` | Validates that read-only AdCP tasks and the 3.x get\_products compatibility facade accept an optional idempotency\_key without strict wrapper rejection. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/read-tool-idempotency.yaml) |
| `reporting-core` | Validates the required reporting.core tier: capability declaration with tier boundaries, and that a polling-only seller needs no receipt task, push notification, destination, or canonicalization surface. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/reporting-core.yaml) |
| `schema-validation` | Validates that agent responses conform to AdCP schemas and that temporal constraints are enforced. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/schema-validation.yaml) |
| `schema-validation-signals` | Validates that signals agent responses conform to AdCP schemas with all required fields present and correctly typed. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/schema-validation-signals.yaml) |
| `security` | Every AdCP agent MUST require authentication on protected operations. At least one of static credentials or OAuth MUST be implemented and correctly advertised. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/security.yaml) |
| `signed-requests` | Agent verifies RFC 9421 HTTP Signatures on incoming AdCP requests per the 3.1-compatible transport-layer profile. Universal capability-gated storyboard — runs for any agent advertising {"request_signing.supported: true"} regardless of {"supported_protocols"}. Graded against the legacy wire suite covering every 3.1 checklist step and canonicalization-edge rule. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/signed-requests.yaml) |
| `stale-response-advisory` | Validates that STALE\_RESPONSE rides in errors\[] on a populated success response with transport success preserved, and that STALE\_RESPONSE is absent on healthy upstream responses. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/stale-response-advisory.yaml) |
| `trusted-match-publisher-authentication` | Verifies that a TMP router deployment rejects schema-valid Context Match and Identity Match requests with absent or invalid publisher authentication using HTTP 401 and a WWW-Authenticate challenge. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/trusted-match-publisher-authentication.yaml) |
| `v3-envelope-integrity` | v3 protocol envelopes MUST NOT carry task\_status or response\_status — v2 legacy field names that have no semantics in v3. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/v3-envelope-integrity.yaml) |
| `version-negotiation` | Sellers advertise supported releases on capabilities and echo the served release on every response. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/version-negotiation.yaml) |
| `webhook-emission` | Any agent that emits webhooks MUST echo the caller-supplied operation\_id in every payload, carry a stable idempotency\_key across retries, avoid duplicate webhook side effects on request replay, and — when the buyer has not opted into the deprecated HMAC fallback — MUST sign deliveries under the RFC 9421 webhook profile. Sellers MUST NOT emit task webhooks for inline terminal responses; any future sync-completion notification mode would be explicit and capability-advertised. Graded by a runner hosting a webhook receiver during storyboard execution. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/webhook-emission.yaml) |
| `webhook-receiver-envelope` | Buyer webhook receivers MUST accept full MCP webhook envelopes, reject bare delivery-result payloads, preserve raw-body signature verification, and dedupe retries by a stable idempotency\_key. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/webhook-receiver-envelope.yaml) |
| `wholesale-feed-bulk-webhooks` | Validates account-level notification\_configs\[] registration for agents that advertise wholesale\_feed.bulk\_change webhook events. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-bulk-webhooks.yaml) |
| `wholesale-feed-product-webhooks` | Validates account-level notification\_configs\[] registration for agents that advertise product wholesale feed webhook events. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-product-webhooks.yaml) |
| `wholesale-feed-products` | Validates get\_products wholesale feed versioning: bootstrap responses carry wholesale\_feed\_version/cache\_scope and matching if\_wholesale\_feed\_version probes return unchanged without product rows. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-products.yaml) |
| `wholesale-feed-products-scope-isolation` | Validates that get\_products conditional-fetch is keyed by cache\_scope: a wholesale\_feed\_version minted under one cache\_scope must not short-circuit (unchanged: true) a request the seller resolves to a different cache\_scope. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-products-scope-isolation.yaml) |
| `wholesale-feed-signal-webhooks` | Validates account-level notification\_configs\[] registration for agents that advertise signal wholesale feed webhook events. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-signal-webhooks.yaml) |
| `wholesale-feed-signals` | Validates get\_signals wholesale feed versioning: bootstrap responses carry wholesale\_feed\_version/cache\_scope and matching if\_wholesale\_feed\_version probes return unchanged without signal rows. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-signals.yaml) |
| `wholesale-feed-signals-scope-isolation` | Validates that get\_signals conditional-fetch is keyed by cache\_scope: a wholesale\_feed\_version minted under one cache\_scope must not short-circuit (unchanged: true) a request the agent resolves to a different cache\_scope. | [YAML](https://adcontextprotocol.org/compliance/latest/universal/wholesale-feed-signals-scope-isolation.yaml) |
Capability-gated rows (`deterministic-testing`, `oauth-setup`, `signed-requests`) are skipped when the corresponding capability is absent or advertises `supported: false`; they cannot be claimed and partially implemented. Declaring `supported: true` and failing the storyboard is non-conformant — omit the capability or 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.
## Standard error codes
The compliance suite verifies that standard errors use the recovery classifications and remediation guidance defined by the canonical [`error-code.json`](https://github.com/adcontextprotocol/adcp/blob/main/static/schemas/source/enums/error-code.json) source taxonomy. The vocabulary remains open: agents must also handle unknown codes using the response's `recovery` value.
| Code | Recovery | Suggested action |
| ---------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ACCOUNT_AMBIGUOUS` | correctable | pass explicit account\_id or a more specific natural key |
| `ACCOUNT_IDENTITY_CONFLICT` | correctable | choose a different operator or operator\_unit identity, or retain the account's current identity; do not retry the same desired identity unchanged |
| `ACCOUNT_MOVED` | correctable | replace the stale reference with error.details.current\_account, refresh through list\_accounts, and retry with a fresh idempotency key |
| `ACCOUNT_NOT_FOUND` | terminal | verify account via list\_accounts or contact seller |
| `ACCOUNT_PAYMENT_REQUIRED` | terminal | buyer must resolve billing |
| `ACCOUNT_REQUIRED` | correctable | pass account, or reference an existing resource whose owning account the service can resolve |
| `ACCOUNT_SETUP_REQUIRED` | correctable | check details.setup for URL or instructions |
| `ACCOUNT_SUSPENDED` | terminal | contact seller to resolve suspension |
| `ACTION_NOT_ALLOWED` | correctable | branch on error.details.reason: for wrong\_status, wait for or transition to a status listed under the action's allowed\_statuses; for mode\_mismatch, this is a flow switch (not a retry against update\_media\_buy) — follow the mode named in available\_actions\[\].mode; for condition\_unresolved, wait until the seller advertises the action after resolving its opaque condition; for not\_supported\_on\_product or not\_supported\_on\_buy, do not retry — the action is unavailable on this buy and buyer must select a different product or renegotiate |
| `AGENT_BLOCKED` | terminal | surface to a human at the buyer — the relationship is permanently denied and is reinstated only through offline operator action with the seller, not via any seller-callable AdCP task |
| `AGENT_SUSPENDED` | terminal | surface to a human at the buyer — the agent cannot unilaterally lift a suspension; re-onboarding with the seller offline may resolve |
| `AMBIGUOUS_BIDDING_POLICY` | correctable | remove either the canonical bidding block or all legacy bidding fields from the effective package |
| `AUDIENCE_TOO_SMALL` | correctable | broaden targeting or upload more audience members |
| `AUTHORIZATION_REQUIRED` | correctable | complete or restore the required downstream platform connection, identity, creator, or post authorization; use error.details.missing\_connections, authorization\_url, authorization\_instructions, or reference\_authorization when present |
| `AUTH_INVALID` | terminal | do NOT auto-retry — credentials were rejected; rotate keys, refresh OAuth tokens once if applicable, otherwise escalate to a human |
| `AUTH_MISSING` | correctable | provide credentials via the auth header and retry |
| `AUTH_REQUIRED` | correctable | provide credentials when missing; do NOT auto-retry rejected credentials — escalate for rotation |
| `BIDDING_PLACEMENT_CONFLICT` | correctable | align media-buy and package bidding scopes with the provider's supported placement, or choose a compatible budget mode/product combination |
| `BILLING_NOT_PERMITTED_FOR_AGENT` | correctable | retry with error.details.suggested\_billing (typically 'operator') when present; when absent, surface to a human at the buyer — the agent cannot unilaterally extend its commercial relationship and MUST NOT auto-retry |
| `BILLING_NOT_SUPPORTED` | correctable | check get\_adcp\_capabilities for supported\_billing and resubmit with a supported value, or omit billing to accept the seller's default |
| `BILLING_OUT_OF_BAND` | terminal | do not retry — billing for this account runs through a non-AdCP channel. Pre-filter via capabilities.creative.bills\_through\_adcp before sending report\_usage; flag the account in the buyer's routing table and fall back to the ad server's native billing export for cost reconciliation |
| `BRAND_REQUIRED` | correctable | include brand (domain plus optional brand\_id) on the request |
| `BUDGET_CAP_REACHED` | correctable | raise max\_spend, or reduce max\_creatives/max\_variants, to produce the remaining items |
| `BUDGET_EXCEEDED` | correctable | reduce requested amount or increase budget allocation |
| `BUDGET_EXHAUSTED` | terminal | buyer must add funds or increase budget cap |
| `BUDGET_TOO_LOW` | correctable | increase budget or check capabilities.media\_buy.limits |
| `CAMPAIGN_SUSPENDED` | transient | wait for the escalation to resolve; contact the plan operator if the suspension persists |
| `CATALOG_LIMIT_EXCEEDED` | correctable | remove unused catalogs, or contact the seller to raise the limit |
| `COMPLIANCE_UNSATISFIED` | correctable | choose a format that supports the required disclosure positions and persistence modes, or remove the disclosure requirement |
| `CONFIGURATION_ERROR` | terminal | surface to a human at the seller — the buyer cannot resolve a seller-side deployment misconfiguration and MUST NOT auto-retry |
| `CONFLICT` | transient | re-read the resource and retry with current state |
| `CONFLICTING_SELECTORS` | correctable | emit one canonical format selector route, or make every required legacy 3.x compatibility projection select the same product format contract under the canonical v2-narrows-v1 comparison |
| `CREATIVE_DEADLINE_EXCEEDED` | correctable | check creative\_deadline via get\_media\_buys before submitting changes, or negotiate a deadline extension with the seller |
| `CREATIVE_INACCESSIBLE` | correctable | verify the asset URLs in creative\_manifest are reachable without agent-side credentials, then re-submit |
| `CREATIVE_LOCALE_NOT_ACCEPTED` | correctable | supply or assign a creative variant matching every in-scope format option's accepted\_language\_ranges, narrow placement scope, choose a compatible format option, or change an ineligible serve\_default |
| `CREATIVE_MISSING_CLICK_URL` | correctable | add the required destination URL and resubmit the creative |
| `CREATIVE_NOT_FOUND` | correctable | verify creative\_id via list\_creatives, or sync\_creatives to register it |
| `CREATIVE_REJECTED` | correctable | revise the creative according to the applicable advertising policy or validated accessibility criteria |
| `CREATIVE_REPRESENTATION_UNRESOLVED` | correctable | inspect every error.details.representation\_rejections entry, then choose a compatible format option or supply a compatible representation |
| `CREATIVE_REVISION_CONTENT_MISMATCH` | correctable | resend the exact content previously bound to this revision\_id, or mint a new revision\_id for changed content |
| `CREATIVE_SIZE_MISMATCH` | correctable | resize or replace the creative with a size accepted by every selected package that may serve it |
| `CREATIVE_VALIDATION_FAILED_GENERIC` | correctable | correct the buyer-visible validation problem and resubmit the creative |
| `CREATIVE_VALUE_NOT_ALLOWED` | correctable | pick a value from error.details.allowed\_values (or re-fetch the format) and resubmit |
| `CREDENTIAL_IN_ARGS` | terminal | do NOT auto-retry — auto-retry re-logs the credential on each attempt. Move authentication material or caller-supplied trust material out of request args (top-level, {"context"}, {"ext"}, any nested location) onto the relevant transport authentication/trust channel or account provisioning path (Authorization: Bearer, RFC 9421 signature/JWKS, mTLS, MCP/A2A authentication framing); rotate any leaked credential, then resubmit |
| `CURSOR_EXPIRED` | correctable | obtain a latest checkpoint, rebuild authoritative account snapshots, then drain changes after the checkpoint |
| `EVALUATOR_AGENT_NOT_ACCEPTED` | correctable | replace the evaluator agent\_url (evaluator.feature\_agent.agent\_url or the evaluator agent-form agent\_url) with one from the seller's published accepted\_verifiers, or drop the evaluator agent pointer to fall back to seller-default ranking |
| `FEED_FETCH_FAILED` | correctable | check URL accessibility, authentication, and that content matches the declared feed\_format |
| `FIELD_NOT_PERMITTED` | correctable | drop the disallowed field(s) and retry |
| `FORMAT_DECLARATION_DIVERGENT` | correctable | advisory — seller-side fix needed: producer is emitting disagreeing format\_ids and format\_options for the same product. Buyer SDK SHOULD prefer format\_options and surface the divergent product to operators; do not auto-retry |
| `FORMAT_DECLARATION_V1_AMBIGUOUS` | correctable | advisory — seller-side fix needed: the v2 declaration's canonical has only family-level structural registry entries (no invertible literal). Seller MUST author v1\_format\_ref on the v2 declaration to disambiguate; SDKs MUST NOT synthesize. Do not auto-retry |
| `FORMAT_DECLARATION_V1_LOSSY_MULTI_SIZE` | correctable | advisory — emitted alongside the partial v1 emission, NOT in place of it: the v2 declaration carries {"params.sizes[]"} with N entries but only M v1\_format\_ref entries (M \< N), so v1 buyers see partial size coverage on the product. Seller-side fix: add v1\_format\_ref entries for the missing sizes. SDK MAY (non-normative) fan out automatically by catalog lookup. Non-fatal — do not auto-retry |
| `FORMAT_NOT_SUPPORTED` | correctable | refresh get\_adcp\_capabilities creative.supported\_formats\[] and retry with a capability\_id whose operations contains the intended build, preview, or validate operation |
| `FORMAT_OPTION_UNRESOLVED` | correctable | advisory — publisher-side fix needed: a placement's {"format_options[].format_option_id"} references a {"format_option_id"} that does not exist in this file's top-level {"formats[]"}. Buyer SDK MUST fail closed for that placement (drop the format from the placement's accepted set) and surface this code. Publisher fix: either declare the missing format option in {"formats[]"} or remove the reference from the placement. Do not auto-retry |
| `FORMAT_PROJECTION_FAILED` | correctable | advisory — seller-side fix needed: ask the seller to add an explicit {"canonical"} field on the legacy format declaration, or contribute a registry entry (format\_id\_glob or structural match) to v1-canonical-mapping.json. Do not auto-retry; the product is still valid on the legacy named-format path |
| `FORMAT_SHAPE_PROMOTED` | correctable | advisory — migrate the legacy custom format\_shape to error.details.promoted\_to before error.details.transition\_end; dual emission is allowed during the transition window. Do not auto-retry |
| `GOVERNANCE_AGENT_NOT_ACCEPTED` | correctable | select a governance agent matching {"error.details.accepted_governance_agents"}, then retry {"sync_governance"} with a fresh idempotency key |
| `GOVERNANCE_DENIED` | correctable | restructure the buy, escalate to human spending authority, or contact the governance agent for details |
| `GOVERNANCE_UNAVAILABLE` | transient | retry with backoff; if the agent remains unreachable, the buyer MUST contact the plan's governance operator |
| `IDEMPOTENCY_CONFLICT` | correctable | use a fresh UUID v4 for the new request, or resend the exact original payload to get the cached response |
| `IDEMPOTENCY_EXPIRED` | correctable | perform a natural-key check to determine whether the original request succeeded; if no evidence of success, generate a fresh idempotency\_key for a new attempt |
| `IDEMPOTENCY_IN_FLIGHT` | transient | wait top-level error.retry\_after seconds and retry with the SAME idempotency\_key — MUST NOT mint a fresh key (turns a safe retry into a double-execution race) |
| `INVALID_FEED_FORMAT` | correctable | verify the feed content matches the declared format |
| `INVALID_PRICING_OPTION` | correctable | verify pricing\_option\_id against the product's pricing\_options from get\_products or the vendor's discovery response, then resubmit with a valid ID |
| `INVALID_REQUEST` | correctable | check request parameters and fix |
| `INVALID_STATE` | correctable | check current status via get\_media\_buys and adjust request |
| `INVALID_USAGE_DATA` | correctable | check required fields for the vendor type (vendor\_cost, currency, account at minimum), fix invalid values, and resubmit |
| `IO_REQUIRED` | correctable | review the proposal's insertion\_order, accept terms, and include io\_acceptance on accept\_proposal; use create\_media\_buy only for 3.x compatibility |
| `ITEM_VALIDATION_FAILED` | correctable | check item\_issues for per-item rejection reasons and fix the offending items |
| `MACRO_RESOLUTION_FAILED` | correctable | inspect error.details.macro\_resolution\_results and route to a resolver that supports the declared dialect, semantic, owner, and encoding depth |
| `MEDIA_BUY_NOT_FOUND` | correctable | verify media\_buy\_id; for legacy correlation use get\_media\_buys plus context, such as context.internal\_campaign\_id |
| `MULTI_FINALIZE_UNSUPPORTED` | correctable | sequence single-proposal finalize calls — one finalize entry per get\_products refine\[] call or per refine\_proposals refinements\[] call |
| `NOT_CANCELLABLE` | correctable | check the seller's cancellation policy or contact the seller |
| `PACKAGE_NOT_FOUND` | correctable | verify package\_id; for legacy package correlation use get\_media\_buys plus package context, such as context.buyer\_ref |
| `PAYMENT_TERMS_NOT_SUPPORTED` | correctable | omit payment\_terms to accept the seller's default, retry with a different supported value, or negotiate offline |
| `PERMISSION_DENIED` | correctable | call check\_governance to mint a valid token, or contact the seller to resolve the underlying permission; when error.details.scope is 'agent' with reason 'sandbox\_only' the rejection is terminal-pending-onboarding — surface to a human rather than auto-retrying. For suspended/blocked agent relationships, sellers emit AGENT\_SUSPENDED / AGENT\_BLOCKED instead (those codes carry recovery: terminal directly). |
| `PIXEL_TRACKER_LOSSY_DOWNGRADE` | correctable | advisory — emitted alongside the v1 downgrade emission: SDK collapsed a pixel\_tracker asset to v1 {"{asset_type: url, url_type: tracker_pixel}"} for a seller that doesn't support pixel\_tracker natively. The URL still fires; what's lost is in {"error.details.lost_fields"} (event variant, method:js execution context, or custom event timing). Buyer decision: accept the loss (most counter pixels survive), or fail the buy and route to a 3.1-capable seller. Non-fatal — do not auto-retry |
| `PIXEL_TRACKER_UPGRADE_INFERRED` | correctable | advisory — emitted when a 3.1 SDK upgrades a v1 url+tracker\_pixel asset to pixel\_tracker by inferring event and method from asset\_id conventions. The inference may not match the buyer's original intent; check {"error.details.inferred_event"} / {"inferred_method"} and re-prompt the seller for explicit values if precise measurement matters. Non-fatal — do not auto-retry |
| `PLACE_TARGET_UNAVAILABLE` | correctable | resolve the pinned value against the current catalog, review any replacement, and submit an intentional package targeting update |
| `PLAN_NOT_FOUND` | correctable | verify plan\_id via sync\_plans, or register the plan first |
| `POLICY_VIOLATION` | correctable | review policy requirements in the error details |
| `PRIVATE_FIELD_IN_PUBLIC_PLACEMENT` | correctable | seller-side fix needed: remove private operational fields ({"visibility"}, {"source"}, {"origin"}, {"delivery_mappings"}, or similar) from public placement objects. Consumers MUST fail closed for the affected placement and alert operators; do not echo private field values in logs or error details |
| `PRODUCT_EXPIRED` | correctable | re-discover with get\_products to find current inventory |
| `PRODUCT_NOT_FOUND` | correctable | remove invalid IDs and retry, or re-discover with get\_products |
| `PRODUCT_UNAVAILABLE` | correctable | choose a different product |
| `PROPOSAL_EXPIRED` | correctable | call request\_proposals and finalize a fresh proposal, or re-discover and finalize through legacy get\_products |
| `PROPOSAL_NOT_COMMITTED` | correctable | finalize the draft through refine\_proposals, or through the legacy get\_products refine action |
| `PROPOSAL_NOT_FOUND` | correctable | request and finalize a fresh proposal, then retry |
| `PROVENANCE_CLAIM_CONTRADICTED` | correctable | revise the provenance claim to match the verifier's observation or replace the creative; auto-retry without correction will not pass |
| `PROVENANCE_DIGITAL_SOURCE_TYPE_MISSING` | correctable | set provenance.digital\_source\_type to a value from the digital-source-type enum and resubmit |
| `PROVENANCE_DISCLOSURE_MISSING` | correctable | set provenance.disclosure.required and, when true, populate disclosure.jurisdictions |
| `PROVENANCE_EMBEDDED_MISSING` | correctable | attach at least one embedded\_provenance entry from a supported provider and resubmit |
| `PROVENANCE_REQUIRED` | correctable | attach a provenance object - at minimum digital\_source\_type - and resubmit |
| `PROVENANCE_SYNTHETIC_DEPICTION_MISSING` | correctable | assess the creative, set provenance.synthetic\_depiction to true or false, and resubmit |
| `PROVENANCE_VERIFIER_NOT_ACCEPTED` | correctable | replace verify\_agent.agent\_url with one from the seller's published accepted\_verifiers, drop verify\_agent if the embedding is self-verifiable, or re-embed with a verifier the seller accepts |
| `RATE_LIMITED` | transient | wait top-level error.retry\_after seconds when present, then retry |
| `READ_ONLY_SCOPE` | correctable | use a non-mutating alternative, or surface to the operator to request a scope that permits mutation |
| `REFERENCE_NOT_FOUND` | correctable | verify the referenced identifier exists and is accessible to the caller |
| `REQUOTE_REQUIRED` | correctable | refine accepted\_proposal\_id into an amendment and apply it through accept\_proposal, or keep control\_media\_buy inside the accepted envelope; 3.1 compatibility callers must adjust or rediscover |
| `SCOPE_INSUFFICIENT` | correctable | the agent cannot broaden its own scope - surface to the operator rather than auto-retry |
| `SERVICE_UNAVAILABLE` | transient | retry with exponential backoff |
| `SESSION_NOT_FOUND` | correctable | initiate a new session via si\_initiate\_session |
| `SESSION_TERMINATED` | correctable | initiate a new session via si\_initiate\_session |
| `SIGNAL_NOT_FOUND` | correctable | verify signal\_id via get\_signals, or confirm the signal is available from this agent |
| `SIGNAL_TARGETING_INCOMPATIBLE` | correctable | assign the creative to a package whose signal targeting matches the creative's signal\_condition, or rebuild the creative for the package's condition; match on shared signal\_ref identity (compare signal\_agent\_segment\_id exactly when both carry it, else categorical signal\_ref + value) |
| `SIGNED_RESPONSE_ENVELOPE_EXPIRED` | transient | re-invoke the designated task (verify\_brand\_claim or verify\_brand\_claims) to obtain a freshly signed response with a current exp window |
| `SIGNED_RESPONSE_REQUEST_HASH_MISMATCH` | correctable | re-invoke the designated task with the intended request parameters — the signed response's request\_hash does not match the verifier's recomputed hash of the actual request; if the mismatch persists across retries, investigate JCS request-binding canonicalization between caller and responder |
| `SIGNED_RESPONSE_TENANT_MISMATCH` | correctable | verify the request targeted the correct brand domain and agent\_url, then re-invoke; if the mismatch persists, the responding agent's server-side tenant resolution may be misconfigured |
| `SOURCE_ACCESS_FAILED` | correctable | error.field source.locator/source.segment\_ref: fix the reference; error.field source: grant the seller's declared consumer identity and retry; no error.field: vendor outage, retry with backoff |
| `STALE_RESPONSE` | transient | advisory — emitted alongside a populated payload that was served from cache past the seller's freshness target because an upstream or sub-agent was unreachable. The response is usable; treat as non-fatal. Inspect {"error.details.cache_age_seconds"} to decide whether to immediately retry for fresh data or accept the cached value; the seller's own service is healthy, so retry is safe (it does not amplify the upstream failure) |
| `TERMS_REJECTED` | correctable | adjust the proposed terms and retry, or omit measurement\_terms to accept the product's defaults |
| `UNPRICEABLE_OUTPUT` | correctable | target an output format the transformer prices, or have the seller add a pricing option covering it |
| `UNSUPPORTED_FEATURE` | correctable | check get\_adcp\_capabilities and remove unsupported fields |
| `UNSUPPORTED_GRANULARITY` | correctable | pick a granularity from the product's reporting\_capabilities.windowed\_pull\_granularities (via get\_adcp\_capabilities) and resubmit, or omit time\_granularity to fall back to cumulative date-range pulls |
| `UNSUPPORTED_PROVISIONING` | correctable | re-issue with the entry shape the seller supports — {"account: {account_id: ...}"} for settings-update sellers with account-id namespaces, or {"brand+operator+billing"} for provisioning sellers; check seller documentation or capability declaration for which modes are implemented |
| `VALIDATION_ERROR` | correctable | review error details and fix field values |
| `VAST_PARSE_FAILED` | correctable | inspect error.details.reason (not\_xml, no\_vast\_root, no\_ad, no\_media\_file), fix the VAST document, and resubmit |
| `VAST_VERSION_MISMATCH` | correctable | inspect error.details.mismatch\_reason and the corresponding acceptance-set or observed-document fields; select a compatible source representation or correct the offending VAST document |
| `VAST_WRAPPER_DEPTH_EXCEEDED` | correctable | inspect error.details.reason (depth, loop, timeout); flatten the wrapper chain, reduce redirects below the format's max\_wrapper\_depth, or fix the failing hop |
| `VERSION_UNSUPPORTED` | correctable | re-pin to a release in supported\_versions and retry, or call get\_adcp\_capabilities without a version pin to discover supported\_versions |
### Full descriptions
**Suggested action:** pass explicit account\_id or a more specific natural key
Natural key resolves to multiple accounts. Recovery: correctable (pass explicit account\_id or a more specific natural key).
**Suggested action:** choose a different operator or operator\_unit identity, or retain the account's current identity; do not retry the same desired identity unchanged
The complete operator\_identity requested through sync\_accounts would rekey the account onto a natural key already owned by another account. The seller MUST reject the change atomically, MUST NOT merge the accounts, and MUST preserve both accounts and every account-scoped resource unchanged. Distinct from CONFLICT, which reports a transient stale revision or concurrent write. Recovery: correctable (choose a different operator or operator\_unit identity, or retain the account's current identity; do not retry the same desired identity unchanged).
**Suggested action:** replace the stale reference with error.details.current\_account, refresh through list\_accounts, and retry with a fresh idempotency key
An authorized caller used a former natural key that was tombstoned after the same account was rekeyed through sync\_accounts. The seller MUST return the current canonical reference in error.details.current\_account, conforming to error-details/account-moved.json, and MUST NOT provision or resolve a second account from the former key. Sellers retain the tombstone while the account or any account-scoped historical resources are retained. To avoid a cross-tenant existence oracle, sellers return ACCOUNT\_MOVED only when the caller is authorized to resolve the current account; otherwise they return ACCOUNT\_NOT\_FOUND. Recovery: correctable (replace the stale account reference with details.current\_account, refresh through list\_accounts, and retry with a fresh idempotency key).
**Suggested action:** verify account via list\_accounts or contact seller
The account reference could not be resolved. Recovery: terminal (verify account via list\_accounts or contact seller).
**Suggested action:** buyer must resolve billing
Account has an outstanding balance requiring payment before new buys. Recovery: terminal (buyer must resolve billing).
**Suggested action:** pass account, or reference an existing resource whose owning account the service can resolve
The service must resolve the commercial account before it can determine governance applicability, but the request and referenced resource do not identify one. Recovery: correctable (pass account, or use a resource bound to an account).
**Suggested action:** check details.setup for URL or instructions
Natural key resolved but the account needs setup before use. Recovery: correctable (check details.setup for URL or instructions).
**Suggested action:** contact seller to resolve suspension
Account has been suspended. Recovery: terminal (contact seller to resolve suspension).
**Suggested action:** branch on error.details.reason: for wrong\_status, wait for or transition to a status listed under the action's allowed\_statuses; for mode\_mismatch, this is a flow switch (not a retry against update\_media\_buy) — follow the mode named in available\_actions\[\].mode; for condition\_unresolved, wait until the seller advertises the action after resolving its opaque condition; for not\_supported\_on\_product or not\_supported\_on\_buy, do not retry — the action is unavailable on this buy and buyer must select a different product or renegotiate
The requested mutation maps to an action that is not currently available on this media buy. Sellers MUST populate {"error.details"} with {"attempted_action"} (the {"media_buy_valid_action"} value the request maps to), {"reason"} (an {"action-not-allowed-reason"} value: {"wrong_status"}, {"not_supported_on_product"}, {"not_supported_on_buy"}, {"mode_mismatch"}, or {"condition_unresolved"}), and {"currently_available_actions"} (echo of the buy's resolved {"available_actions[]"} so the buyer SDK can offer recovery without a separate get\_media\_buys round-trip). Recovery: correctable when {"reason"} is {"wrong_status"} (wait for or transition to an allowed status), {"mode_mismatch"} (re-issue through the appropriate flow), or {"condition_unresolved"} (wait until the seller can resolve the condition and advertises the action). Terminal-for-this-buy when {"reason"} is {"not_supported_on_product"} or {"not_supported_on_buy"} — buyers select a different product or renegotiate buy terms.
**Suggested action:** surface to a human at the buyer — the relationship is permanently denied and is reinstated only through offline operator action with the seller, not via any seller-callable AdCP task
The calling buyer agent's commercial relationship with the seller is permanently denied — the agent is blocked. Sibling to {"AGENT_SUSPENDED"} on the agent-relationship axis but with no recovery path (a suspension may lift via re-onboarding; a block does not). The code itself is the discriminator — same posture as {"AGENT_SUSPENDED"}: no {"error.details"} payload, no per-agent commercial state, cross-tenant onboarding oracle clamp + channel-coverage requirements normative in error-handling.mdx Per-Agent Authorization Gate. Recovery: terminal (no autonomous recovery — the agent MUST surface to a human at the buyer; relationships are reinstated only through offline operator action with the seller, not via any seller-callable AdCP task).
**Suggested action:** surface to a human at the buyer — the agent cannot unilaterally lift a suspension; re-onboarding with the seller offline may resolve
The calling buyer agent's commercial relationship with the seller is temporarily paused — the agent is onboarded but currently suspended. Sibling to {"ACCOUNT_SUSPENDED"} (account-wide) and {"CAMPAIGN_SUSPENDED"} (per-plan) but scoped to the agent-relationship axis (orthogonal to any specific account on that agent). The code itself is the discriminator — it does NOT carry an {"error.details"} payload (mirroring {"BILLING_NOT_PERMITTED_FOR_AGENT"}'s discriminator-by-code pattern), and MUST NOT carry per-agent commercial state (rate cards, payment terms, credit limit, billing entity, contact channels) since full disclosure of per-agent state in a single probe is a per-agent oracle. Cross-tenant onboarding oracle clamp + channel-coverage requirements (response shape, HTTP/A2A/MCP status, headers, side effects, observability, latency parity, retry-counter side channel) are normative in error-handling.mdx Per-Agent Authorization Gate; this description does not restate them to avoid drift. Recovery: terminal (re-onboarding may resolve the suspension; the agent MUST surface to a human at the buyer rather than auto-retrying — the agent cannot unilaterally lift a suspension, and re-attempts only reinforce the gate).
**Suggested action:** remove either the canonical bidding block or all legacy bidding fields from the effective package
The same effective package combines the canonical bidding block with legacy bid\_price or monetary optimization-goal target fields, so two bidding interpretations are present. Sellers MUST reject rather than choosing a winner. Recovery: correctable (emit only the 3.2 bidding block or only one legacy representation).
**Suggested action:** broaden targeting or upload more audience members
Audience segment is below the minimum required size for targeting. Recovery: correctable (broaden targeting or upload more audience members).
**Suggested action:** complete or restore the required downstream platform connection, identity, creator, or post authorization; use error.details.missing\_connections, authorization\_url, authorization\_instructions, or reference\_authorization when present
The caller is authenticated, but the referenced object requires an additional downstream platform connection, identity, creator, or post authorization before the seller can complete the requested action. Typical use: {"sync_creatives"} with a {"published_post"} reference where the seller can resolve the post but the owning identity has not authorized paid serving, or authorization has expired/revoked and can be restored. Distinct from {"AUTH_MISSING"} / {"AUTH_INVALID"} (caller credentials) and from {"PERMISSION_DENIED"} (seller policy denies the caller). Sellers SHOULD include recovery details conforming to {"error-details/authorization-required.json"}, especially {"error.details.missing_connections[]"} when the caller needs to complete one of several platform connections. Legacy recovery hints such as {"authorization_url"}, {"authorization_instructions"}, or {"reference_authorization"} remain valid when safe to disclose. Recovery: correctable (complete or restore the required authorization, then retry).
**Suggested action:** do NOT auto-retry — credentials were rejected; rotate keys, refresh OAuth tokens once if applicable, otherwise escalate to a human
Credentials were presented but rejected — revoked, malformed signature, or a key no longer in the seller's keystore. Sellers MUST return this code when an {"Authorization"} header was present but verification failed. Recovery: terminal. Exception: agents with a valid OAuth 2.1 refresh grant MAY treat this as correctable when the rejection reason is token expiry — silently refresh and retry once; if the refresh fails or the seller explicitly signals revocation, escalate to human.
**Suggested action:** provide credentials via the auth header and retry
No credentials were presented. Sellers MUST return this code when no {"Authorization"} header was included in the request. Recovery: correctable (provide credentials via the auth header and retry).
**Suggested action:** provide credentials when missing; do NOT auto-retry rejected credentials — escalate for rotation
**Deprecated** — use {"AUTH_MISSING"} (no credentials presented) or {"AUTH_INVALID"} (credentials presented and rejected). Retained as a backward-compatible alias during the 3.x deprecation window. Recovery: correctable.
**Suggested action:** align media-buy and package bidding scopes with the provider's supported placement, or choose a compatible budget mode/product combination
The authored media-buy/package bidding scopes cannot be represented by the provider's native campaign, package, or shared-strategy placement rules. Sellers MUST detect this before any provider mutation and SHOULD identify the conflicting scopes and provider constraint in error.details. Recovery: correctable (remove or align package overrides, move the policy to the supported scope, or choose a compatible budget mode/product combination).
**Suggested action:** retry with error.details.suggested\_billing (typically 'operator') when present; when absent, surface to a human at the buyer — the agent cannot unilaterally extend its commercial relationship and MUST NOT auto-retry
The seller's {"supported_billing"} capability accepts the requested model, but the calling buyer agent's commercial relationship with the seller does not — e.g., the agent is onboarded as passthrough-only (no payments relationship — only the operator can be invoiced) and {"billing: 'agent'"} or {"billing: 'advertiser'"} is rejected even though the seller supports both at the capability level. Distinct from {"BILLING_NOT_SUPPORTED"} (seller-wide capability) by being narrowly per-buyer-agent: the gate is the seller's onboarding record for this caller, not the seller's global wire capability. Sellers MUST emit this code only after agent identity has been established via signed-request derivation or a credential-to-agent mapping in the seller's onboarding record; callers without established identity MUST receive {"BILLING_NOT_SUPPORTED"} instead, to prevent the distinct code from acting as an onboarding oracle. The recovery shape is deliberately minimal — {"error.details"} MUST conform to {"error-details/billing-not-permitted-for-agent.json"} ({"rejected_billing"} plus an optional single {"suggested_billing"} retry value, typically {"operator"}) and MUST NOT carry the agent's full permitted-billing subset, rate cards, payment terms, credit limit, billing entity, or any other per-agent commercial state. Recovery: correctable (retry with {"error.details.suggested_billing"} when present; when absent, surface to a human at the buyer — the agent cannot unilaterally extend its commercial relationship and MUST NOT auto-retry, since payments-relationship onboarding with the seller is offline).
**Suggested action:** check get\_adcp\_capabilities for supported\_billing and resubmit with a supported value, or omit billing to accept the seller's default
The seller declines the requested {"billing"} value either at the seller-wide capability level ({"supported_billing"} does not include the value) or at the per-account-relationship level (e.g., the seller accepts {"operator"} billing in general but has no direct billing relationship with the operator on this specific account). The default reject code for billing-value mismatches; {"error.details"} SHOULD conform to {"error-details/billing-not-supported.json"} ({"scope"} ∈ {"{\"capability\", \"account\"}"} plus optional {"supported_billing"} echo for the {"\"capability\""} scope) so callers can dispatch without parsing prose. Distinct from {"BILLING_NOT_PERMITTED_FOR_AGENT"}, which is narrowly scoped to the calling buyer agent's commercial relationship with the seller (passthrough-only vs agent-billable) rather than to the seller's capability or per-account state. Sellers MUST emit {"BILLING_NOT_PERMITTED_FOR_AGENT"} only when agent identity has been established via signed-request derivation or a credential-to-agent mapping in the seller's onboarding record; in all other cases (unauthenticated callers and bearer credentials not mapped to a specific agent record) sellers MUST return {"BILLING_NOT_SUPPORTED"} and MUST omit {"error.details.scope"} — emitting the per-agent code or the {"\"account\""}-scope hint without established identity is a cross-tenant onboarding oracle (same uniform-response shape required by the {"*_NOT_FOUND"} family). Recovery: correctable (check {"get_adcp_capabilities"} for {"supported_billing"} and resubmit with a value the seller supports, or omit {"billing"} to accept the seller's default).
**Suggested action:** do not retry — billing for this account runs through a non-AdCP channel. Pre-filter via capabilities.creative.bills\_through\_adcp before sending report\_usage; flag the account in the buyer's routing table and fall back to the ad server's native billing export for cost reconciliation
A creative-agent billing-loop operation ({"report_usage"} is the canonical case) received a well-formed record that the agent will not bill on because this account bills via a non-AdCP channel — flat license, SaaS contract, bundled enterprise agreement, or any other out-of-band arrangement. The agent returns {"accepted: 0"} with the offending record(s) listed in {"errors[]"} carrying this code; the request itself is valid and silent acceptance would break buyer-side reconciliation. Distinct from {"BILLING_NOT_SUPPORTED"} (the seller declines a specific {"billing"} value on a media-buy account where AdCP billing is otherwise in scope) and {"BILLING_NOT_PERMITTED_FOR_AGENT"} (per-buyer-agent commercial gate on an otherwise-billable surface) by signaling that the entire billing surface is offline for this account, not that a specific value or caller is rejected. Buyers SHOULD pre-filter by reading {"capabilities.creative.bills_through_adcp"} from {"get_adcp_capabilities"} before issuing {"report_usage"}; agents that have not yet declared the capability remain in the probe-to-discover mode. The error is returned per-record (in the {"report_usage"} response {"errors[]"} array with {"field"} pointing at {"usage[N]"} or a specific record subpath), not at the envelope level. The code itself is the discriminator; no {"error.details"} shape is defined for this code (mirroring {"CONFIGURATION_ERROR"}'s discriminator-by-code pattern). Recovery: terminal — auto-retry will not change the outcome; the buyer SHOULD flag the account in its routing table so reconciliation falls back to the ad server's native billing export (or whatever offline channel the agent uses) rather than expecting AdCP-side cost truth.
**Suggested action:** include brand (domain plus optional brand\_id) on the request
A billable operation was attempted without a brand reference. Every billable operation requires either a seller-assigned {"account_id"} or a natural key including {"brand"}. Recovery: correctable (include {"brand"} — {"domain"} plus optional {"brand_id"} — on the request).
**Suggested action:** raise max\_spend, or reduce max\_creatives/max\_variants, to produce the remaining items
build\_creative stopped producing early because the next leaf would exceed the request's max\_spend ceiling. Normally a SUCCESSFUL partial build (BuildCreativeVariantSuccess with budget\_status: 'capped' and an advisory BUDGET\_CAP\_REACHED entry — every returned leaf is real and billed); returned as a terminal error only when even the first leaf would exceed the cap (no partial possible). Distinct from BUDGET\_EXCEEDED (would exceed a media-buy/package allocation — a rejection) and BUDGET\_EXHAUSTED (already spent). Recovery: correctable (raise max\_spend, or reduce max\_creatives/max\_variants).
**Suggested action:** reduce requested amount or increase budget allocation
Operation would exceed the allocated budget for the media buy or package. Distinct from BUDGET\_EXHAUSTED (already spent) and BUDGET\_TOO\_LOW (below minimum). Recovery: correctable (reduce requested amount or increase budget allocation).
**Suggested action:** buyer must add funds or increase budget cap
Account or campaign budget has been fully spent. Distinct from BUDGET\_TOO\_LOW (rejected at submission). Recovery: terminal (buyer must add funds or increase budget cap).
**Suggested action:** increase budget or check capabilities.media\_buy.limits
Budget is below the seller's minimum. Recovery: correctable (increase budget or check capabilities.media\_buy.limits).
**Suggested action:** wait for the escalation to resolve; contact the plan operator if the suspension persists
Campaign governance has been suspended pending human review; the governance agent MUST reject {"check_governance"} and {"report_plan_outcome"} calls on the affected plan until the escalation is resolved. Distinct from {"ACCOUNT_SUSPENDED"} (account-wide) — this is scoped to a single plan/campaign. Recovery: transient (wait for the escalation to resolve; contact the plan operator if the suspension persists).
**Suggested action:** remove unused catalogs, or contact the seller to raise the limit
The account has reached its maximum catalog count. Recovery: correctable (remove unused catalogs, or contact the seller to raise the limit).
**Suggested action:** choose a format that supports the required disclosure positions and persistence modes, or remove the disclosure requirement
A required disclosure from the brief's compliance section cannot be satisfied by the target format — either the required position or the required persistence mode is not in the format's disclosure\_capabilities. Recovery: correctable (choose a format that supports the required disclosure positions and persistence modes, or remove the disclosure requirement).
**Suggested action:** surface to a human at the seller — the buyer cannot resolve a seller-side deployment misconfiguration and MUST NOT auto-retry
The seller's deployment is misconfigured in a way that prevents handling the request — the buyer cannot fix it, retrying will not help, and reporting to the seller's operator is the only remediation. Examples: account declared with {"mode: 'mock'"} but no {"mock_upstream_url"} populated; platform declared with {"mode: 'live'"} or {"mode: 'sandbox'"} but no {"upstream_url"} declared; required environment variable unset on the seller process. Distinct from {"INVALID_REQUEST"} (buyer-fixable; the request itself is malformed), {"SERVICE_UNAVAILABLE"} (transient; retry-with-backoff may succeed), {"UNSUPPORTED_FEATURE"} (capability mismatch — the seller does not implement the requested specialism), {"ACCOUNT_SETUP_REQUIRED"} (buyer-side onboarding incomplete; this code is seller-side deployment incomplete), and {"GOVERNANCE_UNAVAILABLE"} (governance-agent-scoped; transient). Wire placement. The deployment cannot produce a success artifact, so sellers MUST flip transport-level failure markers (HTTP 5xx, MCP {"isError: true"}, A2A {"failed"}) and populate both layers per the two-layer model in {"error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model"}. The code itself is the discriminator; no {"error.details"} shape is defined for this code (mirroring the minimal-disclosure precedent of {"AGENT_SUSPENDED"} / {"AGENT_BLOCKED"}). Sellers SHOULD populate {"error.message"} with operator-actionable detail (which metadata key is missing, which env var is unset) and MUST NOT include credentials, connection strings, or stack traces — the message is wire-visible to the buyer. Recovery: terminal — the buyer MUST surface to the seller's operator and MUST NOT auto-retry (retries cannot resolve a misconfigured deployment until the operator intervenes).
**Suggested action:** re-read the resource and retry with current state
Concurrent modification detected. The resource was modified by another request between read and write. Recovery: transient (re-read the resource and retry with current state).
**Suggested action:** emit one canonical format selector route, or make every required legacy 3.x compatibility projection select the same product format contract under the canonical v2-narrows-v1 comparison
A 3.x package request carries multiple resolvable format selector routes that select different canonical product format declaration sets. Sellers MUST first resolve every present route independently ({"format_option_refs"}, direct {"format_kind"} plus {"params"}, and deprecated {"format_ids"}) without applying precedence. An unresolved option reference or an unprojectable legacy ID is rejected with {"UNSUPPORTED_FEATURE"}, not this code. Once all routes resolve, sellers derive the product {"format_options[]"} entries selected by each route using directional product satisfaction and require those sets to match. Legacy parameter compatibility uses the asymmetric v2-narrows-v1 relation defined by canonical formats, not raw object equality. For fixed-size image selectors, both width and height participate in compatibility. Sellers MUST reject different format shapes, selected option sets, or incompatible dimensions rather than silently choosing the canonical route. {"error.field"} SHOULD point at the conflicting package, and {"error.details"} SHOULD identify the supplied selector routes and their normalized canonical summaries. Recovery: correctable (emit one canonical selector route, or make a required legacy 3.x compatibility projection select the same product format contract).
**Suggested action:** check creative\_deadline via get\_media\_buys before submitting changes, or negotiate a deadline extension with the seller
Creative change submitted after the package's creative\_deadline. Distinct from CREATIVE\_REJECTED (content-policy, brand-safety, or accessibility-review failure). Recovery: correctable (check creative\_deadline via get\_media\_buys before submitting changes, or negotiate a deadline extension with the seller).
**Suggested action:** verify the asset URLs in creative\_manifest are reachable without agent-side credentials, then re-submit
A creative governance agent (get\_creative\_features) could not retrieve the submitted creative\_manifest assets for evaluation — an asset URL was unreachable, returned an error, or required credentials the agent does not hold. Distinct from CREATIVE\_NOT\_FOUND (a creative\_id absent from the agent's library, not an asset-fetch failure) and CREATIVE\_REJECTED (assets retrieved but failed creative review). Recovery: correctable (verify the asset URLs are reachable without agent-side credentials, then re-submit).
**Suggested action:** supply or assign a creative variant matching every in-scope format option's accepted\_language\_ranges, narrow placement scope, choose a compatible format option, or change an ineligible serve\_default
A creative bound to a locale-constrained product format has no materialized variant matching locale\_policy.accepted\_language\_ranges, lacks protocol-declared locale topology, or uses serve\_default with a seller-ineligible default variant. Seller ranges use RFC 4647 Basic Filtering and are applied independently for every placement where the assignment may serve, before buyer Lookup, locale\_fallbacks, or default selection. Distinct from CREATIVE\_REJECTED because this is a mechanically discoverable assignment-eligibility mismatch, not subjective content review. error.field SHOULD point to the offending creative or assignment; error.details SHOULD include format\_option\_id when present, accepted\_language\_ranges, available\_variant\_locales, and placement identity when applicable. Recovery: correctable (supply or assign a matching materialized locale variant, narrow placement scope, choose a compatible format option, or change an ineligible serve\_default).
**Suggested action:** add the required destination URL and resubmit the creative
A submitted creative that requires a destination URL does not provide one. Sellers SHOULD identify the missing buyer-visible field in error.field and MUST NOT expose downstream ad-server names or internal object identifiers in the buyer-facing message. Recovery: correctable (add the required destination URL and resubmit the creative).
**Suggested action:** verify creative\_id via list\_creatives, or sync\_creatives to register it
Referenced creative does not exist in the agent's creative library. Recovery: correctable (verify creative\_id via list\_creatives, or sync\_creatives to register it). Sellers MUST return this code uniformly for any creative\_id not owned by the calling account — never distinguish 'exists in another tenant' from 'does not exist', which would enable cross-tenant enumeration.
**Suggested action:** revise the creative according to the applicable advertising policy or validated accessibility criteria
Creative failed content-policy, brand-safety, or accessibility review. For deadline violations, see CREATIVE\_DEADLINE\_EXCEEDED. Accessibility failures SHOULD use structured details conforming to error-details/accessibility-violation.json. Recovery: correctable (revise the creative according to the applicable policy or validated accessibility criteria).
**Suggested action:** inspect every error.details.representation\_rejections entry, then choose a compatible format option or supply a compatible representation
No representation in a CreativeRepresentationSet is compatible with the selected target capability or product format option. The resolver MUST retain the complete representation set and MUST include one {"error.details.representation_rejections[]"} entry per candidate, conforming to {"error-details/creative-representation-unresolved.json"}; silent seller guessing is forbidden. Recovery: correctable (choose a compatible product/format option, add a compatible representation under a new revision, or fix the rejected asset contract).
**Suggested action:** resend the exact content previously bound to this revision\_id, or mint a new revision\_id for changed content
A sync\_creatives item reused a revision\_id for different canonical revision content under the same creative\_id. Revision identity is scoped to the parent creative and immutable after first acceptance. Sellers MUST evaluate the buyer input before transcoding or normalization, MUST leave the prior creative state unchanged, and SHOULD return details conforming to error-details/creative-revision-content-mismatch.json. Distinct from IDEMPOTENCY\_CONFLICT: idempotency\_key protects one request replay window, while revision identity protects creative content across requests and retention. Recovery: correctable (resend the exact content previously bound to this revision\_id, or mint a new revision\_id for the changed content).
**Suggested action:** resize or replace the creative with a size accepted by every selected package that may serve it
The submitted creative dimensions do not match any size accepted by the selected packages. Sellers SHOULD identify the offending creative in error.field and MAY include the submitted and accepted dimensions in buyer-safe error.details. Recovery: correctable (resize or replace the creative with a size accepted by every selected package that may serve it).
**Suggested action:** correct the buyer-visible validation problem and resubmit the creative
The creative failed buyer-correctable validation, but the producer cannot classify the failure with a more specific standard code. Producers SHOULD prefer a specific creative code whenever one applies and MUST keep buyer-facing messages free of vendor identifiers, internal object names, internal IDs, and stack traces. Recovery: correctable (correct the buyer-visible validation problem and resubmit the creative).
**Suggested action:** pick a value from error.details.allowed\_values (or re-fetch the format) and resubmit
A submitted text-asset value is not in the format's declared {"allowed_values"} list. Distinct from {"CREATIVE_REJECTED"} (generic creative-review failure) by being a closed-set constraint violation that the buyer can resolve mechanically without policy interpretation — the seller has published the complete list of acceptable values on the format, and any value outside that list is rejected by definition. The seller MUST set {"error.field"} to the offending asset's path within the manifest (e.g., {"creatives[0].creative_manifest.assets[0].value"} or the field name declared by the format) and SHOULD include the format's {"allowed_values"} array in {"error.details.allowed_values"} so the buyer agent can re-prompt its LLM with constrained sampling. Recovery: correctable (select a value from {"allowed_values"} and resubmit).
**Suggested action:** do NOT auto-retry — auto-retry re-logs the credential on each attempt. Move authentication material or caller-supplied trust material out of request args (top-level, {"context"}, {"ext"}, any nested location) onto the relevant transport authentication/trust channel or account provisioning path (Authorization: Bearer, RFC 9421 signature/JWKS, mTLS, MCP/A2A authentication framing); rotate any leaked credential, then resubmit
The seller detected authentication material or caller-supplied trust material placed in request args (top-level, in {"context"}, in {"ext"}, or any other nested location in the task payload) instead of arriving on the relevant transport authentication or trust channel. This includes buyer-principal credentials that should arrive on the inbound transport ({"Authorization: Bearer"} per RFC 6750 §2 for HTTP, RFC 9421 signature headers for signed requests, MCP/A2A authentication framing per RFC 9728 §3), and evaluator-call credentials or JWK/JWKS/JWKS-URI trust material smuggled into evaluator-related payload fields instead of being established through the creative agent's outbound transport authentication to the evaluator. Distinct from {"AUTH_REQUIRED"} (no credentials presented or presented credentials rejected on the transport channel) and {"PERMISSION_DENIED"} (authenticated caller not authorized for the action). Distinct from the receiver-side credentials carried in {"push_notification_config.authentication.credentials"}, which configure the seller's webhook callback authentication and are not buyer-principal or evaluator-call credentials — those are an explicit carve-out and MUST NOT trigger this code. Sellers SHOULD reject credential-in-args under AdCP 3.1; the requirement upgrades to MUST 90 days after the 3.1 publication date. Recovery: terminal — the agent MUST NOT auto-retry. Auto-retry against this code re-logs the credential on each attempt across the seller's request logs, observability stack, and any LLM-context surfaces in the buyer-side recovery loop, exactly the prompt-injection exfiltration surface that motivated the rule. Wire placement. Sellers MUST flip transport-level failure markers (HTTP 4xx, MCP {"isError: true"}, A2A {"failed"}) and populate both layers per the two-layer model in {"error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model"}. The code itself is the discriminator; no {"error.details"} shape is defined, and {"error.field"} MUST NOT echo the offending credential value or any prefix of it (e.g., {"\"Bearer ey...\""}). {"error.message"} MUST be generic and MUST NOT contain credential material. Sellers MUST drop the smuggled credential from logs, audit rows, and observability spans before persisting the rejection — the rejection itself is otherwise an exfiltration surface.
**Suggested action:** obtain a latest checkpoint, rebuild authoritative account snapshots, then drain changes after the checkpoint
The list\_account\_changes cursor is no longer within the seller's retained account change window. The seller MUST NOT silently restart from the retention boundary. Recovery: correctable (obtain a new starting\_position: latest checkpoint, rebuild every authoritative account snapshot, then drain changes after that checkpoint). error.details SHOULD include available\_since and MAY include a replacement starting-position hint, without disclosing inaccessible history.
**Suggested action:** replace the evaluator agent\_url (evaluator.feature\_agent.agent\_url or the evaluator agent-form agent\_url) with one from the seller's published accepted\_verifiers, or drop the evaluator agent pointer to fall back to seller-default ranking
Buyer attached an evaluator agent pointer on {"build_creative"} — {"evaluator.feature_agent.agent_url"} or the {"evaluator"} agent-form {"agent_url"} — that does not match (canonicalized per /docs/reference/url-canonicalization: lowercase scheme and host, strip default port, normalize path dot-segments) any entry in the seller's {"creative_policy.accepted_verifiers[].agent_url"}. The producing agent does not call buyer-asserted endpoints outside its allowlist; this mirrors {"PROVENANCE_VERIFIER_NOT_ACCEPTED"} for the gate/rank evaluator path — the buyer represents which on-list agent it used, the seller is the agent-of-record and calls only allowlisted agents. {"error.field"} MUST point at the offending {"agent_url"} path; {"error.details"} SHOULD include a reference to the product whose {"creative_policy.accepted_verifiers"} the buyer should consult. Recovery: correctable (replace the agent\_url with one from the seller's published {"accepted_verifiers"}, or drop the evaluator agent pointer to fall back to seller-default ranking).
**Suggested action:** check URL accessibility, authentication, and that content matches the declared feed\_format
Platform could not fetch the catalog feed URL during sync\_catalogs. Recovery: correctable (check URL accessibility, authentication, and that the content matches the declared feed\_format).
**Suggested action:** drop the disallowed field(s) and retry
A request field is not in the caller's {"field_scopes"} allowlist for this task. Sellers declaring {"field_scopes"} on the account's {"authorization"} object MUST reject any request that sets a non-allowlisted field with this code. Distinct from {"VALIDATION_ERROR"} (schema/business-rule violation) - the field is valid, just not writable by this caller. {"error.field"} MUST identify the exact offending field path (e.g., {"packages[0].budget"}); when multiple fields are disallowed, sellers SHOULD return one error per field, or MAY enumerate them in {"error.details.fields"}. Recovery: correctable and agent-autonomous - agent may drop the disallowed field(s) and retry.
**Suggested action:** advisory — seller-side fix needed: producer is emitting disagreeing format\_ids and format\_options for the same product. Buyer SDK SHOULD prefer format\_options and surface the divergent product to operators; do not auto-retry
Non-fatal advisory raised when a product carries BOTH {"format_ids"} (v1) AND {"format_options"} (v2) and the two disagree (different canonical, different dimensions, different orientation) after projection. The producer's contract is that both shapes MUST refer to the same underlying declaration; divergence is a producer bug.
Either side MAY emit this code: a SELLER may self-detect on emit (own producer bug; rare), or more commonly a consumer-SDK detects on consumption. SDKs MUST prefer {"format_options"} (the richer surface) when both are present and MUST surface the divergent product so it's observable rather than silently picked-one-and-dropped-other. Hard-failing the entire {"get_products"} response is discouraged — it punishes downstream buyers for the producer bug.
**Surface placement (normative).** Same single-surface mandate as {"FORMAT_PROJECTION_FAILED"}: SDKs that detect this on consumption MUST augment the response's {"errors[]"} array with an entry carrying {"source: \"sdk\""}, {"sdk_id: \"@\""}, {"code: \"FORMAT_DECLARATION_DIVERGENT\""}, and the field+details described below. Logger-only is insufficient; lint-output channels are NOT acceptable as the surface (the multi-hop agent network needs warnings to propagate across SDK boundaries via the wire response).
{"error.field"} MUST point at the offending product; {"error.details"} SHOULD carry {"{ product_id, format_ids, format_options_summary, divergence_reason }"} so buyer SDKs can flag the producer for follow-up.
**Multi-hop deduplication.** Each hop that detects the same divergence SHOULD deduplicate by {"(code, field)"} rather than re-emit; the existing entry's {"sdk_id"} identifies which earlier processor saw it first.
Recovery: correctable but seller-side — buyer can't fix divergent declarations, only flag them.
**Suggested action:** advisory — seller-side fix needed: the v2 declaration's canonical has only family-level structural registry entries (no invertible literal). Seller MUST author v1\_format\_ref on the v2 declaration to disambiguate; SDKs MUST NOT synthesize. Do not auto-retry
Non-fatal advisory raised when an SDK detects that a product's v2 declaration cannot be unambiguously projected back to a single v1 named format because the v1-canonical-mapping registry has only family-level structural entries for this canonical (no invertible {"format_id_glob"} literal). The family is known (e.g., 'this is a video\_vast'); the specific v1 named format isn't pickable mechanically. Distinct from {"FORMAT_PROJECTION_FAILED"} (registry-coverage gap, correctable by adding a registry entry) — ambiguity is structural: the family is defined but a specific format can't be picked without seller assertion.
Surface placement: same single-mandate as {"FORMAT_PROJECTION_FAILED"} and {"FORMAT_DECLARATION_DIVERGENT"} — SDKs MUST augment the response's {"errors[]"} array with an entry carrying {"source: \"sdk\""}, {"sdk_id"}, {"code: \"FORMAT_DECLARATION_V1_AMBIGUOUS\""}, {"field"} pointing at the offending declaration, and {"error.details"} SHOULD carry {"{ format_kind, registry_matches: [], product_id }"}
so adopters can see why the inversion was ambiguous.
**SDKs MUST NOT synthesize a v1\_format\_ref** in this case (or any other case). v1↔v2 explicit pairing is seller-asserted only — SDKs encountering family-only registry matches MUST treat the v2 declaration as v1-unreachable and surface this code rather than invent a plausible v1 format\_id. The seller's path: author {"v1_format_ref"} on the v2 declaration to disambiguate (the authoritative pairing per {"v1-canonical-mapping.json"} resolution step 1), or accept that v1-only buyers won't see this product. Recovery: correctable but seller-side — buyer can't disambiguate without the seller's assertion.
**Suggested action:** advisory — emitted alongside the partial v1 emission, NOT in place of it: the v2 declaration carries {"params.sizes[]"} with N entries but only M v1\_format\_ref entries (M \< N), so v1 buyers see partial size coverage on the product. Seller-side fix: add v1\_format\_ref entries for the missing sizes. SDK MAY (non-normative) fan out automatically by catalog lookup. Non-fatal — do not auto-retry
Non-fatal advisory raised when a v2 declaration carries {"params.sizes[]"} with N entries but only M v1\_format\_ref entries (M \< N). The seller has asserted some v1 named formats but not enough to cover all declared sizes — v1-only buyers see partial coverage on the product. Emitted **alongside** the partial v1 emission (NOT in place of it): the product still appears on the v1 wire under the M sizes the seller covered; this code tells v1-aware downstream agents that N-M sizes were dropped from the projection.
Surface placement: SDKs that detect on emission OR consumption MUST augment the response's {"errors[]"} with {"source: \"sdk\""} (or {"\"producer\""} if the seller self-detects on emit), {"sdk_id"}, {"code: \"FORMAT_DECLARATION_V1_LOSSY_MULTI_SIZE\""}, {"field"} pointing at the offending declaration, and {"error.details"} SHOULD carry {"{ product_id, declared_sizes: [{w,h}, …], covered_sizes: [{w,h}, …], dropped_sizes: [{w,h}, …] }"} so buyer agents see which sizes were lost.
**SDKs MAY (non-normative) fan out automatically** by catalog lookup — for each entry in {"sizes[]"} lacking a corresponding {"v1_format_ref"}, the SDK consults the AAO catalog for the per-size v1 named format (e.g., for {"{width: 728, height: 90}"} look up {"display_728x90_image"}) and emits it under {"format_ids[]"}. This is opt-in (requires catalog access); when SDKs fan out, they SHOULD still emit this code as a transparency advisory so downstream consumers know the v1 emit was synthesized rather than seller-asserted.
Recovery: warning — non-fatal, no retry. Seller fix: add {"v1_format_ref[]"} entries for the missing sizes.
**Suggested action:** refresh get\_adcp\_capabilities creative.supported\_formats\[] and retry with a capability\_id whose operations contains the intended build, preview, or validate operation
A requested creative operation route is not supported by this creative agent. On the canonical 3.2 path, returned when build\_creative.target\_capability\_id(s), preview\_creative.target\_capability\_id, or validate\_input targets\[] kind capability does not match an advertised creative.supported\_formats\[].capability\_id carrying the requested operation. Also returned when preview renderer inference has zero or multiple compatible matches. Sellers SHOULD attribute the error to the selector field and MAY include supported capability IDs in error.details.supported\_capability\_ids when safe. Deprecated target\_format\_id(s) and preview format\_id retain legacy named-format error attribution during the 3.x compatibility window. Recovery: correctable (read get\_adcp\_capabilities creative.supported\_formats\[] and retry with a capability\_id whose operations contains the intended operation).
**Suggested action:** advisory — publisher-side fix needed: a placement's {"format_options[].format_option_id"} references a {"format_option_id"} that does not exist in this file's top-level {"formats[]"}. Buyer SDK MUST fail closed for that placement (drop the format from the placement's accepted set) and surface this code. Publisher fix: either declare the missing format option in {"formats[]"} or remove the reference from the placement. Do not auto-retry
Non-fatal advisory raised when a placement in {"adagents.json"} (or any consumer of {"placement-definition.json"}) carries {"format_options[].format_option_id"} referencing a {"format_option_id"} that does NOT exist in the file's top-level {"formats[]"}. The reference is broken — the publisher's catalog claims the placement accepts a format option that isn't declared.
**Resolution scope is same-file only.** Cross-file {"format_option_id"} lookup is not supported by design (closes off format\_option\_id squatting across publisher boundaries — a malicious file cannot reference another publisher's format\_option\_id and claim its narrowing). Buyer SDKs MUST fail closed for the placement (drop the format from the placement's accepted format set) and MUST surface this code rather than silently dropping or guessing what the publisher meant.
Surface placement: same single-mandate as the other FORMAT\_\* codes — SDKs that detect on consumption MUST augment the response's {"errors[]"} with {"source: \"sdk\""}, {"sdk_id"}, {"code: \"FORMAT_OPTION_UNRESOLVED\""}, {"field"} pointing at the offending placement (e.g., {"placements[2].format_options[1].format_option_id"}), and {"error.details"} SHOULD carry {"{ placement_id, format_option_id, declared_format_options: [] }"}
so the publisher can fix.
Recovery: correctable but publisher-side — buyer can't fix; publisher either declares the missing format option in {"formats[]"} or removes the reference from the placement.
**Suggested action:** advisory — seller-side fix needed: ask the seller to add an explicit {"canonical"} field on the legacy format declaration, or contribute a registry entry (format\_id\_glob or structural match) to v1-canonical-mapping.json. Do not auto-retry; the product is still valid on the legacy named-format path
Non-fatal advisory raised when a legacy named format on a product cannot be projected to a canonical-formats {"ProductFormatDeclaration"} via the resolution order in {"v1-canonical-mapping.json"} (explicit {"canonical"} field → format\_id\_glob → structural match → fail-closed). The product is still valid on the legacy named-format path; only the 3.1+ {"format_options"} projection failed. Primarily a **consumer-SDK concern** — the seller didn't fail; the consumer-side SDK couldn't project on their behalf. {"error.field"} MUST point at the offending product (e.g., {"products[3].format_ids[0]"}); {"error.details"} SHOULD carry {"{ format_id, product_id, resolution_failure: \"no_explicit_canonical\" \u007c \"no_registry_match\" \u007c \"no_structural_match\" }"} so buyer SDKs can route remediation (suggest the seller add an explicit {"canonical"} field, or file a registry PR).
**Surface placement (normative).** SDKs that detect this on consumption MUST augment the response's {"errors[]"} array with an entry carrying {"source: \"sdk\""}, {"sdk_id: \"@\""}, {"code: \"FORMAT_PROJECTION_FAILED\""}, and the field+details described above. This is the single mandated surface — logger-only is insufficient and a separate lint-output channel is NOT acceptable (AdCP is a multi-hop agent network; warnings need to propagate across hops or each hop has to re-detect locally). Sellers MAY emit this code on their own response when they self-detect a non-projectable format on emit; producer-emitted entries omit {"source"} (or set {"source: \"producer\""}). The response stays 200/success regardless of who emits; this is non-fatal.
**Multi-hop deduplication.** Each hop that detects the same condition SHOULD deduplicate by {"(code, field)"} rather than re-emit. The existing entry's {"sdk_id"} identifies which earlier processor saw it first; downstream SDKs SHOULD NOT add a second entry for the same {"(code, field)"} pair unless they have materially different {"error.details"} (e.g., a different {"resolution_failure"} reason from a different registry version).
Recovery: correctable (seller-side action — add explicit {"canonical"} field on the legacy format file, contribute a v1-canonical-mapping registry entry, or author a 3.1+ {"ProductFormatDeclaration"} with {"v1_format_ref"} linking back). See canonical-formats.mdx 'Dual emission and v2↔v1 projection' for the full rules.
**Suggested action:** advisory — migrate the legacy custom format\_shape to error.details.promoted\_to before error.details.transition\_end; dual emission is allowed during the transition window. Do not auto-retry
Non-fatal deprecation advisory raised when a 3.2-aware SDK encounters {"format_kind: custom"} with a {"format_shape"} that has been promoted to a first-class canonical. SDKs MUST preserve the declaration during its transition window and SHOULD augment the containing response's {"errors[]"} with {"source: sdk"}, {"sdk_id"}, this code, and {"details: { format_shape, promoted_to, promotion_release, transition_end }"}. Producers that self-detect their own legacy declaration MAY emit the same advisory with {"source: producer"}. Recovery is seller-side: dual-emit during the published transition window, migrate consumers, then replace the custom declaration with the promoted canonical.
**Suggested action:** select a governance agent matching {"error.details.accepted_governance_agents"}, then retry {"sync_governance"} with a fresh idempotency key
The governance agent proposed in {"sync_governance"} does not satisfy the seller's authoritative per-account acceptance criteria. The failed binding MUST NOT be persisted or contacted, and credentials supplied for it MUST NOT be echoed in responses or logs. {"error.details"} SHOULD conform to {"error-details/governance-agent-not-accepted.json"}. Distinct from {"GOVERNANCE_UNAVAILABLE"}, which means a verification criterion or registry could not be resolved and is retryable. Recovery: correctable (select an agent satisfying the returned criteria or resolve the account-specific requirement with the seller).
**Suggested action:** restructure the buy, escalate to human spending authority, or contact the governance agent for details
A registered governance agent denied the transaction. Sellers MUST place the denial in the operation's structured rejection arm when one exists (e.g., {"acquire_rights"} → {"AcquireRightsRejected"}, or an {"approval_webhook"} delivery → {"CreativeRejected"}); otherwise in {"errors[]"} + {"adcp_error"}. Buyers MUST dispatch on the response's discriminated {"status"} first and fall back to {"errors[].code"} / {"adcp_error.code"} only when no rejection arm exists for that operation. The buyer may restructure the buy (e.g., reduce budget, split into smaller transactions), escalate to human spending authority, or contact the governance agent for details. Recovery: correctable.
Wire placement (full guidance). Governance denial is a structured business outcome, not a system error — the governance call SUCCEEDED and the agent returned a denial verdict. Two cases:
1. Operation or webhook payload defines a structured rejection arm. The arm IS the canonical denial shape. The seller populates {"reason"} (human-readable, propagating governance findings) and {"suggestions"} (optional) and does NOT additionally emit {"GOVERNANCE_DENIED"} in {"errors[]"} or {"adcp_error"}. The rejection arms enforce this at the schema layer: e.g., {"AcquireRightsRejected"} and {"CreativeRejected"} both declare {"not: { required: [errors] }"}, so dual-emission is already a schema violation. The code does not appear on the wire when the rejection arm is used. Transport-level success markers MUST NOT be flipped (HTTP 200, MCP {"isError: false"}, A2A {"succeeded"}) — the operation completed successfully and produced a structured response.
2. Operation response has no rejection arm (e.g., {"create_media_buy"} returns Success / Error / Submitted arms only). The seller populates {"errors[].code: GOVERNANCE_DENIED"} in the payload AND {"adcp_error.code: GOVERNANCE_DENIED"} on the envelope per the two-layer model in {"error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model"}. Transport-level failure markers DO flip in this case (HTTP 4xx, MCP {"isError: true"}, A2A {"failed"}) — the task could not produce a success artifact.
The rule generalizes to any current or future operation or webhook payload whose response defines a discriminated rejection arm. In either placement, sellers SHOULD propagate governance findings verbatim — buyers' recovery decisions depend on what specifically was rejected. {"GOVERNANCE_DENIED"} is reserved for verdicts received from a reachable governance agent; if the governance call itself failed (timeout, network, config error), use {"GOVERNANCE_UNAVAILABLE"} instead.
**Suggested action:** retry with backoff; if the agent remains unreachable, the buyer MUST contact the plan's governance operator
A registered governance agent is unreachable. Sellers MUST place this code in {"errors[]"} + {"adcp_error"} (never a structured rejection arm) and flip transport-level failure markers (HTTP 5xx, MCP {"isError: true"}, A2A {"failed"}). Distinct from {"GOVERNANCE_DENIED"} (agent reachable and explicitly denied — see that code's wire-placement guidance). Recovery: transient (retry with backoff; if the agent remains unreachable, the buyer MUST contact the plan's governance operator — the seller MUST NOT proceed with the media buy without a valid decision).
Wire placement (full guidance). Governance unavailability is a system error — the governance call FAILED (timeout, network, config error) and the seller could not get a verdict at all. Always populate both layers per the two-layer model in {"error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model"}. Do NOT use a structured rejection arm for unavailability even when the task offers one — the buyer's recovery semantics differ (retry-with-backoff for unavailability vs. restructure-or-escalate for denial), and conflating them masks the system-error signal.
**Suggested action:** use a fresh UUID v4 for the new request, or resend the exact original payload to get the cached response
An earlier request with the same idempotency\_key was processed with a different canonical payload within the seller's replay window. Distinct from CONFLICT (concurrent write) — this indicates the client reused a key across semantically different requests. Recovery: correctable (use a fresh UUID v4 for the new request, or resend the exact original payload to get the cached response).
**Suggested action:** perform a natural-key check to determine whether the original request succeeded; if no evidence of success, generate a fresh idempotency\_key for a new attempt
The idempotency\_key was seen previously but its cached response has been evicted because it is past the seller's declared replay\_ttl\_seconds. Distinct from IDEMPOTENCY\_CONFLICT (different payload within window) — this indicates the retry arrived too late for at-most-once guarantees. Recovery: correctable (perform a natural-key reconciliation — e.g., call get\_media\_buys for the relevant account/status scope and match returned media\_buys\[].context.internal\_campaign\_id — to determine whether the original request succeeded, then either accept that result or generate a fresh idempotency\_key for a new attempt). If the buyer has any evidence the prior call succeeded (partial response received before crash, entry in the buyer's own DB, a webhook fired), the buyer MUST do the natural-key reconciliation BEFORE minting a new key — minting a new key in that situation is exactly how double-creation happens.
**Suggested action:** wait top-level error.retry\_after seconds and retry with the SAME idempotency\_key — MUST NOT mint a fresh key (turns a safe retry into a double-execution race)
A prior request with the same {"idempotency_key"} is still being processed and has not yet produced a cached response. The second request arrived before the first completed. Sellers MAY return this code instead of blocking the second caller until the first finishes — useful when the first call invokes a slow downstream system (SSP, ad server, payment provider). Distinct from IDEMPOTENCY\_CONFLICT (different canonical payload — a client bug) and from CONFLICT (concurrent modification of a different resource) — IDEMPOTENCY\_IN\_FLIGHT is the seller telling the buyer 'your retry was correct but your previous attempt is still running, come back shortly.' Sellers SHOULD populate top-level {"error.retry_after"} with an integer-second wait hint based on the first request's elapsed time and expected completion. Buyers MUST treat this as transient and MUST NOT mint a fresh {"idempotency_key"} — minting a new key turns a safe retry into a double-execution race. Recovery: transient (wait {"error.retry_after"} seconds and retry with the same {"idempotency_key"}; the second attempt will either replay the now-cached response or, if still in flight, return IDEMPOTENCY\_IN\_FLIGHT again).
**Suggested action:** verify the feed content matches the declared format
Catalog feed content does not match the declared feed\_format. Recovery: correctable (verify the feed content matches the declared format, e.g. XML for google\_merchant\_center).
**Suggested action:** verify pricing\_option\_id against the product's pricing\_options from get\_products or the vendor's discovery response, then resubmit with a valid ID
A {"pricing_option_id"} referenced in the request does not exist on the target account or product. Returned per-record in {"report_usage"} responses and at the request level for {"create_media_buy"} when the submitted pricing option cannot be resolved. {"error.field"} SHOULD point at the offending record path (e.g., {"usage[1].pricing_option_id"} or {"packages[0].pricing_option_id"}). Distinct from {"PRODUCT_NOT_FOUND"} (the product itself is unknown) by being narrowly about a pricing option within a known product or account. Recovery: correctable (verify {"pricing_option_id"} against the product's {"pricing_options"} from {"get_products"} or the vendor's discovery response, then resubmit with a valid ID).
**Suggested action:** check request parameters and fix
Request is malformed, missing required fields, or violates schema constraints. Recovery: correctable (check request parameters and fix).
**Suggested action:** check current status via get\_media\_buys and adjust request
Operation is not permitted for the resource's current status (e.g., updating a completed or canceled media buy, or modifying a canceled package). Recovery: correctable (check current status via get\_media\_buys and adjust request).
**Suggested action:** check required fields for the vendor type (vendor\_cost, currency, account at minimum), fix invalid values, and resubmit
A usage record in {"report_usage"} has missing or invalid fields — required fields absent, values out of range, or type mismatches. Returned per-record in the {"report_usage"} response {"errors[]"} array. {"error.field"} SHOULD point at the offending field path (e.g., {"usage[0].vendor_cost"}, {"usage[0].currency"}). Distinct from {"INVALID_REQUEST"} (top-level request malformed) by being scoped to individual usage records within an otherwise well-formed request. Recovery: correctable (check required fields for the vendor type — at minimum {"vendor_cost"}, {"currency"}, and {"account"} — fix the offending values, and resubmit).
**Suggested action:** review the proposal's insertion\_order, accept terms, and include io\_acceptance on accept\_proposal; use create\_media\_buy only for 3.x compatibility
The committed proposal requires a signed insertion order but no io\_acceptance was provided. Recovery: correctable (review the proposal's insertion\_order, accept terms, and include io\_acceptance on accept\_proposal; 3.x compatibility callers use create\_media\_buy).
**Suggested action:** check item\_issues for per-item rejection reasons and fix the offending items
One or more catalog items failed schema validation during sync\_catalogs. Recovery: correctable (check item\_issues for per-item rejection reasons and fix the offending items).
**Suggested action:** inspect error.details.macro\_resolution\_results and route to a resolver that supports the declared dialect, semantic, owner, and encoding depth
One or more declared creative macro tokens cannot be resolved or safely preserved under the selected product and seller capability intersection. Sellers MUST include per-token {"error.details.macro_resolution_results"}, conforming to {"error-details/macro-resolution-failed.json"}; unknown or ambiguous tokens remain byte-preserved and MUST NOT receive guessed values. Recovery: correctable (route to a compatible execution path, correct the verified declaration, or assign the proper downstream resolver).
**Suggested action:** verify media\_buy\_id; for legacy correlation use get\_media\_buys plus context, such as context.internal\_campaign\_id
Referenced media buy does not exist or is not accessible to the requesting agent. Recovery: correctable (verify media\_buy\_id; when recovering across legacy sellers or missing echoed IDs, reconcile via get\_media\_buys and the opaque request/response context correlation handle, such as context.internal\_campaign\_id, rather than deprecated top-level buyer\_ref).
**Suggested action:** sequence single-proposal finalize calls — one finalize entry per get\_products refine\[] call or per refine\_proposals refinements\[] call
Returned by sellers that cannot guarantee atomic commit across multiple proposals in a single finalize batch. Two call sites where this applies: (1) a {"get_products"} call with multiple {"action: 'finalize'"} entries in {"refine[]"} targeting different {"proposal_id"} values; (2) a {"refine_proposals"} call with multiple {"action: 'finalize'"} entries in {"refinements[]"} targeting different {"proposal_id"} values. The buyer's intent — atomic multi-proposal finalize — is structurally well-formed and per spec atomic on both surfaces, but this seller's downstream stack cannot satisfy the atomicity guarantee (e.g., the proposals route to two different ad servers with no 2PC). More specific than {"INVALID_REQUEST"} so buyers can distinguish 'this seller doesn't support multi-finalize' from 'the request itself is malformed'. Recovery: correctable (sequence the finalize calls one-{"proposal_id"}-per-call on whichever task surface the buyer is using; there is no capability flag for multi-finalize support, so a successful first-attempt is the only positive discovery signal). See [refinement guide § Finalize is exclusive](/docs/media-buy/product-discovery/refinement#finalize-is-exclusive-within-refine).
**Suggested action:** check the seller's cancellation policy or contact the seller
The media buy or package cannot be canceled in its current state. The seller may have contractual or operational constraints that prevent cancellation. Recovery: correctable (check the seller's cancellation policy or contact the seller).
**Suggested action:** verify package\_id; for legacy package correlation use get\_media\_buys plus package context, such as context.buyer\_ref
Referenced package does not exist within the specified media buy. Recovery: correctable (verify package\_id within the media buy; when recovering across legacy sellers or missing echoed product\_id, reconcile via get\_media\_buys and the package-level context correlation handle, such as context.buyer\_ref, rather than deprecated top-level buyer\_ref).
**Suggested action:** omit payment\_terms to accept the seller's default, retry with a different supported value, or negotiate offline
The seller does not accept the requested {"payment_terms"} value for this account. Payment terms are never silently remapped — sellers either accept or reject. Distinct from {"BILLING_NOT_SUPPORTED"} (the {"billing"} enum) by being narrowly about the {"payment_terms"} enum on the same account. Recovery: correctable (omit {"payment_terms"} to accept the seller's default, retry with a different value the seller supports, or negotiate offline).
**Suggested action:** call check\_governance to mint a valid token, or contact the seller to resolve the underlying permission; when error.details.scope is 'agent' with reason 'sandbox\_only' the rejection is terminal-pending-onboarding — surface to a human rather than auto-retrying. For suspended/blocked agent relationships, sellers emit AGENT\_SUSPENDED / AGENT\_BLOCKED instead (those codes carry recovery: terminal directly).
The authenticated caller is not authorized for the requested action, or a required signed credential (e.g., a {"governance_context"} token on a spend-commit) is missing, fails verification, or was issued for a different plan, seller, or phase. Seller content or advertising policy denials use {"POLICY_VIOLATION"}; media-buy change-right and current-availability denials use {"ACTION_NOT_ALLOWED"}. Distinct from {"AUTH_MISSING"} (no credentials presented), {"AUTH_INVALID"} (credentials presented but rejected), {"GOVERNANCE_DENIED"} (governance agent denied), {"AGENT_SUSPENDED"} (agent's relationship temporarily paused), and {"AGENT_BLOCKED"} (agent's relationship permanently denied). When the gate that fired is specifically a non-status per-agent provisioning constraint — e.g., the agent is provisioned for sandbox traffic only and the request was against a non-sandbox account — {"error.details"} SHOULD conform to {"error-details/agent-permission-denied.json"} ({"scope: \"agent\""} plus {"reason: \"sandbox_only\""}) so callers can dispatch without parsing prose. Sellers MUST emit {"scope: \"agent\""} only when buyer-agent identity has been established via signed-request derivation or a credential-to-agent mapping in the seller's onboarding record; in all other cases (including bearer credentials not mapped to a specific agent record) sellers MUST return {"PERMISSION_DENIED"} and MUST omit {"error.details.scope"} — emitting the per-agent scope without established identity is a cross-tenant onboarding oracle, and the omit MUST be enforced across every observable channel (response shape, HTTP/A2A/MCP status, headers, side effects, observability, latency parity) per the channel-coverage rules in error-handling.mdx Per-Agent Authorization Gate, mirroring the {"*_NOT_FOUND"} uniform-response rule and {"BILLING_NOT_PERMITTED_FOR_AGENT"}. The {"suspended"} and {"blocked"} per-agent states are NOT carried on this code — sellers MUST emit {"AGENT_SUSPENDED"} / {"AGENT_BLOCKED"} instead, each of which is its own discriminator. Recovery: correctable (call {"check_governance"} to mint a valid token, or contact the seller to resolve the underlying permission); when {"details.reason"} is present the rejection is terminal-pending-onboarding — the agent MUST surface to a human at the buyer rather than auto-retrying, since the agent cannot unilaterally extend its sandbox-only provisioning.
**Suggested action:** advisory — emitted alongside the v1 downgrade emission: SDK collapsed a pixel\_tracker asset to v1 {"{asset_type: url, url_type: tracker_pixel}"} for a seller that doesn't support pixel\_tracker natively. The URL still fires; what's lost is in {"error.details.lost_fields"} (event variant, method:js execution context, or custom event timing). Buyer decision: accept the loss (most counter pixels survive), or fail the buy and route to a 3.1-capable seller. Non-fatal — do not auto-retry
Non-fatal advisory raised when a 3.1 buyer SDK downgrades a {"pixel_tracker"} asset to the v1 {"{asset_type: url, url_type: tracker_pixel}"} shape for a 3.0.x seller that doesn't recognize the new asset type. The URL is still emitted on the wire and the seller will fire it as a tracker pixel; what's lost is the event/method discrimination.
Downgrade rules (normative):
* {"event: impression"} + {"method: img"} → no loss; emit as {"{asset_type: url, url_type: tracker_pixel, url, asset_id: impression_tracker}"}
* {"event: viewable_mrc_50"} / {"viewable_mrc_100"} / {"viewable_video_50"} / {"audible_video_complete"} → emit with {"asset_id: viewability_tracker"}; advisory {"lost_event: "} (specific viewability variant collapses to a single v1 slot)
* {"event: click"} → emit with {"asset_id: click_tracker"}; no meaningful loss
* {"event: custom, custom_event_name: X"} → emit with {"asset_id: impression_tracker"} (default tracker\_pixel fires on impression); advisory {"lost_event: \"custom\""}, {"lost_custom_event_name: X"} (custom event timing collapses to impression timing)
* {"method: js"} → emit unchanged shape (url, url\_type:tracker\_pixel); advisory {"lost_method: \"js\""} (v1 seller will fire as HTTP GET; the URL is hit and any counter-based measurement increments, but the response body won't execute as JS — measurement that depends on JS execution, e.g., OMID-style verification, viewability observers, cross-domain cookie setters, won't work. Simple counter pixels still work.)
Surface: SDK that performs the downgrade MUST augment the response's {"errors[]"} with {"source: \"sdk\""}, {"sdk_id"}, {"code: \"PIXEL_TRACKER_LOSSY_DOWNGRADE\""}, {"field"} pointing at the affected manifest asset path, and {"error.details"} SHOULD carry {"{ asset_id, original_event, original_method, original_custom_event_name (if present), downgrade_target: \"url+tracker_pixel\", lost_fields: [] }"}
. One advisory per downgraded asset; SDKs SHOULD NOT collapse multiple downgrades into a single advisory entry — per-asset details let the buyer's measurement-plan owner decide whether each loss is tolerable.
Recovery: warning — non-fatal, no retry. Buyer-side decision: accept the loss (most simple counter pixels survive), or fail the buy and route to a 3.1-capable seller. Seller-side fix: upgrade to 3.1 and accept {"pixel_tracker"} natively.
**Suggested action:** advisory — emitted when a 3.1 SDK upgrades a v1 url+tracker\_pixel asset to pixel\_tracker by inferring event and method from asset\_id conventions. The inference may not match the buyer's original intent; check {"error.details.inferred_event"} / {"inferred_method"} and re-prompt the seller for explicit values if precise measurement matters. Non-fatal — do not auto-retry
Non-fatal advisory raised when a 3.1 buyer SDK upgrades a v1 {"{asset_type: url, url_type: tracker_pixel}"} to a {"pixel_tracker"} asset by INFERRING the event and method from the v1 asset\_id and conventional defaults. The inference is structural — the SDK doesn't have explicit event/method values, only the v1 asset\_id hint and {"url_type: tracker_pixel"} (which implies {"method: img"} by default).
Inference rules (normative):
* {"asset_id: impression_tracker"} → {"event: impression, method: img"}
* {"asset_id: viewability_tracker"} → {"event: viewable_mrc_50, method: img"} (50% is the most common default; specific viewability variant cannot be recovered from v1 shape)
* {"asset_id: click_tracker"} → {"event: click, method: img"}
* {"asset_id: "} → {"event: custom, custom_event_name: , method: img"}
Surface: SDK MUST augment the response's {"errors[]"} with {"code: \"PIXEL_TRACKER_UPGRADE_INFERRED\""}, {"field"} pointing at the upgraded asset path, and {"error.details"} SHOULD carry {"{ asset_id, inferred_event, inferred_method, inference_basis: \"asset_id_convention\" \u007c \"default\" }"}. Buyer agents reading the response can re-prompt the seller for explicit values if precise measurement matters.
Recovery: warning — non-fatal, no retry. Seller-side: upgrade emit path to ship pixel\_tracker shape directly when 3.1-capable; until then, conventional asset\_id values give the SDK enough signal to upgrade without losing critical semantics.
**Suggested action:** resolve the pinned value against the current catalog, review any replacement, and submit an intentional package targeting update
A place identifier previously accepted and pinned on a package can no longer be executed. This is a nonfatal resource-state error returned in get\_media\_buys.errors\[] alongside the affected buy. error.field MUST point to the exact media\_buys\[N].packages\[M].targeting\_overlay.geo\_places\[\_exclude]\[A].values\[V] response path. error.details MUST include media\_buy\_id, package\_id, system, system\_version, country, place\_type, and value. The seller MUST preserve and echo the pinned target rather than silently changing geography. Recovery: correctable (look up the value through the declared resolver at the current catalog version and submit an intentional targeting update).
**Suggested action:** verify plan\_id via sync\_plans, or register the plan first
Referenced governance plan does not exist or is not accessible to the requesting agent. Recovery: correctable (verify plan\_id via sync\_plans, or register the plan first). Sellers MUST return this code uniformly for any plan\_id not accessible to the calling account — never distinguish 'exists but unauthorized' from 'does not exist', which would enable cross-tenant enumeration of governance plans.
**Suggested action:** review policy requirements in the error details
Request violates the seller's content or advertising policies. Recovery: correctable (review policy requirements in the error details).
**Suggested action:** seller-side fix needed: remove private operational fields ({"visibility"}, {"source"}, {"origin"}, {"delivery_mappings"}, or similar) from public placement objects. Consumers MUST fail closed for the affected placement and alert operators; do not echo private field values in logs or error details
Fatal producer-side error raised when a public placement object ({"Product.placements[]"} in {"get_products"} or {"placements[]"} in adagents.json) exposes seller-private operational fields such as {"visibility"}, {"source"}, {"origin"}, or {"delivery_mappings"}. This is a private-data leak, not an ordinary syntactic mismatch. Consumers that detect it MUST fail closed for that placement and surface this code so monitoring can alarm on the leak specifically instead of burying it under generic schema validation. {"error.field"} SHOULD point at the offending placement path and {"error.details"} SHOULD carry {"{ placement_id, leaked_fields: [] }"} without echoing private field values. Recovery: correctable but seller-side — remove private operational fields from the public placement surface and keep delivery mappings in seller-internal systems.
**Suggested action:** re-discover with get\_products to find current inventory
The seller still recognizes one or more configured product IDs as issued to the authenticated account and referenced discovery/refinement lineage, and they have passed their expires\_at timestamps. Sellers are not required to retain expiry tombstones indefinitely; an ID that is no longer resolvable, or is inaccessible to this caller because it belongs to another account or lineage, uses PRODUCT\_NOT\_FOUND. This distinction MUST NOT become a cross-tenant existence oracle. Recovery: correctable (re-discover through list\_products, request\_proposals, or the get\_products compatibility facade to find current inventory).
**Suggested action:** remove invalid IDs and retry, or re-discover with get\_products
One or more referenced product IDs are unknown or are not resolvable within the authenticated account and configured-offer lineage. A caller-authorized configured ID that is still recognized as expired uses PRODUCT\_EXPIRED; once no expiry tombstone remains, or whenever the ID belongs to another account or lineage, PRODUCT\_NOT\_FOUND applies. Sellers MUST NOT reveal cross-tenant product existence through error choice. Recovery: correctable (remove invalid IDs and retry, or re-discover with get\_products).
**Suggested action:** choose a different product
The requested product is sold out or no longer available. Recovery: correctable (choose a different product).
**Suggested action:** call request\_proposals and finalize a fresh proposal, or re-discover and finalize through legacy get\_products
A referenced proposal ID has passed its expires\_at timestamp. For a committed proposal, the inventory hold has lapsed. Recovery: correctable (call request\_proposals and finalize a fresh proposal, or re-discover and finalize through the legacy get\_products facade).
**Suggested action:** finalize the draft through refine\_proposals, or through the legacy get\_products refine action
The referenced proposal has proposal\_status 'draft' and cannot be accepted into a media buy. Recovery: correctable (finalize it through refine\_proposals, or through the legacy get\_products refine action).
**Suggested action:** request and finalize a fresh proposal, then retry
The referenced proposal\_id is not recognized by the seller — it belongs to a different tenant, was never issued, or was evicted from the seller's session cache before consumption. Distinct from {"PROPOSAL_EXPIRED"} (a known proposal whose {"expires_at"} window has passed) and {"PROPOSAL_NOT_COMMITTED"} (a known proposal still in {"draft"}). Recovery: correctable (request a fresh proposal, finalize it, then retry accept\_proposal; 3.x compatibility callers retry create\_media\_buy).
**Suggested action:** revise the provenance claim to match the verifier's observation or replace the creative; auto-retry without correction will not pass
Seller invoked a governance agent from {"creative_policy.accepted_verifiers"} via {"get_creative_features"} and the verifier's result contradicts the buyer's provenance claim - e.g., buyer claims {"digital_source_type: digital_capture"} but the AI-detection feature returns {"ai_generated: true"} above the seller's confidence threshold. Distinct from the {"PROVENANCE_*_MISSING"} family (structural absence) by being an active refutation. {"error.details"} SHOULD be limited to the audit-safe allowlist {"{ agent_url, feature_id, claimed_value, observed_value, confidence }"}; sellers MUST NOT forward arbitrary verifier extension fields, {"detail_url"}, or any verifier response shape that may carry cross-tenant or PII data. When the seller calls a different on-list agent than the buyer nominated (the seller is the verifier-of-record), {"error.details.agent_url"} is the agent the seller actually called and {"error.details.substituted_for"} SHOULD carry the buyer's nominated {"agent_url"} so the buyer can reconcile. Recovery: correctable - buyer revises the provenance claim to match reality (or replaces the creative); auto-retry without correction will not pass.
**Suggested action:** set provenance.digital\_source\_type to a value from the digital-source-type enum and resubmit
Seller's {"creative_policy.provenance_requirements.require_digital_source_type"} is true and the submitted creative's resolved provenance (after inheritance) has no {"digital_source_type"} value, or has it set to null. Distinct from {"PROVENANCE_REQUIRED"} (no provenance object at all) - provenance is present, just missing this specific field. Recovery: correctable (set {"provenance.digital_source_type"} to a value from the {"digital-source-type"} enum and resubmit). {"error.field"} MUST point at the resolved provenance path that was inspected (e.g., {"creatives[0].creative_manifest.provenance.digital_source_type"}).
**Suggested action:** set provenance.disclosure.required and, when true, populate disclosure.jurisdictions
Seller's {"creative_policy.provenance_requirements.require_disclosure_metadata"} is true and the submitted creative's resolved provenance has no {"disclosure.required"} boolean, or {"disclosure.required"} is true with no {"disclosure.jurisdictions"} entries. Recovery: correctable (set {"provenance.disclosure.required"} and, when true, populate {"disclosure.jurisdictions"}). {"error.field"} MUST point at {"provenance.disclosure"} (e.g., {"creatives[0].creative_manifest.provenance.disclosure"}).
**Suggested action:** attach at least one embedded\_provenance entry from a supported provider and resubmit
Seller's {"creative_policy.provenance_requirements.require_embedded_provenance"} is true and the submitted creative's resolved provenance has no {"embedded_provenance"} array, or has it as an empty array. Used in pipelines where sidecar {"c2pa.manifest_url"} is stripped by intermediaries and the seller requires content-stream-resilient provenance. Recovery: correctable (attach at least one {"embedded_provenance"} entry from a supported provider and resubmit, optionally with a {"verify_agent"} pointer matching one of the seller's {"creative_policy.accepted_verifiers"}). {"error.field"} MUST point at {"provenance.embedded_provenance"} on the resolved manifest.
**Suggested action:** attach a provenance object - at minimum digital\_source\_type - and resubmit
Seller's {"creative_policy.provenance_required"} is true and the submitted creative has no {"provenance"} object on the manifest, on the creative-asset, or on any individual asset. Distinct from {"CREATIVE_REJECTED"} (generic creative-review failure) by being narrowly about provenance presence. Recovery: correctable (attach a provenance object - at minimum {"digital_source_type"} - and resubmit). {"error.field"} MUST point at the path where provenance was expected (e.g., {"creatives[0].creative_manifest"}).
**Suggested action:** assess the creative, set provenance.synthetic\_depiction to true or false, and resubmit
Seller's {"creative_policy.provenance_requirements.require_synthetic_depiction"} is true and the submitted creative's resolved provenance (after inheritance) has no {"synthetic_depiction"} boolean. Both {"true"} and {"false"} satisfy the requirement; absence means unassessed. Distinct from {"PROVENANCE_REQUIRED"} (no provenance object at all) and from {"PROVENANCE_CLAIM_CONTRADICTED"} (an independent verifier actively refuted a declared value). Recovery: correctable (assess the creative, set {"provenance.synthetic_depiction"} to true or false, and resubmit). {"error.field"} MUST point at the resolved {"provenance.synthetic_depiction"} path. The declaration does not establish consent, legality, or verification.
**Suggested action:** replace verify\_agent.agent\_url with one from the seller's published accepted\_verifiers, drop verify\_agent if the embedding is self-verifiable, or re-embed with a verifier the seller accepts
Buyer attached a {"verify_agent.agent_url"} on {"embedded_provenance[]"} or {"watermarks[]"} that does not match (canonicalized per /docs/reference/url-canonicalization: lowercase scheme and host, strip default port, normalize path dot-segments) any entry in the seller's {"creative_policy.accepted_verifiers[].agent_url"}. The seller does not call buyer-asserted endpoints outside its allowlist; this is the cross-check that closes the buyer-controlled-URL trust gap. {"error.field"} MUST point at the offending {"verify_agent.agent_url"} path; {"error.details"} SHOULD include a reference to the product whose {"creative_policy.accepted_verifiers"} the buyer should consult (the buyer already has this from {"get_products"}). Recovery: correctable (replace {"verify_agent.agent_url"} with one from the seller's published {"accepted_verifiers"}, drop the {"verify_agent"} entirely if the embedding is self-verifiable, or re-embed evidence using a verifier the seller accepts).
**Suggested action:** wait top-level error.retry\_after seconds when present, then retry
Request rate exceeded. Sellers SHOULD populate top-level {"error.retry_after"} with the integer number of seconds to wait. Recovery: transient (wait {"error.retry_after"} seconds when present, then retry).
**Suggested action:** use a non-mutating alternative, or surface to the operator to request a scope that permits mutation
The caller's scope is read-only; the invoked task would mutate state and was rejected. Distinct from {"SCOPE_INSUFFICIENT"} (task not in scope at all) — the task is in some scopes this seller supports, just not this caller's. Recovery: correctable but not agent-autonomous — use a non-mutating alternative, or surface to the operator to request a scope that permits mutation.
**Suggested action:** verify the referenced identifier exists and is accessible to the caller
Generic fallback for a referenced identifier, grant, session, or other resource that does not exist or is not accessible by the caller. Use when no resource-specific not-found code applies (e.g., property lists, content standards, rights grants, SI offerings, proposals, catalogs, event sources, collection lists, brands, individual properties). Typed parameters that lack a dedicated standard code MUST also use REFERENCE\_NOT\_FOUND rather than minting a custom \*\_NOT\_FOUND code. See 'Uniform response for inaccessible references' in error-handling.mdx for the full MUST list. Recovery: correctable. Summary of the uniform-response MUST: sellers MUST return the same response for 'exists but the caller lacks access' as for 'does not exist' across every observable channel — error.code/message/field/details (message MUST be generic; error.field MUST be identical across both cases on typed parameters); HTTP status, A2A task.status.state, and MCP isError; response headers (ETag, Cache-Control, per-type rate-limit buckets, CDN tags); side effects (webhook/audit writes, background-job enqueues, per-type quota counters, DB-shard routing); and observability (logs, APM spans, third-party error telemetry like Sentry/Datadog). Sellers MUST perform the same resolution-and-authorization work on both paths (resolve-then-authorize; on true-miss still run an authorization decision of equivalent shape against an empty principal set so authorizer latency is not a side channel). Cache population MUST NOT be gated on authorization. Polymorphism is evaluated against the tool-schema's declared parameter shape before any lookup, and a tool's declared shape MUST be identical across all callers.
**Suggested action:** refine accepted\_proposal\_id into an amendment and apply it through accept\_proposal, or keep control\_media\_buy inside the accepted envelope; 3.1 compatibility callers must adjust or rediscover
A control\_media\_buy request, or the 3.x update\_media\_buy facade, would exceed the accepted commercial envelope. The seller is declining the requested shape at the current terms. Distinct from TERMS\_REJECTED (measurement) and POLICY\_VIOLATION (content). Sellers SHOULD populate error.details.envelope\_field with the field path(s) that breached the envelope. AdCP 3.2 callers refine the MediaBuy's accepted\_proposal\_id to obtain a typed amendment; legacy 3.1 callers adjust the update, rediscover terms, or create a separate buy.
**Suggested action:** the agent cannot broaden its own scope - surface to the operator rather than auto-retry
The authenticated caller is not authorized for the invoked task — the task is not in the caller's {"allowed_tasks"} for this account (discoverable via the {"authorization"} object on sync\_accounts / list\_accounts responses). Distinct from {"PERMISSION_DENIED"} (generic authz failure, often credential-shaped) by being narrowly about task-level scope. Sellers SHOULD populate {"error.details.introspection_hint"} pointing at where the caller can re-read its scope (strawman: {"{ task: 'list_accounts', account: {...} }"}). Recovery: correctable in the sense that the request can be re-sent after the scope is broadened, but the agent cannot broaden its own scope — this requires operator intervention, and agents SHOULD surface rather than auto-retry.
**Suggested action:** retry with exponential backoff
Seller service is temporarily unavailable. Retry with exponential backoff. Recovery: transient.
**Suggested action:** initiate a new session via si\_initiate\_session
SI session ID is invalid, expired, or does not exist. Recovery: correctable (initiate a new session via si\_initiate\_session).
**Suggested action:** initiate a new session via si\_initiate\_session
SI session has already been terminated and cannot accept further messages. Recovery: correctable (initiate a new session via si\_initiate\_session).
**Suggested action:** verify signal\_id via get\_signals, or confirm the signal is available from this agent
Referenced signal does not exist in the agent's catalog. Recovery: correctable (verify signal\_ref via get\_signals, or confirm the signal is available from this agent). Sellers MUST return this code uniformly for any signal\_ref not accessible to the calling account — never distinguish 'exists but unauthorized' from 'does not exist', which would enable cross-tenant enumeration.
**Suggested action:** assign the creative to a package whose signal targeting matches the creative's signal\_condition, or rebuild the creative for the package's condition; match on shared signal\_ref identity (compare signal\_agent\_segment\_id exactly when both carry it, else categorical signal\_ref + value)
A creative carrying a signal\_condition (from build\_creative signal\_conditions fan-out, #5240) was assigned to a package whose signal targeting is incompatible — e.g. a sun creative routed to a rain-targeted package. The trafficking-compatibility invariant: a creative built FOR one signal condition MUST NOT serve into a package targeting an incompatible condition. Enforced reject-at-trafficking on the sales side (create\_media\_buy / sync\_creatives), NOT at build\_creative (per #5280, signal pointers are advisory at the build layer; enforcement lives at the trafficking boundary). Compatibility is matched on shared signal\_ref identity: when both sides carry signal\_agent\_segment\_id, compare the opaque handle exactly; when both carry only categorical \{signal\_id,value}, compare signal\_ref + value-set semantics; equal categorical labels from DIFFERENT providers are NOT compatible absent an explicit equivalence mechanism; when one side has a segment handle and the other only a categorical value, the seller MAY accept only if it can resolve both to the same provider-issued segment, else reject/warn. For value\_type:numeric the comparison is range-overlap (WG-open: range-overlap vs exact-match — see RFC #5240 open decisions). error.field SHOULD point at the offending assignment path (e.g. packages\[N].creative\_assignments\[M] or creatives\[N]); error.details SHOULD carry the creative's signal\_condition and the package's incompatible signal targeting so the buyer can re-route. Distinct from SIGNAL\_NOT\_FOUND (signal unknown/inaccessible) by being a compatibility mismatch between a known creative condition and a known package condition. Recovery: correctable (assign the creative to a package whose signal targeting matches its signal\_condition, or rebuild for the package's condition).
**Suggested action:** re-invoke the designated task (verify\_brand\_claim or verify\_brand\_claims) to obtain a freshly signed response with a current exp window
The {"signed_response.payload.exp"} timestamp is at or past the current time after applying the verifier's clock-skew tolerance. The signed envelope was valid when issued but the verification window has closed. Raised by verifiers consuming a designated-task signed response ({"verify_brand_claim"} / {"verify_brand_claims"}) during step 7 of the [response-signing verifier checklist](/docs/building/by-layer/L1/security#verifier-checklist-responses). Online verifiers MUST reject expired envelopes; audit verifiers MAY verify after {"exp"} as historical evidence that the brand-agent signed the payload during the stated {"iat"}/{"exp"} window, but MUST NOT treat the result as current truth. Distinct from {"STALE_RESPONSE"} (cache-staleness advisory on a populated success payload) by being a cryptographic freshness failure on a signed response envelope. Recovery: transient (re-invoke the designated task to obtain a freshly signed response with a current {"exp"} window).
**Suggested action:** re-invoke the designated task with the intended request parameters — the signed response's request\_hash does not match the verifier's recomputed hash of the actual request; if the mismatch persists across retries, investigate JCS request-binding canonicalization between caller and responder
The {"signed_response.payload.request_hash"} does not match the verifier's recomputed SHA-256 hash of the canonical request-binding object {"{ task, brand_domain, agent_url, caller_identity, request }"} for the actual request sent. Raised during step 8 of the [response-signing verifier checklist](/docs/building/by-layer/L1/security#verifier-checklist-responses). This indicates either a replay of a signed response from a different request, a JCS request-binding canonicalization divergence between signer and verifier, or payload tampering. Verifiers MUST reject the envelope when the recomputed hash does not byte-match the signed {"request_hash"}. {"error.details"} SHOULD carry {"expected_request_hash"} (the verifier's recomputed value) when safe to disclose — the hash binds the response to the exact request that produced it, and divergence is the signal that the binding has been broken. Recovery: correctable (re-invoke the designated task with the intended request parameters; if the mismatch persists across retries, investigate JCS request-binding canonicalization between the caller and the responding agent).
**Suggested action:** verify the request targeted the correct brand domain and agent\_url, then re-invoke; if the mismatch persists, the responding agent's server-side tenant resolution may be misconfigured
The {"signed_response.payload.brand_domain"} does not match the verifier's resolved or expected brand tenant for this verification call. Raised during step 9 of the [response-signing verifier checklist](/docs/building/by-layer/L1/security#verifier-checklist-responses). The responding brand agent derives {"brand_domain"} from server-side tenant resolution, not from caller-supplied request fields (per the response-signing profile in security.mdx), so a mismatch indicates cross-tenant replay, a multi-brand agent routing error, or a mismatch between the verifier's tenant resolution and the responder's. Distinct from {"SIGNED_RESPONSE_REQUEST_HASH_MISMATCH"} (request-binding divergence) by being narrowly about the tenant identity — {"brand_domain"} is a field inside the signed payload that the responder derives independently, not an echo of any caller-supplied value. Recovery: correctable (verify that the request targeted the correct brand domain and agent; re-invoke with the correct brand reference if the request was mis-routed; if the mismatch persists, the responding agent's server-side tenant resolution may be misconfigured).
**Suggested action:** error.field source.locator/source.segment\_ref: fix the reference; error.field source: grant the seller's declared consumer identity and retry; no error.field: vendor outage, retry with backoff
Seller could not read an external audience source on sync\_audiences (experimental, media\_buy.audience\_activation). Per-audience: surfaces as action: failed with this code in the audience's errors array. The seller cannot reliably distinguish a revoked grant from an expired one from a transient vendor outage — all three observables are a failed read — so error.field distinguishes what the buyer can act on: 'source.locator' or 'source.segment\_ref' means the reference does not resolve (changed request needed); 'source' means access denied (establish or re-grant access to the seller's declared consumer identity, then retry); absence of error.field indicates a vendor-side failure (retry with backoff, no buyer action). On an already-ready audience a failed re-read MUST NOT change audience status — membership stays frozen at the last successful read and source.access\_status reports 'unavailable'. Recovery: correctable (fix the reference or grant per error.field; vendor outages without error.field are transient and retry with backoff).
**Suggested action:** advisory — emitted alongside a populated payload that was served from cache past the seller's freshness target because an upstream or sub-agent was unreachable. The response is usable; treat as non-fatal. Inspect {"error.details.cache_age_seconds"} to decide whether to immediately retry for fresh data or accept the cached value; the seller's own service is healthy, so retry is safe (it does not amplify the upstream failure)
Non-fatal advisory raised when the seller's live fetch to an upstream or sub-agent failed (timeout, connection error, downstream 5xx) and the response payload was satisfied from a cached prior result that is past the seller's freshness target for this surface. Emitted **alongside** a populated success payload — the caller's request still completes from a usable cache hit; this code tells downstream consumers that the data is older than the seller would normally serve.
Distinct from {"SERVICE_UNAVAILABLE"} (seller's own service is down, no payload — transient, retry-with-backoff) by signalling **graceful degradation**: the seller's own service is fine, but one of its dependencies is currently unreachable and the seller chose to honor the request from cache rather than return empty. Sellers MUST emit {"STALE_RESPONSE"} ONLY when the response payload is non-empty AND derived from a cache entry whose {"cache_age_seconds"} exceeds the surface's freshness target. When no cached entry exists (or the cache hit is within freshness target), sellers MUST NOT emit this code — return the empty-or-fresh response with whatever upstream-failure code applies (e.g., {"SERVICE_UNAVAILABLE"}).
**Wire placement (normative).** Transport-level success markers stay flipped to success (HTTP 200, MCP {"isError: false"}, A2A {"succeeded"}) — the task ran successfully and produced a response, even if from cache. The advisory rides in {"errors[]"} on the payload and MUST NOT be promoted to {"adcp_error"} on the envelope (envelope-level errors are reserved for the empty-payload failure case per the two-layer model in {"error-handling.mdx#envelope-vs-payload-errors-the-two-layer-model"}). {"error.field"} SHOULD point at the affected payload path (e.g., {"formats"} for {"list_creative_formats"}, {"products"} for {"get_products"}). {"error.details"} SHOULD conform to {"error-details/stale-response.json"} — {"served_from_cache"} (required, always {"true"}), {"cache_age_seconds"} (required), and optionally {"freshness_target_seconds"}, {"upstream"} (the dependency that failed), and {"original_error"} (the underlying failure code/message).
**Multiple stale upstreams.** When N sub-agents are stale (e.g., a {"list_creative_formats"} registry aggregating from multiple creative agents), the seller SHOULD emit **one {"STALE_RESPONSE"} entry per affected upstream** rather than aggregating — the per-upstream shape mirrors the existing precedent set by {"PIXEL_TRACKER_LOSSY_DOWNGRADE"} (one advisory per downgraded asset) and lets buyer agents reason about which sub-population of the payload is stale. Each entry's {"error.field"} SHOULD narrow to the affected slice (e.g., {"formats"} for formats sourced from the stale upstream).
Recovery: transient — buyers MUST treat as non-fatal (the response is usable), MAY immediately retry later for fresh data, and SHOULD surface staleness to operators or end users when relevant. {"cache_age_seconds"} is the informational knob for the buyer's own "is this stale enough to bother retrying" policy.
**Suggested action:** adjust the proposed terms and retry, or omit measurement\_terms to accept the product's defaults
Buyer-proposed measurement\_terms were rejected by the seller. The error details SHOULD identify which specific term was rejected and the seller's acceptable range or supported vendors. Recovery: correctable (adjust the proposed terms and retry, or omit measurement\_terms to accept the product's defaults).
**Suggested action:** target an output format the transformer prices, or have the seller add a pricing option covering it
A creative transformer build targets an output capability that no pricing option covers — no transformer.pricing\_options entry has a matching applies\_to\_output\_capability\_ids and none is unscoped. The build is rejected rather than billed at a guessed rate. Recovery: correctable.
**Suggested action:** check get\_adcp\_capabilities and remove unsupported fields
A requested feature or field is not supported by this seller. When rejecting a {"refine_proposals"} request that uses a typed dimension omitted from an explicit {"proposal_refinement.supported_dimensions"} declaration, the error details SHOULD follow {"error-details/unsupported-refinement-dimension.json"} — {"unsupported_dimension"} names the offending dimension and {"supported_dimensions"} echoes the seller's declaration so the buyer can remove or translate the field without another capability round trip. Recovery: correctable (check get\_adcp\_capabilities and remove unsupported fields).
**Suggested action:** pick a granularity from the product's reporting\_capabilities.windowed\_pull\_granularities (via get\_adcp\_capabilities) and resubmit, or omit time\_granularity to fall back to cumulative date-range pulls
The requested {"time_granularity"} on {"get_media_buy_delivery"} is not in the product's declared {"reporting_capabilities.windowed_pull_granularities"}. Distinct from {"UNSUPPORTED_FEATURE"} (generic capability mismatch) by being narrowly about reporting-window granularity — the buyer asked for hourly pull-recovery on a product that only honors daily pulls, for example. Sellers MAY echo the declared set in {"error.details.supported_granularities"} when the caller is authorized to read the product's reporting capabilities — the same set is already available via {"get_adcp_capabilities"}, so the echo is a convenience, not load-bearing. Sellers MUST NOT echo a granularity set the caller could not otherwise read (per-product capability views vary by buyer entitlement). The {"error.field"} SHOULD point at {"time_granularity"}. Buyers that need higher-frequency recovery than the seller's pull set supports MUST rely on the webhook channel as primary at that frequency — the seller's {"available_reporting_frequencies"} may legitimately exceed {"windowed_pull_granularities"} (e.g., a stream-tap webhook on Kafka with warehouse pulls only at daily). Recovery: correctable (re-issue at a granularity in the declared set, or omit {"time_granularity"} to fall back to cumulative date-range pulls).
**Suggested action:** re-issue with the entry shape the seller supports — {"account: {account_id: ...}"} for settings-update sellers with account-id namespaces, or {"brand+operator+billing"} for provisioning sellers; check seller documentation or capability declaration for which modes are implemented
The seller does not support the {"sync_accounts"} mode the entry requested. Returned per-entry in the {"sync_accounts"} response when (a) an entry keyed by the natural-key trio ({"brand"} + {"operator"} + {"billing"}) is sent to a seller that does not provision accounts via AdCP — typical for account-id namespaces where accounts are pre-provisioned out of band or discovered via {"list_accounts"}; or (b) an entry keyed by {"account"} (AccountRef) is sent to a seller that has not implemented the settings-update mode. Distinct from {"UNSUPPORTED_FEATURE"} (generic capability mismatch) by being narrowly about which of the two {"sync_accounts"} modes the seller implements. The two modes are mutually exclusive per-entry — the seller MUST NOT silently downgrade or upgrade between them. Sellers MAY declare which modes they implement via {"get_adcp_capabilities"} (forward-looking — capability declaration shape is open). Recovery: correctable (re-issue with the entry shape the seller supports; for account-id namespaces that expose settings updates, that means {"account: {account_id: ...}"} entries; for sellers that only provision via natural key that means the flat {"brand+operator+billing"} shape). The {"error.field"} SHOULD point at the entry index where the unsupported shape was found.
**Suggested action:** review error details and fix field values
Request contains invalid field values or violates business rules beyond schema validation. Recovery: correctable (review error details and fix field values).
**Suggested action:** inspect error.details.reason (not\_xml, no\_vast\_root, no\_ad, no\_media\_file), fix the VAST document, and resubmit
A submitted {"vast"} asset failed document-level validation: the inline {"content"} (or the document fetched from {"url"}) is not well-formed XML, has no {""} root element, contains no {""} element, or an {""} linear creative carries no {""}. Returned by sellers that declare {"creative_specs.vast_validation"} of {"document"} or {"wrapper"}; sellers at the default {"structural"} level do not inspect the VAST document and MUST NOT return this code. Distinct from {"VALIDATION_ERROR"} (manifest-level format validation): the manifest was structurally valid, the VAST document inside it was not. Sellers SHOULD set {"error.field"} to the offending asset path and SHOULD populate {"error.details.reason"} with one of {"not_xml"}, {"no_vast_root"}, {"no_ad"}, {"no_media_file"}. Unresolved ad-server macros in URLs ({"[MACRO]"}, {"${MACRO}"}, {"{UNIVERSAL_MACRO}"}) are opaque tokens, not parse failures. Recovery: correctable (fix the VAST document and resubmit).
**Suggested action:** inspect error.details.mismatch\_reason and the corresponding acceptance-set or observed-document fields; select a compatible source representation or correct the offending VAST document
A submitted {"vast"} asset is version-incompatible when its exact {"vast_version"} is absent from the intersection of the selected product format option's {"params.vast_versions"} and the seller's {"execution.creative_specs.vast_versions"}, or when an inspected document violates its applicable VAST version rule. Modern {"error.details"} MUST conform to {"error-details/vast-version-mismatch.json"}: acceptance failures carry {"mismatch_reason: asset_outside_acceptance"}, {"asset_vast_version"}, {"product_vast_versions"}, and {"seller_vast_versions"}, plus {"format_option_ref"} only when the selected option is addressable; inspected-document failures carry {"mismatch_reason: document_version_mismatch"}, {"asset_vast_version"}, {"observed_document_vast_version"}, and {"document_role"}. Only the submitted document is compared for equality with the asset declaration; wrapper and terminal documents are checked against the acceptance intersection. The deprecated {"supported_versions"} field remains accepted for older 3.x peers. Distinct from {"VERSION_UNSUPPORTED"}, which concerns AdCP protocol negotiation. Recovery: correctable (select a source VAST representation in the compatibility intersection or correct the offending document; never relabel the asset).
**Suggested action:** inspect error.details.reason (depth, loop, timeout); flatten the wrapper chain, reduce redirects below the format's max\_wrapper\_depth, or fix the failing hop
Resolving a {"vast"} asset's wrapper chain failed: the chain exceeded the format's declared {"max_wrapper_depth"}, revisited a {"VASTAdTagURI"} already seen in the chain (a loop), or a hop did not resolve within the seller's per-hop timeout. Returned by sellers that declare {"creative_specs.vast_validation: \"wrapper\""}. Sellers SHOULD set {"error.field"} to the offending asset path and SHOULD populate {"error.details.reason"} with one of {"depth"}, {"loop"}, {"timeout"}, plus {"error.details.depth"} with the depth reached. Recovery: correctable (flatten the chain, reduce redirects below the format's {"max_wrapper_depth"}, or fix the failing hop).
**Suggested action:** re-pin to a release in supported\_versions and retry, or call get\_adcp\_capabilities without a version pin to discover supported\_versions
The declared adcp\_version (release-precision) or adcp\_major\_version (deprecated) is not supported by this seller. The error details SHOULD follow {"error-details/version-unsupported.json"} — {"supported_versions"} (release-precision strings) is authoritative for retry; {"supported_majors"} is deprecated. Recovery: correctable (re-pin to a release in supported\_versions and retry; or call get\_adcp\_capabilities without a version pin to discover supported\_versions).
## 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](/dist/docs/3.2.0-beta.10/building/verification/validate-your-agent#storyboard-taxonomy) storyboard.
`supported_protocols` uses snake\_case; compliance paths and specialism IDs use kebab-case. See [Naming conventions](#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 |
| `measurement` | Preview / no stable baseline | Experimental 3.1 metric-catalog discovery. Agents implementing it must list `measurement.core` in `experimental_features`. |
Support for the [compliance test controller](/dist/docs/3.2.0-beta.10/building/by-layer/L3/comply-test-controller) is declared via the `capabilities.compliance_testing` block on [`get_adcp_capabilities`](/dist/docs/3.2.0-beta.10/protocol/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: , 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](https://github.com/adcontextprotocol/adcp/issues/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-dooh` | stable | Digital out-of-home, non-guaranteed venue and screen inventory |
| `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`](/dist/docs/3.2.0-beta.10/governance/campaign/tasks/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`](/dist/docs/3.2.0-beta.10/media-buy/task-reference/sync_audiences), [`list_accounts`](/dist/docs/3.2.0-beta.10/accounts/tasks/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 through [`get_signals`](/dist/docs/3.2.0-beta.10/signals/tasks/get_signals); activation is not required for this claim |
| `signal-marketplace` | stable | Marketplace signal agent reselling third-party data; requires `get_signals` and [`activate_signal`](/dist/docs/3.2.0-beta.10/signals/tasks/activate_signal) |
### 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 |
**Experimental in 3.1.** Measurement metric-catalog discovery is available through the experimental `measurement` capability block and `measurement.core` experimental feature. A stable `measurement-verification` specialism and baseline storyboard are deferred until the measurement task surface is frozen.
### 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`](/dist/docs/3.2.0-beta.10/protocol/get_adcp_capabilities). See [#3823](https://github.com/adcontextprotocol/adcp/issues/3823).
Four 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` |
| Non-guaranteed digital out-of-home venue and screen inventory | `sales-dooh` |
| Guaranteed-only digital out-of-home inventory | `sales-guaranteed` |
| Social platform with platform-managed creative | `sales-social` |
`sales-dooh` is the non-guaranteed DOOH profile. Guaranteed-only DOOH sellers still route `dooh` briefs through their portfolio declaration, but claim `sales-guaranteed` until a dedicated guaranteed DOOH profile exists.
| 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` |
`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. It is a conformance declaration, not the buyer's per-proposal routing signal: buyers decide whether a returned proposal can be bought from `proposal_status`.
| If you… | Set |
| ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| Accept RFPs, generate proposals, and finalize draft proposals to committed status before create | `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`) |
```jsonc theme={null}
// Full-service guaranteed seller — proposal lifecycle graded
{
"supported_protocols": ["media_buy"],
"specialisms": ["sales-guaranteed"],
"media_buy": {
"supports_proposals": true
}
}
```
```jsonc theme={null}
// 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 through [`get_signals`](/dist/docs/3.2.0-beta.10/signals/tasks/get_signals); activation is not required for this claim |
| `signal-marketplace` | stable | Marketplace signal agent reselling third-party data; requires `get_signals` and [`activate_signal`](/dist/docs/3.2.0-beta.10/signals/tasks/activate_signal) |
### 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 |
**Experimental in 3.1.** Measurement metric-catalog discovery is available through the experimental `measurement` capability block and `measurement.core` experimental feature. A stable `measurement-verification` specialism and baseline storyboard are deferred until the measurement task surface is frozen.
### 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`](/compliance/latest/protocols/media-buy/scenarios/dependency_impairment.yaml) 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](/dist/docs/3.2.0-beta.10/media-buy/media-buys/lifecycle#compliance) for the full `impairment.coherence` contract.
## How to claim
Declare your protocols and specialisms in [`get_adcp_capabilities`](/dist/docs/3.2.0-beta.10/protocol/get_adcp_capabilities):
```json theme={null}
{
"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](/dist/docs/3.2.0-beta.10/building/verification/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](/dist/docs/3.2.0-beta.10/building/verification/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`](/dist/docs/3.2.0-beta.10/protocol/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`](/compliance/latest/specialisms/sales-broadcast-tv/index.yaml) | — |
| `sales-dooh` | `channels: ['dooh']` | [`sales_dooh`](/compliance/latest/specialisms/sales-dooh/index.yaml) | — |
| `sales-social` | `channels: ['social']` | [`sales_social`](/compliance/latest/specialisms/sales-social/index.yaml) | — |
| `audience-sync` | [`sync_audiences`](/dist/docs/3.2.0-beta.10/media-buy/task-reference/sync_audiences) tool | [`audience_sync`](/compliance/latest/specialisms/audience-sync/index.yaml) | — |
| `property-lists` | `property_list` tools | [`property_lists`](/compliance/latest/specialisms/property-lists/index.yaml) | — |
| `collection-lists` | `collection_list` tools | [`collection_lists`](/compliance/latest/specialisms/collection-lists/index.yaml) | — |
| `governance-spend-authority` | [`check_governance`](/dist/docs/3.2.0-beta.10/governance/campaign/tasks/check_governance), [`sync_plans`](/dist/docs/3.2.0-beta.10/governance/campaign/tasks/sync_plans) | [`governance_spend_authority`](/compliance/latest/specialisms/governance-spend-authority/index.yaml) | [`governance_spend_authority/denied`](/compliance/latest/specialisms/governance-spend-authority/denied.yaml) |
| `creative-generative` | [`build_creative`](/dist/docs/3.2.0-beta.10/creative/task-reference/build_creative) | [`creative_generative`](/compliance/latest/specialisms/creative-generative/index.yaml) | [`creative_generative/seller`](/compliance/latest/specialisms/creative-generative/generative-seller.yaml) |
| `brand-rights` | [`get_brand_identity`](/dist/docs/3.2.0-beta.10/brand-protocol/tasks/get_brand_identity), [`acquire_rights`](/dist/docs/3.2.0-beta.10/brand-protocol/tasks/acquire_rights) | [`brand_rights`](/compliance/latest/specialisms/brand-rights/index.yaml) | [`brand_rights/governance_denied`](/compliance/latest/specialisms/brand-rights/scenarios/governance_denied.yaml) |
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`](/dist/docs/3.2.0-beta.10/governance/property/tasks/property_lists#create_property_list), [`validate_property_delivery`](/dist/docs/3.2.0-beta.10/governance/property/tasks/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](/dist/docs/3.2.0-beta.10/building/verification/validate-with-mock-fixtures)** for the complementary pre-staging gate.