> ## 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.3 beta program

> Where the AdCP 3.3 beta stands at beta.3, how to test a beta before SDK support or against the public test agent's preview, which SDK versions bundle which beta, and which proposals are still in review for 3.3.

# AdCP 3.3 beta program

> [!WARNING]
>
> **Use the beta in development and staging, not production.** New production integrations should stay on AdCP 3.2 until 3.3 reaches general availability. Every beta is an immutable checkpoint, but later betas may change 3.3 surfaces before GA.

3.3 is a minor release with a deliberately short cycle. Its beta follows the same order as 3.2: the protocol first, then the SDKs.

## Beta status

The latest checkpoint is **`3.3.0-beta.3`, published 2026-10-31**. Each beta is an immutable, signed checkpoint, and later betas may change 3.3 surfaces before GA. GA follows the first beta that meets every one of the proposed GA criteria in [#8600](https://github.com/adcontextprotocol/adcp/issues/8600): SDK support for the latest beta, green storyboards, the closed-schema triage ([#8501](https://github.com/adcontextprotocol/adcp/issues/8501)), no open objections on consent items and decision records, and current release docs. Objections are due by 2026-11-06, or at the 2026-11-09 working-group session.

| Checkpoint | Published | Purpose | Who should test |
| - | - | - | - |
| `3.3.0-beta.0` | 2026-10-22 | Canonical schemas, compliance assets, skills, and protocol manifest for SDK implementation | SDK maintainers, code-generator maintainers, raw-wire implementers, and agent teams that can validate without generated 3.3 SDK types |
| `3.3.0-beta.1` | 2026-10-29 | Beta.0 integration corrections, the account identity model, `request_account`, principal-level reporting subscriptions, undisclosed rosters, and the first commercial experiments | Buyer and seller teams running end-to-end integrations, and SDK maintainers ingesting the bundle |
| `3.3.0-beta.2` | 2026-10-30 | Account change outcomes, seller offers, measurement provenance, structural capability bounds, the principal clarification, reporting-subscription convergence, and the withdrawal of definition pins, purchase rights, and installment selection | The same teams, against the withdrawn surfaces removed |
| `3.3.0-beta.3` | 2026-10-31 | Live creative updates, the protocol envelope on every task response, money terms on resolved account requests, revocation as no access, and reporting-subscription coverage computable from the wire | The same teams; this is the checkpoint the docs describe |

Beta.0 did not wait for the SDKs. A checkpoint is SDK-backed only after the matching SDK versions and integration evidence are published. `@adcp/sdk` 17.0.0-beta.11 is the first published SDK that bundles beta.3 ([SDK guidance](#sdk-guidance)). Three features that shipped in the betas are [withdrawn after beta.1](#withdrawn-after-beta-1).

## Know which version string to use

The artifact version, wire pin, and documentation selector are related but not interchangeable:

| Surface | beta.0 | beta.1 | beta.2 | beta.3 |
| - | - | - | - | - |
| Protocol artifact | `3.3.0-beta.0` | `3.3.0-beta.1` | `3.3.0-beta.2` | `3.3.0-beta.3` |
| Git tag | `v3.3.0-beta.0` | `v3.3.0-beta.1` | `v3.3.0-beta.2` | `v3.3.0-beta.3` |
| `adcp_version` wire pin | `"3.3-beta.0"` | `"3.3-beta.1"` | `"3.3-beta.2"` | `"3.3-beta.3"` |
| Documentation selector | `3.3-beta` | `3.3-beta` | `3.3-beta` | `3.3-beta` |

Only send a prerelease wire pin to a peer that advertises that exact value in `get_adcp_capabilities.adcp.supported_versions`. Prerelease pins are exact: a buyer pinned to `"3.3-beta.2"` must not silently negotiate to beta.3, and a stable `"3.2"` pin must not silently negotiate to a beta.

## Test a beta without an SDK

Download the signed protocol bundle of the beta you test (the commands use the latest, `3.3.0-beta.3`; substitute another published checkpoint) rather than copying schemas from `main` or from the moving `/schemas/3.3.0-beta.4/` path:

```bash theme={null}
curl -fLO https://adcontextprotocol.org/protocol/3.3.0-beta.3.tgz
curl -fLO https://adcontextprotocol.org/protocol/3.3.0-beta.3.tgz.sha256
shasum -a 256 -c 3.3.0-beta.3.tgz.sha256
tar -xzf 3.3.0-beta.3.tgz
```

The extracted `adcp-3.3.0-beta.3/` directory contains:

* `manifest.json`: release version, bundle contents, skills, and file count;
* `schemas/`: source-shaped and bundled request/response schemas, including `schemas/manifest.json` for the task and capability inventory;
* `compliance/`: storyboards, test kits, vectors, and runner contracts;
* `skills/`: role guidance for coding agents;
* `openapi/`: published OpenAPI artifacts.

Verify the Sigstore signature before using the bundle as a build input. See [Verifying protocol tarballs](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/verifying-protocol-tarballs.md) for the certificate-identity and issuer checks.

Useful tests are:

1. Generate or refresh types from the pinned bundled schemas.
2. Validate representative requests and responses for the roles you implement, including the new 3.3 surfaces you plan to adopt: the `account_id` identity model and, if you support it, `request_account`; `status` on every response through the protocol envelope; `expected_confirmation_at`, vendor-metric `outcome_target` goals, `reporting_webhook.operation_id`, `media_buy.features.catalog_ingestion`, the DOOH `location` and `dooh_inventory_summary` fields, `sync_audiences` audience sizes, and the experimental spot, print, daypart, loudness, reporting-subscription, live-creative-update, and governance `budget.periods[]` fields.
3. Compare your advertised tools with `schemas/manifest.json`.
4. Exercise raw MCP or A2A calls with `adcp_version: "3.3-beta.3"` against a staging peer that advertises the same pin.
5. Run the compliance assets with a source-compatible runner if you maintain one. Do not weaken production authentication to accommodate a beta runner.

## Try the preview on the public test agent

The public test agent at `https://test-agent.adcontextprotocol.org` serves `3.3.0-beta.3` as an opt-in preview alongside its stable releases. It lists `"3.3-beta.3"` in `adcp.supported_versions` and serves the preview only to a request that pins exactly that value:

| Request | Served |
| - | - |
| `adcp_version: "3.3-beta.3"` | The preview. Responses echo `"3.3-beta.3"` and validate against the published `3.3.0-beta.3` schemas. |
| `adcp_version: "3.2"`, `"3.3"`, or a later release | 3.2. A release pin never resolves onto a prerelease. |
| Any other 3.3 prerelease, such as `"3.3-beta.2"` | Never the preview. Prerelease pins match exactly. |
| `adcp_major_version` alone, or no version | The route's stable default, never the preview. |

```bash theme={null}
curl -s https://test-agent.adcontextprotocol.org/sales/mcp \
  -H "Authorization: Bearer $ADCP_AUTH_TOKEN" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_adcp_capabilities","arguments":{"adcp_version":"3.3-beta.3"}}}'
```

At the preview pin, `/sales/mcp` serves the experimental 3.3 surfaces the training agent implements:

* account requests (`account.requests`): `request_account`, and `account_requests` on `list_accounts`;
* the caller's `authorization`, with `authorized_at` and `regranted_at`, and `revision` on each `list_accounts` account;
* principal-level reporting subscriptions (`media_buy.reporting_subscriptions`): the `reporting_subscriptions` section of `sync_principal` and `get_principal`, and `subscription_coverage` on `get_reporting_status`;
* the `reporting_subscription_probe` controller scenario, which revokes, reduces, and restores grants and advances a per-caller sandbox clock;
* collection cards (`media_buy.collection_cards`): `include_collections` on `get_products`, `list_products`, `request_proposals` and `refine_proposals`, with images, samples, links, talent `brand_ref` and follower counts on the CreatorLoop creator channels;
* the collection catalog (`media_buy.collection_catalog`): `list_collections`, and the `collection_card.*` and `collection_catalog.bulk_change` webhooks registered through `sync_accounts`;
* the `seed_collection` controller scenario, which changes the caller's cards (a sample, a removal, a follower sweep) so the card webhooks fire;
* inventory holds ([Hold policy](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/media-buy/task-reference/refine_proposals.md#hold-policy-experimental)): `hold_policy` on products and drafts (`media_buy.hold_policy`), committed proposals with `hold_placed_at`, ranked holds with `hold_rank` (`media_buy.hold_ranking`), per-installment `holds` (`media_buy.installment_holds`), `extend_hold` (`media_buy.hold_extension`), and the `force_hold_unavailable` controller scenario.

At the same pin, `/brand/mcp` returns `collections` on `get_brand_identity` for the creators (`brand.collection_links`).

Holds are kept per caller and timed by the caller's sandbox clock, so two accounts that hold the same slot are queued at positions 1 and 2. These products carry hold policies:

| Product | Hold policy |
| - | - |
| `crestline_radio_premium` | Exclusive, 1 to 3 days. A second buyer gets `hold_unavailable` while a hold stands. |
| `streetlevel_premium` | Ranked, 2 to 7 days. While a hold ahead stands, accepting a hold behind it returns `PRODUCT_UNAVAILABLE`. |
| `beacon_search_standard` | Not holdable. A draft that allocates it finalizes as terms only. |
| `trendsettr_premium` | Exclusive, 1 to 3 days, extendable to 10 days in total. |
| `creatorloop_creator_*` | Ranked, 2 to 5 days, extendable to 21 days in total, never past the slot's booking deadline. Each upcoming slot is held separately and listed in `holds`. |

Other products take the default: a hold that never contends.

`tools/list` includes `request_account` and `list_collections` only when the listing is pinned to the preview (`params._meta.adcp_version`, as `@adcp/sdk` sends it).

With `@adcp/sdk`, use 17.0.0-beta.11 or later, which negotiates exactly `3.3-beta.3`. Earlier 17.0.0 betas bundle an older beta, so they settle on 3.2 with the test agent.

> [!WARNING]
>
> **The preview is experimental and can change without notice.** It follows the latest published beta and moves to the next one when it ships. Once it moves, the old pin is no longer served. AAO can also switch the preview off, after which the agent serves only its stable releases. Use it to try 3.3 surfaces, not as a stable integration target.

> [!NOTE]
>
> **No 3.3 verification badge is issued from a beta.** A beta bundle is an implementation input, not a certification target, and prerelease grading runs are diagnostic, as they were for 3.2.

## SDK support contract

An SDK support claim must name all of the following:

* exact SDK package version;
* exact AdCP prerelease bundle used to generate or load schemas;
* supported roles and transports;
* known unsupported or raw-only surfaces;
* install command and one tested validation command.

The SDK compatibility matrix lives in [Choose your SDK](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/building/by-layer/L4/choose-your-sdk.md). Until a row names support for a beta, treat that SDK's generated 3.3 types and validators for it as unavailable. Raw JSON calls may still be possible, but they are not equivalent to SDK support.

SDK maintainers should report protocol ambiguities against the [AdCP repository](https://github.com/adcontextprotocol/adcp/issues). Report SDK implementation bugs in the SDK's own repository. Accepted protocol fixes receive a changeset and ship in the next beta; a published beta is never rebuilt in place.

## SDK guidance

**TypeScript.** Use `@adcp/sdk` **17.0.0-beta.6 or later** (npm `beta` dist-tag) to test 3.3. The published prereleases bundle a signed AdCP release: 17.0.0-beta.6 bundles `3.3.0-beta.1`, 17.0.0-beta.10 bundles `3.3.0-beta.2`, and 17.0.0-beta.11 and later bundle `3.3.0-beta.3`. Each negotiates only its own beta, so a buyer and seller on different betas settle on a stable release. Pin the exact SDK version, and send a prerelease `adcp_version` only to a peer that advertises that exact pin. `@adcp/sdk` 17 is a major release; read its [16 to 17 migration guide](https://github.com/adcontextprotocol/adcp-client/blob/main/docs/migration-16-to-17.md) first.

**Python.** There is no Python SDK release that bundles a 3.3 beta. Support is pending [adcp-client-python#1560](https://github.com/adcontextprotocol/adcp-client-python/issues/1560), which is open. Until it lands, use the `adcp` 3.2 release for production-line work and validate 3.3 behavior over the raw wire against the signed bundle.

**Go.** Check the [adcp-go releases](https://github.com/adcontextprotocol/adcp-go/releases) for a published 3.3 support statement; this page names none.

Do not combine an SDK that bundles an earlier beta with a later wire pin unless that SDK explicitly documents forward compatibility. GA needs SDK support for the latest beta, so these versions will move; [Choose your SDK](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/building/by-layer/L4/choose-your-sdk.md) is the SDK matrix, and it can lag the npm dist-tag.

## SDK convergence

A beta is the SDK-backed ecosystem checkpoint only when:

* every first-party SDK's support for it is marked supported, partial, or unavailable with an exact package version;
* accepted protocol feedback from the previous beta is merged;
* the integration scenarios below have run against the previous beta and identify any correction in the candidate;
* copy/paste installation and validation commands have been executed as published;
* the cumulative migration guide and release notes describe any correction that requires adopter action.

After a beta is published, SDK maintainers ingest that signed bundle and publish an exact support statement or an explicit unsupported or partial result. Only after the matching buyer and seller scenarios pass is that beta the SDK-backed checkpoint.

## Withdrawn after beta.1

Three features shipped in `3.3.0-beta.1` and are not part of 3.3. They leave the protocol after beta.1. All three add terms to `commercial_terms`, which stays closed within 3.x so that a buyer is never bound by terms it cannot read ([adcp#8501](https://github.com/adcontextprotocol/adcp/issues/8501)). They are planned for 4.0, where `commercial_terms` gets a declared extension point with must-understand.

| Feature | Shipped in | Action |
| - | - | - |
| Definition pins: `commercial_terms.definition_pins[]`, the `definition_changed` reason, `drifted_pins[]`, `REFERENCE_DEFINITION_CHANGED`, the `definition_pin_probe` scenario, and the `definition_pin_drift` storyboard ([#7960](https://github.com/adcontextprotocol/adcp/pull/7960)) | beta.0 and beta.1 | Stop emitting and requiring them. A seller that emits pins to a peer on the later schema sends a field a closed `commercial_terms` rejects. The beta rule that sellers pin covered definitions no longer applies. |
| Purchase rights (`media_buy.purchase_rights`): `purchases[].rights[]`, `brand/rights-scope.json`, and the `paid_amplification` and `content_reuse` values of `right-use` ([#8101](https://github.com/adcontextprotocol/adcp/pull/8101)) | beta.1 | Stop listing the feature id and emitting `rights[]`. Carry rights through `acquire_rights` until 4.0. |
| Installment selection (`media_buy.installment_selection`): `purchases[].installments[]` and `refine_proposals` `installment_changes` ([#8246](https://github.com/adcontextprotocol/adcp/pull/8246)) | beta.1 | Stop listing the feature id and emitting or accepting the fields. Installments on the canonical product and `holds[]` stay. |

The [migration guide](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/migration/3-2-to-3-3.md#withdrawn-from-3-3-planned-for-4-0) lists every surface removed, and [Planned for 4.0](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/migration/v4-compatibility.md#planned-for-4-0-withdrawn-from-3-3) keeps the designs.

## Required integration evidence

Retain the exact protocol bundle, SDK package versions, capability responses, redacted requests and responses, task IDs, and account and MediaBuy identifiers for each run.

1. **Account lifecycle.** Call a discovery task (`get_products` or `list_products`) with a buyer-declared natural key that was never provisioned. The seller returns `ACCOUNT_NOT_FOUND` (a seller that provisions lazily instead of exposing `sync_accounts` may answer without creating the account), and `list_accounts` shows no new account. Then provision, with `sync_accounts` or the seller's lazy path on a provisioning task, and repeat the read.
2. **Signed traffic.** Send a signed request and receive a signed webhook between two agents that publish `identity.brand_json_url`. Confirm agent resolution by canonical URL, and that a pinned key missing from the agent's JWKS is rejected. Against a seller that lists an operation in `required_for` and `a2a_invocation_skill` in `request_signing.operation_sources`, confirm an unsigned A2A call to that operation is rejected. A 3.3 seller that lists the operation in `required_for` without the marker must reject it too; the marker advertises enforcement, it does not enable it.
3. **Catalog intake.** For a seller that declares `media_buy.features.catalog_ingestion`, confirm `sync_catalogs` rejects an unlisted catalog type, mode, or feed format, and an explicit `content_id_type` outside a declared `supported_content_id_types`, with `UNSUPPORTED_FEATURE` before mutation, including on a dry run, and reports one `item_issues` entry per item on terminal results and discovery reads under `per_item` reporting.
4. **Delivery webhooks.** Register a `reporting_webhook` with an `operation_id` and confirm every `media_buy_delivery` webhook echoes it verbatim. Register one without it and confirm the seller sends no delivery webhooks to it.
5. **End to end.** Run one buyer and seller lifecycle through purchase, creative assignment, and a delivery readback.

## What may still change

The [3.3.0 milestone](https://github.com/adcontextprotocol/adcp/milestone/10) is the live scope record for work that may still land during the beta cycle. Use these maintained GitHub views as the live record:

* [Open 3.3 issues](https://github.com/adcontextprotocol/adcp/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.3.0)
* [Open 3.3 pull requests](https://github.com/adcontextprotocol/adcp/pulls?q=is%3Aopen+milestone%3A3.3.0)
* [Closed 3.3 milestone work](https://github.com/adcontextprotocol/adcp/milestone/10?closed=1)

Milestone assignment means **candidate for the 3.3 line**, not a commitment to any particular beta or GA. A change is included in a beta only when it is merged before that beta's tag. Items may be deferred, split, or moved to a later release as working groups resolve scope and interoperability risk.

### In review for 3.3

> [!NOTE]
>
> **These are proposals, not features.** Each row is an issue that was open in the 3.3.0 milestone on 2026-10-31 (28 issues, not counting the [GA tracking issue](https://github.com/adcontextprotocol/adcp/issues/8600)), with its open pull request where one exists. An issue stays open while part of it is still in review, so a row can list merged work. Issues whose work has fully merged have been closed and are not listed; see [What's new](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/whats-new-in-3-3.md) and the [release notes](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/release-notes.md#version-3-3-0) for what they shipped. None is part of a beta unless it merges before that beta's tag. "Merged so far" names the slice that already shipped on `main`; the rest of the issue is still in review. The live lists are the [open 3.3 issues](https://github.com/adcontextprotocol/adcp/issues?q=is%3Aopen+is%3Aissue+milestone%3A3.3.0) and [open pull requests](https://github.com/adcontextprotocol/adcp/pulls?q=is%3Aopen+is%3Apr+draft%3Afalse) and [drafts](https://github.com/adcontextprotocol/adcp/pulls?q=is%3Aopen+is%3Apr+draft%3Atrue).

#### Decisions

| Decision | What it changes | Status |
| - | - | - |
| Agent identity is an origin ([DR-0023](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0023-agent-identity-is-an-origin.md)) | Agents are identified by origin and sign HTTP requests and webhooks with the Web Bot Auth profile; the RFC 9421 brand.json profile is deprecated in 3.3 and removed in 4.0. | Merged: [Web Bot Auth profile](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/building/by-layer/L1/wba-profile.md) [#7894](https://github.com/adcontextprotocol/adcp/pull/7894), Web Bot Auth identities and RFC 9421 deprecation [#8162](https://github.com/adcontextprotocol/adcp/pull/8162), first-contact binding [#8168](https://github.com/adcontextprotocol/adcp/pull/8168), walkthrough and migration [#8172](https://github.com/adcontextprotocol/adcp/pull/8172), R7/R8 erratum [#8219](https://github.com/adcontextprotocol/adcp/pull/8219), experimental production security profile [#8155](https://github.com/adcontextprotocol/adcp/pull/8155), onboarding posture [#8170](https://github.com/adcontextprotocol/adcp/pull/8170). `request_account` and pending-action naming [#8293](https://github.com/adcontextprotocol/adcp/pull/8293); single account write and reporting subscriptions [#8551](https://github.com/adcontextprotocol/adcp/pull/8551), [#8552](https://github.com/adcontextprotocol/adcp/pull/8552). |
| Responses conform to the served release ([DR-0024](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0024-responses-conform-to-served-release.md)) | Every response validates against the release the seller served, including `get_adcp_capabilities` and webhook payloads. See [Serving an older pin](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/versioning.md#serving-an-older-pin). | Merged: [#8117](https://github.com/adcontextprotocol/adcp/pull/8117). Grading is open in [#8156](https://github.com/adcontextprotocol/adcp/pull/8156). |
| Demand-side grants ([DR-0025](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0025-demand-side-grants-in-trust-json.md)) | An operator declares in trust.json which agents may act for it, and sellers report `grant_absent`. | Merged: [#8157](https://github.com/adcontextprotocol/adcp/pull/8157), [#8169](https://github.com/adcontextprotocol/adcp/pull/8169). |
| JWS artifacts use the Web Bot Auth key directory ([DR-0026](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0026-jws-artifacts-use-the-wba-key-directory.md)) | Governance contexts, designated-task response signatures, and rights attestations from an origin its trust record lists verify against that origin's Web Bot Auth key directory in 3.3; amends DR-0023. | Merged: [#8299](https://github.com/adcontextprotocol/adcp/pull/8299). |
| Seller revisions advance on every committed change ([DR-0031](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0031-seller-revision-any-origin.md)) | A seller-maintained revision (media-buy and account `revision`, creative `seller_revision`) advances on every committed change, whatever its origin; the `sync_creatives` assignment carve-out is removed. Other resource families are deferred to 3.4. | Merged: [#8159](https://github.com/adcontextprotocol/adcp/pull/8159); recorded in [#8389](https://github.com/adcontextprotocol/adcp/pull/8389). |
| A major-only request is served the oldest supported release ([DR-0034](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0034-major-only-requests-are-served-the-oldest-release.md)) | A request that carries `adcp_major_version` and no `adcp_version` is served the oldest release the seller supports in that major, 3.0 where supported, and the response echoes it. `adcp_major_version` is removed in 4.0 ([DR-0035](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0035-adcp-major-version-removed-in-4-0.md)). | Accepted 2026-10-26; ratified in [#8410](https://github.com/adcontextprotocol/adcp/pull/8410). |
| Closed schemas stay closed within a major ([DR-0036](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0036-closed-schemas-stay-closed-within-a-major.md)) | A minor adds only to open schemas, and four recorded corrections are the only exceptions. This is why definition pins, purchase rights, and installment selection are [withdrawn](#withdrawn-after-beta-1). | Proposed, awaiting ratification. The corrections merged in [#8531](https://github.com/adcontextprotocol/adcp/pull/8531) and [#8547](https://github.com/adcontextprotocol/adcp/pull/8547), and the CI guard in [#8502](https://github.com/adcontextprotocol/adcp/pull/8502). |

Four records document surfaces merged for beta.0 and are accepted (decided 2026-10-30): [DR-0027](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0027-mutation-outcome-on-error.md) (`error.mutation_outcome`), [DR-0028](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0028-sales-fixed-rate-specialism.md) (`sales-fixed-rate`), [DR-0029](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0029-delivery-projection-advisory.md) (delivery projection), and [DR-0030](https://github.com/adcontextprotocol/adcp/blob/main/governance/decisions/DR-0030-media-buy-lineage-forward-only.md) (media-buy lineage).

#### Open 3.3.0 milestone issues

| Area | Issue | Topic | Open PR | Merged so far |
| - | - | - | - | - |
| Commercial flow | [#7902](https://github.com/adcontextprotocol/adcp/issues/7902) | Core `opportunity` on `get_products` | [#8034](https://github.com/adcontextprotocol/adcp/pull/8034) (draft) | — |
| Commercial flow | [#8010](https://github.com/adcontextprotocol/adcp/issues/8010) | Booking rounds for scheduled media | [#8022](https://github.com/adcontextprotocol/adcp/pull/8022) (draft) | `expected_confirmation_at` (#8016) |
| Commercial flow | [#5673](https://github.com/adcontextprotocol/adcp/issues/5673) | Best-first ordering of products and proposals | [#8037](https://github.com/adcontextprotocol/adcp/pull/8037) (draft) | — |
| Commercial flow | [#7852](https://github.com/adcontextprotocol/adcp/issues/7852) | Delivery-mode-aware media-buy baseline | [#7973](https://github.com/adcontextprotocol/adcp/pull/7973) (draft) | — |
| Commercial flow | [#6810](https://github.com/adcontextprotocol/adcp/issues/6810) | Complete account change visibility across seller-managed state | — | `idempotency_key` echo and required `changed_paths` on change records (#8160) |
| Delivery and measurement | [#8543](https://github.com/adcontextprotocol/adcp/issues/8543) | Reporting subscriptions on the principal | — | `request_account` as the single account write (#8551); experimental `reporting_subscriptions` on `sync_principal` and exceptions-only `subscription_coverage` (#8552); beta.2 and beta.3 convergence (#8585, #8588, #8593, #8596, #8607, #8613, #8616, #8617, #8618, #8619, #8621, #8622) |
| Delivery and measurement | [#5683](https://github.com/adcontextprotocol/adcp/issues/5683) | Linear TV preemption notice and replacement offer | — | Report-time spot lifecycle (#8017); the offer-and-accept loop as experimental seller offers (#8102); contract-time preemption criteria planned for 3.4 |
| Delivery and measurement | [#8009](https://github.com/adcontextprotocol/adcp/issues/8009) | Book and report position in break | — | Reporting half (#8017) |
| Delivery and measurement | [#7777](https://github.com/adcontextprotocol/adcp/issues/7777) | Delivery evidence gaps for scheduled and offline channels | — | `change_cutoff` (#8054) |
| Delivery and measurement | [#6878](https://github.com/adcontextprotocol/adcp/issues/6878) | Seller-initiated trackers and measurement sources | — | Experimental `collection-mechanism` vocabulary, `counting_mechanisms[]`, and `vendor_metric_provenance[]` (#7940); seller-initiated trackers and `impression_id` joinability remain open |
| Delivery and measurement | [#6628](https://github.com/adcontextprotocol/adcp/issues/6628) | Reporting metric coherence findings | — | Flat totals omitted for multi-qualifier metrics (#8055) |
| Delivery and measurement | [#7253](https://github.com/adcontextprotocol/adcp/issues/7253) | DOOH impression basis: typed tier, effective multiplier, and derivation link | — | — |
| Security and signing | [#7812](https://github.com/adcontextprotocol/adcp/issues/7812) | `error.mutation_outcome` on failed mutations | — | `mutation_outcome` on `core/error.json` (#7935) |
| Security and signing | [#7577](https://github.com/adcontextprotocol/adcp/issues/7577) | Checklist step position grading | — | — |
| Targeting and inventory | [#8375](https://github.com/adcontextprotocol/adcp/issues/8375) | Supported match keys in capabilities and `Product.identity` | [#8446](https://github.com/adcontextprotocol/adcp/pull/8446) (draft) | — |
| Targeting and inventory | [#8450](https://github.com/adcontextprotocol/adcp/issues/8450) | `required_match_keys` filter on `get_products` for cross-publisher cap planning | — (follow-up to draft [#8446](https://github.com/adcontextprotocol/adcp/pull/8446)) | — |
| Targeting and inventory | [#8451](https://github.com/adcontextprotocol/adcp/issues/8451) | Conformance coverage for match keys before graduating `media_buy.match_keys` | — (follow-up to draft [#8446](https://github.com/adcontextprotocol/adcp/pull/8446)) | — |
| Creative and brand | [#8107](https://github.com/adcontextprotocol/adcp/issues/8107) | `3gp`, `mpeg`, and `m4v` video containers | — | — |
| Creative and brand | [#8092](https://github.com/adcontextprotocol/adcp/issues/8092) | Creator and show cards on collections | — | Collection cards, follower counts, response collections, and `list_collections` (#8094, #8098, #8141, #8279) |
| Signals, audiences, catalogs | [#8023](https://github.com/adcontextprotocol/adcp/issues/8023) | Audience overlap read | [#8031](https://github.com/adcontextprotocol/adcp/pull/8031) (draft) | Audience size ranges (#8024) |
| Signals, audiences, catalogs | [#6872](https://github.com/adcontextprotocol/adcp/issues/6872) | `uids[].value` shape per type | — | Wire form documented (#8059) |
| Conformance and governance | [#7068](https://github.com/adcontextprotocol/adcp/issues/7068) | Machine-observed implementation matrix | [#8040](https://github.com/adcontextprotocol/adcp/pull/8040) (draft) | — |
| Conformance and governance | [#3959](https://github.com/adcontextprotocol/adcp/issues/3959) | Governance framework mapping | [#8035](https://github.com/adcontextprotocol/adcp/pull/8035) (draft) | — |
| Conformance and governance | [#8093](https://github.com/adcontextprotocol/adcp/issues/8093) | Creator marketplace training fixtures | — | CreatorLoop seller and proposal fixtures (#8106) |
| Conformance and governance | [#8182](https://github.com/adcontextprotocol/adcp/issues/8182) | `hold_policy` and `extend_hold` storyboards and controller scenario | — | `force_hold_unavailable` controller scenario and hold-policy vector gaps (#8214); storyboards still open |
| Conformance and governance | [#8201](https://github.com/adcontextprotocol/adcp/issues/8201) | 3.2 compact proposal storyboards and `sales-dooh` opt into fixture resolution | — | `olv` channel match for `outdoor_video_auction` discovery (#8211) |
| Conformance and governance | [#8181](https://github.com/adcontextprotocol/adcp/issues/8181) | Training agent serves the experimental 3.3 hold-policy, `extend_hold`, and response-collection surfaces | — | — |
| Conformance and governance | [#8398](https://github.com/adcontextprotocol/adcp/issues/8398) | URL validation is over-specified: eight patterns where `^https://` is enough | — | `setup_url` pattern relaxed to `^https://` with `format: uri` (#8548) |

Also open, without a 3.3 milestone issue: [#7958](https://github.com/adcontextprotocol/adcp/pull/7958) composable delivery breakdowns and [#7957](https://github.com/adcontextprotocol/adcp/pull/7957) metric aggregation semantics (both drafts; their issues moved to 3.4.0), [#7446](https://github.com/adcontextprotocol/adcp/pull/7446) TMP Context Match cache isolation (on the 3.3.0 milestone), and [#8346](https://github.com/adcontextprotocol/adcp/pull/8346) signed creative addons (open; asks the working group to reconsider a 3.4 deferral, and WG approval is pending).

## Known beta boundaries

* Experimental surfaces retain their [experimental-status contract](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/experimental-status.md). A 3.3 beta does not graduate them to stable. The surfaces new in 3.3 are listed in the [release notes](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/release-notes.md#experimental-surfaces-in-3-3).
* The `3.3-beta` documentation selector moves forward; pinned semver artifacts and documentation snapshots remain immutable.
* Stable schema aliases continue to resolve to stable releases during beta. Use pinned prerelease URLs when validating beta behavior.
* The `media_buy_seller/unprovisioned_account_reference` storyboard is advisory until runner capability `14.1.0`.

## Report useful feedback

Include this information in a beta issue:

* protocol artifact version and wire pin;
* SDK name and version, or `raw wire`;
* buyer, seller, creative, signals, brand, measurement, or governance role;
* transport and task name;
* schema path or JSON Pointer involved;
* expected and actual behavior;
* minimal redacted payload and validation error;
* whether the problem blocks interoperability on the beta you tested.

Never include credentials, signed URLs, bearer tokens, private keys, or live customer payloads.

## Related

* [What's new in AdCP 3.3](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/whats-new-in-3-3.md)
* [Migrating from 3.2 to 3.3](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/migration/3-2-to-3-3.md)
* [Release Notes](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/release-notes.md#version-3-3-0)
* [Versions & Compatibility](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/reference/versions.md)
* [Choose your SDK](https://docs.adcontextprotocol.org/dist/docs/3.3.0-beta.4/building/by-layer/L4/choose-your-sdk.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.