> ## 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.

# AdCP 3.0

> What's new in AdCP 3.0: brand identity and rights, governance, sponsored intelligence, shows and episodes, 20 media channels, and migration guides from v2.

AdCP 3.0 expands the protocol beyond media buying into brand identity, governance, media planning, and conversational brand experiences.

## At a glance

| Area                       | v2.x                                | v3.x                                                                                                     |
| -------------------------- | ----------------------------------- | -------------------------------------------------------------------------------------------------------- |
| **Protocol scope**         | Media Buy, Signals, Creative        | Adds Brand Protocol, Governance, Sponsored Intelligence                                                  |
| **Brand identity**         | No standard mechanism               | `brand.json` + community brand registry                                                                  |
| **Governance**             | No brand suitability protocol       | Property lists, content standards, and brand calibration                                                 |
| **Sponsored Intelligence** | No conversational brand protocol    | Consent-first brand sessions in AI assistants                                                            |
| **Accounts Protocol**      | No formal account model             | Named protocol layer: `sync_accounts`, `list_accounts`, `report_usage`, brand registry-grounded identity |
| **Catalogs**               | `promoted_offerings` creative asset | First-class `sync_catalogs` task with 13 catalog types                                                   |
| **Media planning**         | Products only                       | Proposals with budget allocations + delivery forecasts                                                   |
| **Brand rights**           | No licensing protocol               | `get_rights`, `acquire_rights`, `update_rights` with HMAC-authenticated webhooks                         |
| **Visual guidelines**      | No structured brand visuals         | `visual_guidelines` on `brand.json` for generative creative systems                                      |
| **Creative governance**    | No creative evaluation protocol     | `get_creative_features` for security scanning, quality, content categorization                           |
| **Shows and episodes**     | No content programming model        | `shows` on products with distribution IDs, episode lifecycle, break-based inventory                      |
| **Channel model**          | 9 channels                          | 20 planning-oriented channels (including `sponsored_intelligence`)                                       |
| **Capability discovery**   | Agent card extensions               | Runtime `get_adcp_capabilities` task                                                                     |
| **Creative assignment**    | Simple ID arrays                    | Weighted assignments with placement targeting                                                            |
| **Geo targeting**          | Implicit US-centric                 | Explicit named systems (global)                                                                          |
| **Keyword targeting**      | No keyword support                  | `keyword_targets` with match types and bid prices                                                        |
| **Optimization**           | Single optimization goal            | Multi-goal `optimization_goals` array with metric and event types                                        |
| **Delivery reporting**     | Aggregate delivery only             | Opt-in dimension breakdowns (geo, device, audience, placement, keyword)                                  |
| **Signal pricing**         | Simple CPM                          | Structured pricing models (CPM, percent of media, flat fee)                                              |
| **Device targeting**       | No form-factor targeting            | `device_type` (desktop, mobile, tablet, ctv, dooh, unknown) distinct from `device_platform` (OS)         |
| **Proximity targeting**    | No point-based geo targeting        | `geo_proximity` with travel time, radius, and GeoJSON methods                                            |
| **Refinement**             | Free-text with `proposal_id`        | Typed change-request array with seller acknowledgment                                                    |
| **Error handling**         | Unstructured errors                 | `recovery` field (transient, correctable, terminal) + 18 standard error codes                            |
| **AI provenance**          | No provenance model                 | `provenance` object with IPTC source types, C2PA references, regulatory disclosures                      |
| **Creative compliance**    | No compliance on briefs             | `required_disclosures`, `prohibited_claims`, disclosure positions                                        |
| **Agent ergonomics**       | Full payloads on every call         | `fields` projection, opt-in breakdowns, pre-flight capability filtering                                  |
| **Signal lifecycle**       | Activate only                       | `activate` / `deactivate` action on `activate_signal`                                                    |

***

## New capabilities

### Brand Protocol

Buy-side identity through `/.well-known/brand.json`. Just as publishers use `adagents.json` to declare properties and authorized agents, brands use `brand.json` to declare their identity, brand hierarchy, and authorized operators.

| Sell side       | Buy side                         |
| --------------- | -------------------------------- |
| Publisher       | **House** (corporate entity)     |
| Property        | **Brand** (advertising identity) |
| `adagents.json` | **`brand.json`**                 |

Four variants: **House Portfolio** (full brand hierarchy inline), **Brand Agent** (dynamic via MCP), **House Redirect** (sub-brand to house domain), and **Authoritative Location** (hosted URL).

Given any domain, the protocol resolves to a canonical brand:

```
shoes.novabrands.example.com
  -> fetch /.well-known/brand.json
  -> { "house": "novabrands.example.com" }
  -> fetch novabrands.example.com/.well-known/brand.json
  -> search brands[] for property matching "shoes.novabrands.example.com"
  -> Result: { house: "novabrands.example.com", brand_id: "nova_athletics" }
```

**Use cases:** creative generation (resolve domain to brand identity), brand verification (check `authorized_operators`), reporting roll-up (group campaigns by house).

