docs(reference): curated 3.3.0-beta.3 notes

.changeset/beta3-curated-release-notes.md

@@ -0,0 +1,4 @@
+---
+---
+
+Docs: curated 3.3.0-beta.3 notes in What's new in 3.3 and the beta program page.

docs/reference/3-3-beta.mdx

@@ -171,9 +171,9 @@ Four proposed records document surfaces merged for beta.0 and await working-grou
 | Commercial flow | [#8184](https://github.com/adcontextprotocol/adcp/issues/8184) | Invoice lines on `get_account_financials` tied to billed reporting | [#8207](https://github.com/adcontextprotocol/adcp/pull/8207) (draft) | — |
 | Commercial flow | [#8142](https://github.com/adcontextprotocol/adcp/issues/8142) | Seller revision that advances on every committed change | — | Media-buy, account, and creative seller revisions from any origin (#8159, DR-0031 recorded in #8389); other resource families deferred to 3.4 |
 | 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) |
-| Commercial flow | [#8280](https://github.com/adcontextprotocol/adcp/issues/8280) | `request_account` and one pending-action shape (agent identity P10) | — | `request_account` and the pending action (#8293); `request_account` as the single account write and `list_accounts` request reads (#8551) |
+| Commercial flow | [#8280](https://github.com/adcontextprotocol/adcp/issues/8280) | `request_account` and one pending-action shape (agent identity P10) | — | `request_account` and the pending action (#8293); `request_account` as the single account write and `list_accounts` request reads (#8551); change outcomes and the separate-account opt-in (#8580, #8582); money terms on resolved requests and consistent timezone changes (#8620) |
 | Commercial flow | [#8230](https://github.com/adcontextprotocol/adcp/issues/8230) | Installments on the canonical Product in the proposal lifecycle | [#8246](https://github.com/adcontextprotocol/adcp/pull/8246) | — |
-| Delivery and measurement | [#8543](https://github.com/adcontextprotocol/adcp/issues/8543) | Reporting subscriptions on the principal | — | Experimental `reporting_subscriptions` on `sync_principal` and exceptions-only `subscription_coverage` (#8552) |
+| Delivery and measurement | [#8543](https://github.com/adcontextprotocol/adcp/issues/8543) | Reporting subscriptions on the principal | — | 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 | [#8102](https://github.com/adcontextprotocol/adcp/pull/8102) (draft) | Report-time spot lifecycle (#8017); contract-time half 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) |

docs/reference/whats-new-in-3-3.mdx

@@ -19,6 +19,29 @@ Around that, 3.3 tightens the places where two conformant 3.2 implementations co
 
 No stable field, enum value, or task is removed. Two result fields, one usage, the account identity-rekey machinery, and the RFC 9421 signing profiles are deprecated, all functional throughout 3.x. They are `seller_id` on event source and audience results (use `platform_id`), and the natural key as the account reference after provisioning. They also include `account.identity_updates`, `operator_identity`, `ACCOUNT_MOVED`, `ACCOUNT_IDENTITY_CONFLICT`, and `account.stable_account_id` (use `account_id`), and the RFC 9421 profiles (use the experimental Web Bot Auth profile). 3.3 adds optional fields, enum values, and capability declarations. Schema-valid 3.2 messages stay schema-valid except for the new domain identifier format, and unless they already used a name 3.3 now defines with a different shape; the list is in the [migration guide](/docs/reference/migration/3-2-to-3-3#what-can-fail-validation). The normative narrowings are recorded in [Versioning and governance](/docs/reference/versioning#3-3-exceptions-to-3-x-compatibility-beta) and lead the [migration guide](/docs/reference/migration/3-2-to-3-3#required-to-claim-3-3-behavior).
 
+## New in beta.3
+
+beta.3 finishes the reporting-subscription and account-request surfaces, both experimental, against what the TypeScript and Python SDK implementations found. Coverage is now computable from the wire alone, and canonical coverage vectors with an independent reference model pin it. The account change outcomes and the owed confirmation period first shipped in beta.2; they are summarized here with the rest.
+
+**Account changes ([`request_account`](/docs/accounts/tasks/request_account), `account.requests`).**
+- A change request resolves one of three ways: `updated` on the named account, `matched` to an account the caller already holds, or `created` as a separate account carrying the change. `created` happens only when the buyer opts in with `allow_separate_account: true`; otherwise a seller that would only accept the change on a new account refuses with `ACCOUNT_CHANGE_REQUIRES_NEW_ACCOUNT`.
+- A request that resolves `matched` or `created` now MUST carry `account`, with its `billing`, `billing_entity`, and `payment_terms`, because they can differ from the terms requested. **Adopter action:** sellers that omitted `account` on these resolutions now fail validation ([#8620](https://github.com/adcontextprotocol/adcp/pull/8620)).
+- An `updated` request that changed money terms carries `effective_at`, when the new terms take effect. A `created` separate account lists in `not_carried_over` the account-level configurations it doesn't have.
+- `currency` and `timezone` change through `request_account` only on sellers that list them in `account.requests.changeable_attributes`; otherwise the change is refused with `UNSUPPORTED_FEATURE`.
+
+**Losing authority means losing access ([#8607](https://github.com/adcontextprotocol/adcp/pull/8607)).** After the caller loses authority for an account, every reference to it fails like an unknown identifier, receipts and consumer statuses included. A seller that wants a buyer to finish reconciling, for example after an agency change, keeps a reduced grant listing only the reconciliation tasks instead of revoking. A partial grant that lists `get_reporting_status` but not `sync_reporting_receipts` or `sync_reporting_status` keeps the account covered, and the missing tasks fail with `SCOPE_INSUFFICIENT` ([#8619](https://github.com/adcontextprotocol/adcp/pull/8619)).
+
+**Reporting subscriptions (`media_buy.reporting_subscriptions`).**
+- **Which periods are owed.** A buy owes the period in which it is confirmed, in full ([#8593](https://github.com/adcontextprotocol/adcp/pull/8593)). A deactivated subscription reads `inactive` in `subscription_coverage`, with `deactivated_at`, while its obligations are retained ([#8613](https://github.com/adcontextprotocol/adcp/pull/8613)). The flight's stop time uses the new `cancellation_effective_at`, the delivery stop, so delivery through a cancellation notice period stays owed, and a seller delivers on a buy only inside its flight, extending `end_time` first for a make-good ([#8617](https://github.com/adcontextprotocol/adcp/pull/8617)).
+- **Billing stays contiguous.** When a cutover hands a billing feed to a schedule with no boundary at the handoff, the stretch is owed as one stub obligation (`stub: true`) instead of going unreported. This covers account timezone changes, and it applies to account-level `sync_accounts` billing configurations too ([#8617](https://github.com/adcontextprotocol/adcp/pull/8617)).
+- **Computable from the wire.** `authorization.regranted_at`, a media buy's `flight_history` of retroactive flight edits, each package's `reporting_delivery_offering_ids` fixed at confirmation, and `available_from` / `withdrawn_at` on offerings ([#8618](https://github.com/adcontextprotocol/adcp/pull/8618)).
+- **Deterministic.** Resolution is per package and fixed per buy and version until the resolved offering is withdrawn; a buy owes the union of its packages' offerings. `max_accounts` admission is sticky and ordered by `authorization.authorized_at`, then `account_id` in byte order. Billing subscriptions use `match: exact` with `dimensions` ([#8619](https://github.com/adcontextprotocol/adcp/pull/8619)).
+- **At agency scale.** `destination_overrides[]` routes accounts to other destinations inside one subscription. Adding or removing accounts no longer needs a new `subscription_version`: membership edits apply in place as `excluded_by_buyer` intervals. The readback lists 16 prior versions and 1,000 accounts inline, with totals, and `get_principal` pages the rest through `reporting_subscription_page`. Several pacing or analytics subscriptions may cover one account; billing stays one per account. Managed-delivery row schemas declare `account_id` and key on it ([#8619](https://github.com/adcontextprotocol/adcp/pull/8619)).
+- **Period arithmetic.** A local date's first instant is always a boundary, so `PT24H` equals `P1D` and days nest in sub-daily schedules even where midnight doesn't exist. Two cutovers inside one period and reactivation after a change made while inactive never owe a period twice. `billing_cycle` needs a date component, `P7D` weeks under `utc`, `account_timezone`, and `source_timezone` start on Thursday, `status_retention_days` counts exact 24-hour days, and a `utc` offering matches a `period_timezone` override only when it is exactly `UTC` or `Etc/UTC` ([#8622](https://github.com/adcontextprotocol/adcp/pull/8622)).
+- **Test assets.** Canonical coverage vectors and an independent reference model live in `static/compliance/source/test-vectors/reporting-subscriptions/` ([#8616](https://github.com/adcontextprotocol/adcp/pull/8616)), and `comply_test_controller` adds `reporting_subscription_probe` to drive grants, account timezones, and the clock against a remote seller ([#8621](https://github.com/adcontextprotocol/adcp/pull/8621)).
+
+**Live creative updates (experimental, `creative.live_updates`, [#8488](https://github.com/adcontextprotocol/adcp/pull/8488)).** A buyer changes a serving creative by syncing it again under the same `creative_id`. The seller declares, per kind of change, whether it applies `uninterrupted`, `staged` (the approved version keeps serving until the update is approved), or `paused_for_review`, and refuses the rest with `CREATIVE_LIVE_UPDATE_UNSUPPORTED`. `list_creatives` shows `staged_update`, and the opt-in `creative.staged_update_changed` event tracks it.
+
 ## Scheduled and human-gated buying
 
 - **An account is its account ID.** Sellers MUST return `account_id` from `sync_accounts` once the account is resolved, accept it on every account-scoped task, and never change it. A brand is its domain, plus `brand_id` where its `brand.json` lists several brands. Countries, currency, timezone, sandbox, and `operator_unit` are account attributes that a settings update changes without changing the account. Currency, timezone, and sandbox are set at opening, and a seller can review a countries change before applying it. A seller SHOULD return the existing account when a provisioning entry matches exactly one. Natural keys keep working throughout 3.x, but using them as the reference after provisioning is deprecated and planned for removal in 4.0. They remain the way to open an account and to look up its ID. `account.identity_updates`, `ACCOUNT_MOVED`, `ACCOUNT_IDENTITY_CONFLICT`, and `account.stable_account_id` are deprecated. See [Account identity](/docs/accounts/overview#account-identity).
@@ -156,7 +179,7 @@ from the list as a denial.
 
 The experimental account change feed (`account.change_feed`) gains two changes ahead of graduation. A record whose `origin.kind` is `adcp` can echo the originating request's `idempotency_key`, so a buyer recognizes its own changes on a shared account; the seller includes it only on records served to the principal that sent the request, and every other reader sees the same record without it. And `changed_paths` is now required when `origin.kind` is `adcp` or `seller_operator`, staying best-effort for `seller_system` and `connected_platform`. See [`list_account_changes`](/docs/accounts/tasks/list_account_changes#recognizing-your-own-changes).
 
-## Reporting subscriptions on the principal (experimental, beta.1)
+## Reporting subscriptions on the principal (experimental, beta.1 to beta.3)
 
 Reliable Reporting was configured one account at a time, so a new account reported nothing until someone configured it. `sync_principal` now takes `reporting_subscriptions`: one registration per feed purpose, scoped to `all_authorized_accounts: true` or to named `account_ids`, with a selector that works across sellers (`feed_purpose`, `period_duration`, `required_finality`, optional `dimensions`, and `match`). The buyer can work out coverage without asking: a confirmed buy is owed every complete period that starts on or after the later of the subscription version's `accepted_at` and the account's `authorization.authorized_at`, from the period in which the buy is confirmed through its final period. `get_reporting_status` reports only exceptions under `subscription_coverage`. Exceptions remove periods from what is owed and never add any, so a missing report still means an owed period with nothing delivered. Revoked accounts appear in the subscription readback on `get_principal`, not as silent gaps. A caller's own `sync_accounts` delivery config still wins for that account and feed purpose. Sellers list accepted registration tasks in `reporting_delivery.configuration_tasks[]`. `configuration_task` stays `"sync_accounts"` for older clients and is deprecated. In beta.2, offerings publish `standard_dimensions` so a buyer resolves the selector from the wire, and the readback carries `inactive_intervals`, per-version configuration in `prior_versions`, and per-offering gaps and timezone cutovers. Period arithmetic (civil days, elapsed hours), cutovers across different offerings, and authorization chains on re-grant are now pinned. Feature id `media_buy.reporting_subscriptions`. See [Reporting subscriptions](/docs/protocol/sync_principal#reporting-subscriptions) and [Subscription coverage](/docs/media-buy/task-reference/get_reporting_status#subscription-coverage).
 
@@ -198,6 +221,8 @@ These merged on `main` during the 3.3 cycle and were also released on the 3.2 li
 | A linear TV, print, or DOOH seller | Adopt the delivery fields you can populate; gate 3.3-only rows and fields on the negotiated version. |
 | An SDK maintainer | Generate from the signed beta.0 tarball and check the [SDK-facing changes](/docs/reference/migration/3-2-to-3-3#sdk-and-code-generator-maintainers). |
 | A seller that opens buyer-declared accounts | Return `account_id` from `sync_accounts`, accept it on every account-scoped task, and never change it; update countries and other attributes in place. |
+| A seller supporting `account.requests` | Return `account`, with its money terms, on every request that resolves `matched` or `created`; send `effective_at` on money changes and `not_carried_over` on a separate account; refuse `currency` or `timezone` changes you don't list in `changeable_attributes`. |
+| A seller advertising `media_buy.reporting_subscriptions` | Publish `cancellation_effective_at`, `flight_history`, per-package `reporting_delivery_offering_ids`, `authorization.regranted_at`, and offering `available_from` / `withdrawn_at`; owe billing stubs at cutovers; deliver only inside a buy's flight; key managed-delivery rows on `account_id`. |
 | A buyer that sends natural keys after provisioning | Store the returned `account_id` and send it; natural-key references are deprecated ahead of 4.0. |
 | A seller reporting event source or audience platform IDs | Emit `platform_id` and the deprecated `seller_id` alias with identical values, including discovery responses. |
 | A buyer consuming event source or audience platform IDs | Prefer `platform_id`, fall back to `seller_id` when absent, and keep using buyer object IDs in AdCP requests. |