<Card title="Brand Protocol" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/brand-protocol">
  Full specification including brand.json variants, resolution flow, and brand identity.
</Card>

***

### Brand rights lifecycle

Three tasks for licensing and usage rights between brands and content owners:

| Task             | Purpose                                         |
| ---------------- | ----------------------------------------------- |
| `get_rights`     | Discover available rights for a brand's content |
| `acquire_rights` | Request and negotiate rights acquisition        |
| `update_rights`  | Modify active rights (extend, restrict, revoke) |

Rights include generation credentials (API keys or tokens for accessing licensed content), creative approval webhooks (HMAC-SHA256 authenticated callbacks when creatives are submitted for review), and revocation notifications. The protocol distinguishes actionable rejections (fix and resubmit) from final rejections (do not retry).

Structured `visual_guidelines` on `brand.json` complement rights by giving generative creative systems structured rules for on-brand asset production: photography style, graphic elements, composition, motion, logo placement, colorways, type scale, and restrictions.

<Card title="Brand rights" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/brand-protocol/tasks/get_rights">
  Task reference for rights discovery, acquisition, and management.
</Card>

***

### Shows and episodes

Products can now reference persistent content programs — podcasts, TV series, YouTube channels — via `show_ids`. `get_products` responses include a top-level `shows` array with distribution identifiers for cross-seller matching, episode lifecycle states (scheduled, tentative, live, postponed, cancelled, aired, published), break-based ad inventory configuration, talent linking to `brand.json`, and international content rating systems.

Shows support relationships (spinoff, companion, sequel, prequel, crossover) and derivative content (clips, highlights, recaps) for comprehensive content modeling.

<Card title="Shows and episodes" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/media-buy/product-discovery/shows-and-episodes">
  Full specification including show schemas, episode lifecycle, and break-based inventory.
</Card>

***

### Registry API

The AgenticAdvertising.org registry provides a public REST API for resolving brands and properties, discovering agents, and validating authorization. Most endpoints require no authentication.

| Capability          | Endpoint                                        | Description                                      |
| ------------------- | ----------------------------------------------- | ------------------------------------------------ |
| Brand resolution    | `/api/brands/resolve`                           | Resolve domain to canonical brand                |
| Property resolution | `/api/properties/resolve`                       | Resolve publisher domain to property info        |
| Agent discovery     | `/api/registry/agents`                          | List registered agents with capabilities         |
| Authorization check | `/api/registry/validate/property-authorization` | Real-time authorization validation               |
| Search              | `/api/search`                                   | Search across brands, publishers, and properties |
| Community brands    | `/api/brands/save`                              | Contribute brand data (auth required)            |

The registry complements the protocol: resolve entities via the REST API, then transact via MCP/A2A tasks.

<Card title="Registry API" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/registry">
  Complete endpoint reference with authentication and rate limits.
</Card>

***

### Proposals and delivery forecasts

Publishers can return **proposals** alongside products — structured media plans with percentage-based budget allocations that buyers can execute directly via `create_media_buy`. Proposals encode publisher expertise, replacing ad-hoc product lists with actionable buying strategies. They can be refined through session continuity — subsequent `get_products` calls within the same session carry conversation history.

**Delivery forecasts** attach to proposals and allocations. Each forecast contains budget points with metric ranges (low/mid/high), showing how delivery scales with spend. Three forecast methods: **`estimate`** (rough approximation), **`modeled`** (predictive models), **`guaranteed`** (contractually committed). Forecasts can predict delivery metrics (impressions, reach, GRPs) and outcomes (purchases, leads, app installs). TV and radio forecasts use `demographic_system` and `demographic` for GRP-based planning.

<Card title="Proposals and forecasting" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/media-buy/product-discovery/media-products#proposals">
  Complete documentation including budget curves, CTV, retail media, and broadcast audio examples.
</Card>

***

### Accounts

<Tip>
  **Migrating from v2?** Accounts are entirely new in v3 — there is no v2 equivalent to migrate from. Start with [Accounts and Agents](/dist/docs/3.0.0-rc.2/building/integration/accounts-and-agents) for the setup guide.
</Tip>

Formal billing relationships between buyers and sellers via `sync_accounts`.

**Four entities:**

| Entity       | Question                            | How identified                                                                                                                                            |
| ------------ | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Brand**    | Whose products are advertised?      | House domain + brand\_id via `brand.json`                                                                                                                 |
| **Account**  | Who gets billed?                    | [Account reference](/dist/docs/3.0.0-rc.2/building/integration/accounts-and-agents#account-references) — `account_id` from `list_accounts` or natural key |
| **Operator** | Who operates on the brand's behalf? | Domain (e.g., `acmeagency.example.com`)                                                                                                                   |
| **Agent**    | What software places buys?          | Authenticated session                                                                                                                                     |

**Two billing models:** `operator` (operator or brand buying direct is invoiced) and `agent` (agent consolidates billing). **Two trust models:** agent-trusted (default, agent declares brands/operators) and operator-scoped (seller requires operator-level credentials).

**Workflow:** `get_adcp_capabilities` -> `sync_accounts` -> `get_products` with `account` -> `create_media_buy` with `account`.

<Card title="Accounts Protocol" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/accounts/overview">
  Accounts Protocol overview: identity verification, billing models, and settlement.
</Card>

***

### Catalogs

First-class catalog lifecycle with `sync_catalogs`. Thirteen catalog types: structural (`offering`, `product`, `inventory`, `store`, `promotion`) and industry-vertical (`hotel`, `flight`, `job`, `vehicle`, `real_estate`, `education`, `destination`, `app`). Vertical types have canonical item schemas drawn from Google Ads, Meta, LinkedIn, and Microsoft feed specs.

Formats declare what catalogs they need via `catalog_requirements`. Creatives reference synced catalogs by `catalog_id` instead of embedding items in assets. Catalogs declare `conversion_events` and `content_id_type` for attribution alignment.

<Card title="Catalogs" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/creative/catalogs">
  Complete documentation including catalog types, sync workflow, format requirements, and conversion events.
</Card>

***

### Capability discovery

`get_adcp_capabilities` replaces both `adcp-extension.json` and the MCP agent card with runtime capability discovery. It returns supported protocols, account billing models, portfolio information, targeting systems, and governance features — all schema-validated.

<Warning>
  **Agent cards and `adcp-extension.json` are no longer needed.** Buyers discover sellers through `adagents.json` and call `get_adcp_capabilities` at runtime. If your v2 integration reads capability data from agent card extensions, switch to `get_adcp_capabilities`.
</Warning>

<Card title="get_adcp_capabilities" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/protocol/get_adcp_capabilities">
  Full task reference with request/response schemas.
</Card>

***

### Governance Protocol

Brand suitability and inventory curation. Governance agents manage **property lists** (curated sets of properties for targeting or exclusion) and **content standards** (brand suitability policies with per-category block/allow rules). Buyers pass property lists to `get_products` for filtered inventory discovery, and use `calibrate_content` for collaborative alignment between brand and governance agent. Governance agents can enforce `provenance_required` on creative policy and support third-party AI content verification via the `verification` array on provenance claims.

<Card title="Governance Protocol" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/governance/overview">
  Full specification including property lists, content standards, and calibration.
</Card>

***

### Sponsored Intelligence Protocol

Conversational brand experiences in AI assistants. SI defines how AI assistants invoke brand agents for rich engagement (text, voice, UI components) without breaking the conversational flow. Sessions follow a consent-first model: user expresses interest, grants consent, then the brand agent engages conversationally with optional transaction handoff.

<Card title="Sponsored Intelligence" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/sponsored-intelligence/overview">
  Full specification including session lifecycle, implementing agents, and implementing hosts.
</Card>

***

### Signal catalogs for data providers

Data providers can publish signal catalogs via `adagents.json`, following the same pattern as publishers declaring properties.

| Publishers                           | Data providers                           |
| ------------------------------------ | ---------------------------------------- |
| Declare **properties**               | Declare **signals**                      |
| Use `property_ids` / `property_tags` | Use `signal_ids` / `signal_tags`         |
| Buyers verify via `publisher_domain` | Buyers verify via `data_provider_domain` |

Signals now have explicit `value_type` (binary, categorical, numeric) with typed targeting, and structured `signal_id` objects that reference the data provider's catalog.

<Card title="Data provider guide" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/signals/data-providers">
  Complete implementation guide for publishing signal catalogs.
</Card>

***

## Breaking changes

### Media channel taxonomy

v2's 9 channels are replaced by 20 planning-oriented channels. Five channels carried over unchanged (`display`, `social`, `ctv`, `podcast`, `dooh`). The remaining four are split, removed, or renamed.

<Warning>
  All code that reads or writes channel values must be updated.
</Warning>

| v2 channel | v3 channel(s)                | Notes                                                            |
| ---------- | ---------------------------- | ---------------------------------------------------------------- |
| `display`  | `display`                    | Unchanged                                                        |
| `video`    | `olv`, `linear_tv`, `cinema` | Split by distribution context (`ctv` was already separate in v2) |
| `audio`    | `radio`, `streaming_audio`   | Split by distribution (`podcast` was already separate in v2)     |
| `native`   | Removed                      | Use format-level properties instead                              |
| `social`   | `social`                     | Unchanged                                                        |
| `ctv`      | `ctv`                        | Unchanged                                                        |
| `podcast`  | `podcast`                    | Unchanged                                                        |
| `dooh`     | `dooh`                       | Unchanged                                                        |
| `retail`   | `retail_media`               | Renamed for clarity                                              |

New channels in v3 (no v2 equivalent): `search`, `linear_tv`, `radio`, `streaming_audio`, `ooh`, `print`, `cinema`, `email`, `gaming`, `retail_media`, `influencer`, `affiliate`, `product_placement`, `sponsored_intelligence`.

<Note>
  The `gaming` channel covers intrinsic in-game ads, rewarded video, and playable ads. Rewarded video in gaming apps could also be classified as `olv` — use `gaming` when the inventory comes from a gaming budget.
</Note>

<Card title="Channels deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/channels">
  Complete mapping guide with examples for each v2 channel, multi-channel products, and capability discovery.
</Card>

***

### Pricing option field renames

v3 separates **hard constraints** (publisher-enforced prices) from **soft hints** (historical percentiles). `fixed_rate` becomes `fixed_price`, and `price_guidance.floor` moves to top-level `floor_price`.

| v2 field               | v3 field      | Notes                                          |
| ---------------------- | ------------- | ---------------------------------------------- |
| `fixed_rate`           | `fixed_price` | Renamed for clarity (it's a price, not a rate) |
| `price_guidance.floor` | `floor_price` | Moved to top level as hard constraint          |

These fields map to standard deal types: `fixed_price` corresponds to Programmatic Guaranteed (PG) and Preferred Deals, while `floor_price` corresponds to Private Marketplace (PMP) auctions. Open auction inventory omits both fields.

<Card title="Pricing deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/pricing">
  Fixed-price vs auction examples, price guidance schema, flat-rate pricing, minimum spend, and transition period handling.
</Card>

***

### Creative assignments with weighting

`creative_ids` string arrays are replaced by `creative_assignments` objects that support delivery weighting and placement targeting.

| v2 field                      | v3 field                                                                            |
| ----------------------------- | ----------------------------------------------------------------------------------- |
| `creative_ids` (string array) | `creative_assignments` (object array with `creative_id`, `weight`, `placement_ids`) |

<Card title="Creatives deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/creatives">
  Weighted assignments, placement targeting, asset discovery with the unified `assets` array, repeatable groups, and format cards.
</Card>

***

### Geo targeting with named systems

Metro and postal targeting now require explicit system specification, supporting global markets. Values are grouped by system using `{ "system": "...", "values": [...] }` objects.

| v2 field                          | v3 field                                   |
| --------------------------------- | ------------------------------------------ |
| `geo_metros` (string array)       | `geo_metros` (system/values objects)       |
| `geo_postal_codes` (string array) | `geo_postal_areas` (system/values objects) |

v3 also adds `geo_metros_exclude` and `geo_postal_areas_exclude` for negative targeting (e.g., target the US except the New York DMA).

<Card title="Geo targeting deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/geo-targeting">
  Metro and postal system reference tables, exclusion targeting, capability discovery, and a full targeting example.
</Card>

***

### Other targeting changes

v3 adds several targeting fields beyond geo:

| Field                                   | Description                                                                                                      |
| --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `daypart_targets`                       | Time-of-day and day-of-week targeting windows                                                                    |
| `age_restriction`                       | Age-gating for restricted content                                                                                |
| `device_platform`                       | Operating system targeting (iOS, Android, Windows, tvOS, etc.)                                                   |
| `device_type`                           | Device form factor targeting (desktop, mobile, tablet, ctv, dooh, unknown)                                       |
| `language`                              | Content language targeting                                                                                       |
| `keyword_targets` / `negative_keywords` | Keyword targeting for search and retail media with match types (broad, phrase, exact) and per-keyword bid prices |
| `device_type_exclude`                   | Negative device form factor targeting                                                                            |
| `geo_proximity`                         | Point-based proximity targeting via travel time isochrones, radius, or GeoJSON geometry                          |

These fields are optional additions — they don't replace any v2 fields.

***

### Unified asset discovery

Formats now use an `assets` array with `required` boolean instead of `assets_required`. See the [creatives deep dive](/dist/docs/3.0.0-rc.2/reference/migration/creatives#asset-discovery).

***

### Catalogs replace promoted\_offerings

The `promoted_offerings` creative asset type and `promoted_offering` string field are removed. Catalogs are now first-class protocol objects with their own sync lifecycle (`sync_catalogs`), format-level requirements (`catalog_requirements`), and conversion event alignment.

| v2 field                                          | v3 replacement                        |
| ------------------------------------------------- | ------------------------------------- |
| `promoted_offerings` (creative asset)             | `catalogs` field on creative manifest |
| `promoted_offering` (string on media-buy)         | Removed — use `brand` + `brief`       |
| `promoted_offering` (string on creative-manifest) | Removed — use `catalogs` field        |

<Card title="Catalogs deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/catalogs">
  Before/after examples, sync\_catalogs workflow, catalog\_requirements discovery, and migration checklist.
</Card>

***

### Brand identity unification

Inline `brand_manifest` objects are replaced by brand references (`BrandRef`). Task schemas reference brands by `{ domain, brand_id }` instead of passing manifests inline. Brand data is resolved from `brand.json` or the registry at execution time.

| v2/beta field                    | v3 rc.1 field                    |
| -------------------------------- | -------------------------------- |
| `brand_manifest` (inline object) | `brand` (`{ domain, brand_id }`) |

Affects: `get_products`, `create_media_buy`, `build_creative`, and property list schemas.

<Card title="Brand identity deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/brand-identity">
  BrandRef schema, resolution flow, before/after examples, and migration steps.
</Card>

***

### Product delivery forecasts

`estimated_exposures` is replaced by a structured `forecast` field using the `DeliveryForecast` type.

| v2/beta field                   | v3 rc.1 field                                                               |
| ------------------------------- | --------------------------------------------------------------------------- |
| `estimated_exposures` (integer) | `forecast` (DeliveryForecast with time periods, metric ranges, methodology) |

***

### Proposal refinement via buying mode

`proposal_id` is removed from the `get_products` request. Refinement now uses `buying_mode: "refine"` with a typed `refine` array of change-requests (see [typed refinement](#typed-refinement-with-seller-acknowledgment)). Session continuity (`context_id` in MCP, `contextId` in A2A) carries conversation history across calls.

Proposal execution via `create_media_buy` with `proposal_id` is unchanged.

| v2/beta field                           | v3 rc.1 field                         |
| --------------------------------------- | ------------------------------------- |
| `proposal_id` on `get_products` request | Removed — use `buying_mode: "refine"` |

***

### Optimization goals redesign

`optimization_goal` (singular object) is replaced by `optimization_goals` (array). Each goal is a discriminated union on `kind`:

| v2/beta field                       | v3 rc.1 field                            |
| ----------------------------------- | ---------------------------------------- |
| `optimization_goal` (single object) | `optimization_goals` (array)             |
| Implicit single goal                | `priority` field for multi-goal ordering |

Two goal kinds:

* **`metric`** — Seller-native delivery metrics (clicks, views, reach, engagements, etc.) with `cost_per` or `threshold_rate` targets
* **`event`** — Conversion tracking with `event_sources` array and optional `value_field`/`value_factor`

<Card title="Optimization goals deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/optimization-goals">
  Goal kinds, reach optimization, multi-goal priority, product capabilities, and migration steps.
</Card>

***

### Signals pricing restructure

The legacy `pricing: { cpm }` object on signals is replaced by a structured `pricing_options` array with three pricing models.

| v2/beta field          | v3 rc.1 field                                        |
| ---------------------- | ---------------------------------------------------- |
| `pricing.cpm` (number) | `pricing_options[]` (array of pricing model objects) |

Three models: `cpm`, `percent_of_media` (with optional `max_cpm`), `flat_fee`.

<Card title="Signals deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/signals">
  Pricing models, deliver\_to flattening, usage reporting, and migration steps.
</Card>

***

### Signals deliver\_to flattening

The nested `deliver_to` object in `get_signals` request is replaced with two top-level fields.

| v2/beta field             | v3 rc.1 field              |
| ------------------------- | -------------------------- |
| `deliver_to.destinations` | `destinations` (top-level) |
| `deliver_to.countries`    | `countries` (top-level)    |

***

### AudienceMember external\_id required

`external_id` is promoted from a uid-type enum value to a required top-level field on AudienceMember. Every member must have a buyer-assigned stable identifier plus at least one matchable identifier.

<Card title="Audiences deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/reference/migration/audiences">
  Before/after examples, uid-type changes, sync\_audiences usage, and migration steps.
</Card>

***

### Typed refinement with seller acknowledgment

`refine` is redesigned from a nested object with `overall`/`products`/`proposals` to a flat typed array. Each entry is discriminated by `scope`:

| v2/beta field                  | v3 rc.1 field                                      |
| ------------------------------ | -------------------------------------------------- |
| `refine.overall` (string)      | `{ "scope": "request", "ask": "..." }` array entry |
| `refine.products[].product_id` | `{ "scope": "product", "id": "..." }`              |
| `refine.products[].notes`      | `ask` field                                        |

Sellers respond with `refinement_applied` — a positionally-matched array where each entry reports `status` (`applied`, `partial`, `unable`) and optional `notes`.

<Card title="Refinement deep dive" icon="arrow-right" href="/dist/docs/3.0.0-rc.2/media-buy/product-discovery/refinement">
  Change-request types, seller acknowledgment, and before/after examples.
</Card>

***

### Creative assignments restructured

`SyncCreativesRequest.assignments` changed from a `{ creative_id: package_id[] }` map to a typed array with explicit fields.

| v2/beta field              | v3 rc.1 field                                                                 |
| -------------------------- | ----------------------------------------------------------------------------- |
| `assignments` (object map) | `assignments` (array of `{ creative_id, package_id, weight, placement_ids }`) |

***

### Signals account and field consistency

Two consistency changes to signals schemas:

| v2/beta field                                                | v3 rc.1 field                                               |
| ------------------------------------------------------------ | ----------------------------------------------------------- |
| `account_id` (string) on `get_signals` and `activate_signal` | `account` (AccountReference object)                         |
| `deployments` on `activate_signal`                           | `destinations` (renamed for consistency with `get_signals`) |

***

### Package catalogs as array

| v2/beta field                                | v3 rc.1 field                      |
| -------------------------------------------- | ---------------------------------- |
| `catalog` (single Catalog object) on Package | `catalogs` (array of Catalog refs) |

***

### Brand tone structured format

Brand `tone` is now an object type only — string format is removed. Structured tone includes `voice`, `attributes`, `dos`, and `donts` fields. Existing string values should migrate to `{ "voice": "<previous-string>" }`.

| v2/beta field             | v3 rc.2 field                                        |
| ------------------------- | ---------------------------------------------------- |
| `tone` (string or object) | `tone` (object: `{ voice, attributes, dos, donts }`) |

***

### Account resolution removed

`account_resolution` capability field is removed. `require_operator_auth` now determines both the auth model and account reference style: `true` means explicit accounts (discover via `list_accounts`, pass `account_id`), `false` means implicit accounts (declare via `sync_accounts`, pass natural key).

| v2/beta/rc.1 field              | v3 rc.2 field                         |
| ------------------------------- | ------------------------------------- |
| `account_resolution` capability | Removed — use `require_operator_auth` |

***

### Privacy and consent

AdCP does not define its own consent framework. Privacy signals (TCF 2.0, GPP, US Privacy String) should be passed via the brief's `ext` field or through transport-level headers. Sellers that require consent signals should declare this in `get_adcp_capabilities` using the extension mechanism.

***

## Removed in v3

| Removed                                               | Replacement                                                           |
| ----------------------------------------------------- | --------------------------------------------------------------------- |
| `adcp-extension.json` agent card                      | `get_adcp_capabilities` task                                          |
| `list_authorized_properties` task                     | `get_adcp_capabilities` portfolio section                             |
| `assets_required` in formats                          | `assets` array with `required` boolean                                |
| `preview_image` in formats                            | `format_card` object                                                  |
| `creative_ids` in packages                            | `creative_assignments` array                                          |
| `geo_postal_codes`                                    | `geo_postal_areas`                                                    |
| `fixed_rate` in pricing                               | `fixed_price`                                                         |
| `price_guidance.floor`                                | `floor_price` (top-level)                                             |
| `promoted_offerings` asset type                       | `catalogs` field on creative manifest                                 |
| `promoted_offering` on media-buy                      | Removed — use `brand` + `brief`                                       |
| `promoted_offering` on creative-manifest              | `catalogs` field                                                      |
| `brand_manifest` (inline object)                      | `brand` ref (`{ domain, brand_id }`)                                  |
| `estimated_exposures` on Product                      | `forecast` (DeliveryForecast)                                         |
| `proposal_id` on `get_products` request               | Session continuity (`context_id` / `contextId`)                       |
| `refine` object with `overall`/`products`/`proposals` | `refine` array of typed change-requests                               |
| `creative_brief` on `build_creative` request          | `brief` asset type in manifest `assets` map                           |
| `supports_brief` capability                           | `supports_compliance`                                                 |
| `creative-brief-ref.json` schema                      | Deleted — briefs are now asset types                                  |
| `deployments` on `activate_signal`                    | `destinations`                                                        |
| `account_id` (string) on signals tasks                | `account` (AccountReference)                                          |
| `report_usage.kind` and `report_usage.operator_id`    | Removed                                                               |
| `catalog` (singular) on Package                       | `catalogs` (array)                                                    |
| `account_resolution` capability                       | `require_operator_auth` determines account model                      |
| `delete_content_standards` task                       | Archive via `update_content_standards` instead                        |
| `get_property_features` task                          | Property list filters + `get_adcp_capabilities` for feature discovery |
| `tone` as string on brand.json                        | Object only: `{ voice, attributes, dos, donts }`                      |

***

## Migration checklists

<AccordionGroup>
  <Accordion title="All implementations" defaultOpen>
    These breaking changes affect anyone reading or writing AdCP data:

    * [ ] Update channel enum values to [new taxonomy](/dist/docs/3.0.0-rc.2/reference/migration/channels)
    * [ ] Rename `fixed_rate` -> `fixed_price` in [pricing options](/dist/docs/3.0.0-rc.2/reference/migration/pricing)
    * [ ] Move `price_guidance.floor` -> `floor_price` ([pricing details](/dist/docs/3.0.0-rc.2/reference/migration/pricing))
    * [ ] Replace `creative_ids` with [`creative_assignments`](/dist/docs/3.0.0-rc.2/reference/migration/creatives)
    * [ ] Add system specification to [metro/postal targeting](/dist/docs/3.0.0-rc.2/reference/migration/geo-targeting)
    * [ ] Rename `geo_postal_codes` -> `geo_postal_areas`
    * [ ] Handle new `geo_metros_exclude` and `geo_postal_areas_exclude` fields
    * [ ] Update format parsing to use [`assets` array](/dist/docs/3.0.0-rc.2/reference/migration/creatives#asset-discovery)
    * [ ] Replace `preview_image` reads with [`format_card`](/dist/docs/3.0.0-rc.2/reference/migration/creatives#format-cards-replacing-preview_image) rendering
    * [ ] Replace `list_authorized_properties` calls with `get_adcp_capabilities` portfolio
    * [ ] Remove `promoted_offerings` from creative manifest assets and replace with [`catalogs` field](/dist/docs/3.0.0-rc.2/reference/migration/catalogs)
    * [ ] Remove `promoted_offering` string from media buy and creative manifest objects
    * [ ] Update `optimization_goal` to [`optimization_goals`](/dist/docs/3.0.0-rc.2/media-buy/media-buys/optimization-reporting) (array of discriminated union)
    * [ ] Handle `external_id` as required field on AudienceMember
    * [ ] Replace `brand_manifest` with `brand` ref (`{ domain, brand_id }`) in all task calls
    * [ ] Replace `estimated_exposures` reads with `forecast` (DeliveryForecast) on products
    * [ ] Remove `proposal_id` from `get_products` requests — use session continuity for refinement
    * [ ] Update `refine` from object to typed array with `scope` discriminator
    * [ ] Handle `recovery` field on errors for retry/correction logic
    * [ ] Update `catalog` to `catalogs` (array) on packages
    * [ ] Update signals `account_id` to `account` (AccountReference)
    * [ ] Rename signals `deployments` to `destinations`
    * [ ] Pass `buying_mode` (now required) on `get_products`
    * [ ] Move `creative_brief` to `brief` asset type in manifest `assets` map
    * [ ] Handle `report_usage` without `kind` and `operator_id` fields
    * [ ] Update `SyncCreativesRequest.assignments` from object map to typed array
    * [ ] Migrate brand `tone` from string to object format (`{ voice, attributes, dos, donts }`)
    * [ ] Remove `account_resolution` reads — use `require_operator_auth` instead
    * [ ] Remove `delete_content_standards` calls — archive via `update_content_standards`
    * [ ] Remove `get_property_features` calls — use property list filters
    * [ ] Validate all requests/responses against v3 schemas
  </Accordion>

  <Accordion title="Seller agents (publishers, SSPs, networks)">
    Update all data structures to v3 format (channels, pricing, geo targeting), then implement new capabilities:

    * [ ] Implement `get_adcp_capabilities` task (including `account` capabilities)
    * [ ] Remove `adcp-extension.json` from agent card
    * [ ] Implement `sync_accounts` for account provisioning
    * [ ] Return proposals with delivery forecasts from `get_products` when applicable
    * [ ] Support property list filtering in `get_products` if integrating with governance agents
    * [ ] Handle catalogs synced via [`sync_catalogs`](/dist/docs/3.0.0-rc.2/reference/migration/catalogs) with approval workflow
    * [ ] Declare `metric_optimization` capabilities on products
    * [ ] Declare `reporting` capabilities in `get_adcp_capabilities` for dimension breakdowns
    * [ ] Support `reporting_dimensions` parameter on `get_media_buy_delivery`
    * [ ] Return `refinement_applied` array when processing `refine` requests
    * [ ] Implement `rejected` status and `rejection_reason` on media buys
    * [ ] Support `fields` projection parameter on `get_products`
    * [ ] Declare `supported_pricing_models` in `get_adcp_capabilities`
  </Accordion>

  <Accordion title="Buyer agents and orchestrators (DSPs, agencies, brands)">
    Update all requests and response handling to v3 format, then integrate new capabilities:

    * [ ] Resolve brands via [`brand.json`](/dist/docs/3.0.0-rc.2/brand-protocol) before placing buys
    * [ ] Call `sync_accounts` to establish billing relationships
    * [ ] Update to call `get_adcp_capabilities` for runtime discovery
    * [ ] Evaluate proposals and delivery forecasts when returned by sellers
    * [ ] Use the [Registry API](/dist/docs/3.0.0-rc.2/registry) for brand/property resolution and agent discovery
    * [ ] Pass property lists to filter inventory when working with governance agents
    * [ ] Invoke SI sessions when connecting users with brand agents
    * [ ] Sync catalogs via [`sync_catalogs`](/dist/docs/3.0.0-rc.2/reference/migration/catalogs) before submitting creatives
    * [ ] Add `conversion_events` to catalogs for attribution tracking
    * [ ] Update `optimization_goal` to `optimization_goals` array in `create_media_buy`
    * [ ] Pass `pricing_option_id` when activating signals with pricing options
    * [ ] Use `reporting_dimensions` for dimension breakdowns in delivery reporting
    * [ ] Handle `refinement_applied` response for typed refinement feedback
    * [ ] Use `recovery` field on errors for automated retry/correction
    * [ ] Use `fields` projection on `get_products` for efficient discovery
    * [ ] Handle `rejected` status on media buys
    * [ ] Use `action: "deactivate"` on `activate_signal` for campaign cleanup
    * [ ] Integrate `get_rights` / `acquire_rights` for licensed content campaigns
    * [ ] Handle `visual_guidelines` from `brand.json` for creative generation
  </Accordion>

  <Accordion title="Signals agents (data providers, measurement vendors)">
    Update schema references from v2 to v3. Signals Protocol doesn't use media channels in its core model.

    * [ ] Update schema references from v2 to v3
    * [ ] Ensure `get_adcp_capabilities` returns `major_versions: [3]`
    * [ ] Return structured `signal_id` objects in `get_signals` responses
    * [ ] Include `value_type` field in signal responses
    * [ ] Support `signal_ids` parameter in `get_signals` requests for ID-based lookup
    * [ ] Update from legacy `pricing` to structured `pricing_options` array
    * [ ] Handle top-level `destinations`/`countries` instead of nested `deliver_to`
    * [ ] Add `idempotency_key` support to `report_usage`
    * [ ] Support `action: "deactivate"` on `activate_signal`
    * [ ] Include `categories` and `range` metadata in signal entries
    * [ ] Update `account_id` to `account` (AccountReference)
    * [ ] Rename `deployments` to `destinations`
  </Accordion>

  <Accordion title="Data providers (new in v3)">
    Publish signal catalogs via `adagents.json`. See [Data Provider Guide](/dist/docs/3.0.0-rc.2/signals/data-providers).

    * [ ] Create signal catalog in `/.well-known/adagents.json`
    * [ ] Define signals with `id`, `name`, `value_type`, and optional metadata
    * [ ] Add `signal_tags` for grouping and efficient authorization
    * [ ] Authorize signals agents using `signal_ids` or `signal_tags` authorization types
    * [ ] Validate catalog using AdAgents.json Builder
  </Accordion>

  <Accordion title="Creative agents (creative management, DCO providers)">
    Support new asset discovery and integrate brand identity. Format `type` field (video, display, audio) is IAB creative classification, not media channels.

    * [ ] Support `assets` array with `required` boolean (replaces `assets_required`)
    * [ ] Replace `preview_image` with `format_card` rendering
    * [ ] Resolve brand identity via `brand.json` for on-brand creative generation
    * [ ] Support `catalog` field on creative manifests (replaces [`promoted_offerings`](/dist/docs/3.0.0-rc.2/reference/migration/catalogs) asset)
    * [ ] Declare `catalog_requirements` on formats that render catalog items
    * [ ] Update schema references from v2 to v3
    * [ ] Support `provenance` object on creative manifests and assets
    * [ ] Support `brief` and `catalog` as asset types in the `assets` map
    * [ ] Handle `compliance.required_disclosures` on creative briefs
    * [ ] Check format `supported_disclosure_positions` compatibility
    * [ ] Declare `supports_compliance` in capabilities (replaces `supports_brief`)
    * [ ] Handle `visual_guidelines` from `brand.json` for on-brand asset generation
  </Accordion>

  <Accordion title="Brands (new in v3)">
    Establish buy-side identity. See [brand.json specification](/dist/docs/3.0.0-rc.2/brand-protocol/brand-json).

    * [ ] Host `/.well-known/brand.json` on your domain
    * [ ] Declare brand portfolio, properties, and authorized operators
    * [ ] Optionally provide brand data (logos, colors, fonts, tone) inline in `brand.json` or via brand agent
    * [ ] Add `visual_guidelines` to `brand.json` for generative creative systems
    * [ ] Implement `get_rights` / `acquire_rights` / `update_rights` if licensing content
    * [ ] Register in the [community brand registry](/dist/docs/3.0.0-rc.2/registry) if not hosting `brand.json`
  </Accordion>

  <Accordion title="Governance agents (new in v3)">
    Implement brand suitability capabilities. See [Governance Protocol](/dist/docs/3.0.0-rc.2/governance).

    * [ ] Implement property list tasks (`create_property_list`, `get_property_list`, etc.)
    * [ ] Implement content standards tasks (`create_content_standards`, `calibrate_content`, etc.)
    * [ ] Implement `get_adcp_capabilities` with `governance` in `supported_protocols`
    * [ ] Implement `provenance_required` enforcement on creative policy
    * [ ] Support `verification` results from AI detection services
    * [ ] Implement `get_creative_features` for creative evaluation
    * [ ] Declare `creative_features` in `get_adcp_capabilities`
  </Accordion>

  <Accordion title="Sponsored Intelligence agents (new in v3)">
    Implement conversational brand experiences. See [Sponsored Intelligence](/dist/docs/3.0.0-rc.2/sponsored-intelligence/overview).

    * [ ] Implement SI session tasks (`si_initiate_session`, `si_send_message`, `si_terminate_session`)
    * [ ] Implement `get_adcp_capabilities` with `sponsored_intelligence` in `supported_protocols`
  </Accordion>
</AccordionGroup>

***

## Getting help

* **Community**: [Slack](https://join.slack.com/t/agenticads/shared_invite/zt-3c5sxvdjk-x0rVmLB3OFHVUp~WutVWZg)
* **Issues**: [GitHub Issues](https://github.com/adcontextprotocol/adcp/issues)
* **Support**: [support@adcontextprotocol.org](mailto:support@adcontextprotocol.org)
