Instrument AdCP 3.2 across docs, compliance, and training

.changeset/instrument-3-2-surfaces.md

@@ -0,0 +1,5 @@
+---
+"adcontextprotocol": minor
+---
+
+Instrument the AdCP 3.2 beta across the training agent, compliance surface, adopter documentation, and learning system. Targeting-aware product discovery now issues bounded configured-product offers, validates purchase-time narrowing against declared overlay support, preserves proposal acceptance and lifecycle readback, and enforces retry-safe idempotency. Webhook delivery uses durable, scoped request bindings and recoverable outbox snapshots with the SDK 14 beta emitter contract. A release manifest tracks all 16 feature families across documentation, training, compliance, and runtime, with explicit dispositions for deferred candidates.

docs/building/by-layer/L4/choose-your-sdk.mdx

@@ -13,20 +13,20 @@ For the layered model behind this — what each layer contains and what an SDK a
 
 What "shipped" means at each layer is the [L0–L3 checklist](/docs/building/cross-cutting/sdk-stack#what-an-sdk-at-each-layer-should-provide).
 
-*Last updated: 2026-08-20.*
+*Last updated: 2026-08-23.*
 
 | SDK | Current package | 3.2 beta support | L0 | L1 | L2 | L3 |
 |---|---|---|:-:|:-:|:-:|:-:|
-| **`@adcp/sdk`** (TypeScript) | `14.0.0-beta.5` | Exact `3.2.0-beta.4` support | ✅ | ✅ | ✅ | ✅ |
-| **`adcp`** (Python) | `7.0.2` | Pending exact 3.2 support | ✅ | ⚠️ | ⚠️ | ⚠️ |
+| **`@adcp/sdk`** (TypeScript) | `14.0.0-beta.7` | Exact `3.2.0-beta.5` support | ✅ | ✅ | ✅ | ✅ |
+| **`adcp`** (Python) | `8.0.0b7` | Exact `3.2.0-beta.5` schemas and types; higher-level helpers remain partial | ✅ | ⚠️ | ⚠️ | ⚠️ |
 | **`adcp/v3`** (Go) | `v3.0.0` | Pending exact 3.2 support | ⚠️ | ⚠️ | ⚠️ | ⚠️ |
 
 Legend: ✅ shipped · ⚠️ partial / role-dependent · ❌ not yet covered. The L0–L3 columns describe the current package, not a 3.2 support claim.
 
 <Warning>
-**3.2 packages are prereleases.** The TypeScript beta supports the exact beta.4
-protocol checkpoint; it does not imply compatibility with a later beta.
-Python and Go have not published exact 3.2 support statements yet. See the
+**3.2 packages are prereleases.** The TypeScript and Python betas support the
+exact beta.5 protocol checkpoint; that does not imply compatibility with a
+later beta. Go has not published an exact 3.2 support statement yet. See the
 [3.2 beta program](/docs/reference/3-2-beta).
 </Warning>
 
@@ -49,7 +49,7 @@ and the [Slack community](/docs/community/joining-slack).
 [![npm version](https://img.shields.io/npm/v/@adcp/sdk)](https://www.npmjs.com/package/@adcp/sdk)
 
 ```bash
-npm install @adcp/sdk@14.0.0-beta.5
+npm install @adcp/sdk@14.0.0-beta.7
 ```
 
 ```javascript
@@ -63,7 +63,7 @@ const client = createSingleAgentClient({
 });
 
 const products = await client.listProducts({
-  adcp_version: '3.2-beta.4',
+  adcp_version: '3.2-beta.5',
   account: { account_id: 'account_123' },
   criteria: {
     offer_filters: { channels: ['ctv'] },
@@ -100,7 +100,7 @@ integrations should use the main server and per-tool type exports.
 [![PyPI version](https://img.shields.io/pypi/v/adcp)](https://pypi.org/project/adcp/)
 
 ```bash
-pip install adcp
+pip install adcp==8.0.0b7
 ```
 
 ```python
@@ -158,11 +158,11 @@ Both SDKs share the same positional shape: `adcp <agent> [tool] [payload]`. The
 ### JavaScript CLI
 
 ```bash
-npx @adcp/sdk@14.0.0-beta.5 --help
-npx @adcp/sdk@14.0.0-beta.5 --save-auth my-agent https://sales.example.com/mcp
-npx @adcp/sdk@14.0.0-beta.5 my-agent list_products '{"adcp_version":"3.2-beta.4","account":{"account_id":"account_123"}}'
+npx @adcp/sdk@14.0.0-beta.7 --help
+npx @adcp/sdk@14.0.0-beta.7 --save-auth my-agent https://sales.example.com/mcp
+npx @adcp/sdk@14.0.0-beta.7 my-agent list_products '{"adcp_version":"3.2-beta.5","account":{"account_id":"account_123"}}'
 # or against the built-in public test agent:
-npx @adcp/sdk@14.0.0-beta.5 test-mcp list_products '{"adcp_version":"3.2-beta.4"}'
+npx @adcp/sdk@14.0.0-beta.7 test-mcp list_products '{"adcp_version":"3.2-beta.5"}'
 ```
 
 The CLI also drives storyboards (`adcp storyboard run`), conformance grading (`adcp grade`), and registry diagnostics. See `--help` for the full surface.

docs/learning/foundations/a2b-testing-your-first-agent.mdx

@@ -72,12 +72,12 @@ Use these as a quick reference while working through the module with Addie, or t
 Call `get_products` with `buying_mode: "brief"` and a plain-English description of your campaign goals. The agent returns curated `products[]` and ready-to-execute `proposals[]`.
 
 <Note>
-This public training-agent lab continues to use the pre-3.2 brief flow. The 3.2
-structured discovery exercise will be enabled only after the beta SDKs and
-training runtime implement targeting-aware discovery; follow
-[issue #6199](https://github.com/adcontextprotocol/adcp/issues/6199). Until
-then, do not use this sandbox to test `get_products.targeting_overlay` or
-`required_overlay_support`, because the live runtime does not enforce them.
+This foundation lab intentionally uses the `get_products` compatibility facade
+so first-time learners can focus on the four-call lifecycle. The same public
+seller also supports compact 3.2 targeting-aware discovery. After this module,
+use the [buyer briefs supplement](/docs/learning/supplements/buyer-briefs-and-get-products)
+to practice `list_products`, `request_proposals`, and effective targeting
+readback with the pinned beta wire and SDK.
 </Note>
 
 ```bash

docs/learning/instructional-design.mdx

@@ -157,7 +157,7 @@ AdCP is a living protocol. When the specification evolves — new tasks added, e
 
 Each required demonstration is tracked by a stable ID tied to specific protocol knowledge. When a protocol change affects what a certified person should know, the system can identify which credential holders learned under the previous criteria and flag them for recertification.
 
-Recertification is targeted, not blanket. If a protocol update adds a new governance task but doesn't affect media buy workflows, only credentials that cover governance are flagged. Credential holders receive a notification through Addie with context on what changed and what they need to review. The decision process, delta-assessment rules, and AdCP 3.1 S2 canonical formats rationale are documented in the [recertification policy](/docs/learning/policies/recertification).
+Recertification is targeted, not blanket. If a protocol update adds a new governance task but doesn't affect media buy workflows, only credentials that cover governance are flagged. Credential holders receive a notification through Addie with context on what changed and what they need to review. The decision process, delta-assessment rules, and recorded AdCP 3.1 and 3.2 decisions are documented in the [recertification policy](/docs/learning/policies/recertification).
 
 | Tier | Validity | Recertification |
 |------|----------|-----------------|

docs/learning/policies/recertification.mdx

@@ -1,7 +1,7 @@
 ---
 title: Recertification and protocol-change updates
 sidebarTitle: Recertification
-description: "AdCP certification recertification policy: targeted protocol-change updates, delta assessments, learner notifications, and the AdCP 3.1 canonical formats S2 rationale."
+description: "AdCP certification recertification policy: targeted protocol-change updates, delta assessments, learner notifications, and recorded AdCP 3.1 and 3.2 decisions."
 "og:title": "AdCP - Recertification and protocol-change updates"
 ---
 
@@ -18,7 +18,8 @@ This policy is IACET-aligned and CPD-aligned. It is not an assertion of current
 
 AdCP credentials are tied to protocol competency. When the protocol changes, the certification program determines whether existing credential holders need no action, a targeted delta assessment, or full recertification.
 
-This policy documents that decision process and records the AdCP 3.1 canonical formats rationale for pre-3.1 S2 Creative specialist holders.
+This policy documents that decision process and records the AdCP 3.1 canonical
+formats rationale and the AdCP 3.2 specialist-credential decision.
 
 ## Decision levels
 
@@ -107,6 +108,59 @@ Learners are assigned full S2 recertification instead of the delta when:
 
 The delta-only window is 90 days after `delta_window_opens_at`. During that window, affected credential holders keep their S2 credential but are marked as requiring a protocol update. After the window closes, unresolved holders retain their historical S2 completion record, but their learner-facing S2 status is no longer current until they complete the current S2 module. Learner-facing messages must include the computed absolute deadline date.
 
+## AdCP 3.2 specialist decision
+
+AdCP 3.2 adds bounded competencies to three specialist credentials without
+invalidating their prior evidence. The recorded decision is therefore a
+**targeted delta assessment** for pre-3.2 holders of S1 Media Buy, S2 Creative,
+and S6 Security—not full recertification. No 3.2 learner targeting, notification,
+or credential-status change may occur during beta.
+
+Migration `550_curriculum_3_2_criteria.sql` adds stable evidence handles to the
+current module definitions so beta-path learners can demonstrate the new wire
+behavior. That curriculum instrumentation is not, by itself, a release gate or
+authorization to target prior credential holders. Evidence recorded during beta
+is provisional until program leadership maps it to the final GA artifact.
+
+| Credential | New criterion IDs | Decision rationale |
+|---|---|---|
+| S1 Media Buy | `s1_ex1_sc_compact_media_buy_lifecycle`, `s1_ex1_sc_targeting_aware_discovery`, `s1_ex1_sc_availability_and_outcome_planning` | Compact lifecycle, targeting resolution, and planning inputs extend prior discovery, proposal, purchase, and optimization evidence. |
+| S2 Creative | `s2_ex1_sc_pixel_density_and_renditions`, `s2_ex1_sc_vast_accessibility_provenance` | Pixel-density, rendition, validation, accessibility, and provenance rules narrow prior format-authoring and validation competencies. |
+| S6 Security | `s6_ex2_sc_3_2_signed_body_integrity`, `s6_ex4_sc_webhook_delivery_identity` | Body binding and binary encoding extend request-signing evidence; separating echoed `operation_id` correlation from payload `idempotency_key` deduplication extends webhook-security evidence. |
+
+For each credential, `criteria_effective_at` is the later of AdCP 3.2.0 GA and
+production deployment of `550_curriculum_3_2_criteria.sql` with the applicable
+assessment path available. `delta_window_opens_at` equals that effective point;
+`delta_window_closes_at` is 90 calendar days later at 23:59 UTC. The auditable
+record requirement is a pre-effective-date completion record for the affected
+module plus a criterion/checkpoint trail sufficient to verify its prior required
+demonstrations. A holder whose record already includes every applicable 3.2
+criterion requires no action.
+
+Assign the current full module instead of the delta when the prior record is
+missing or cannot be mapped, the learner misses the delta window, or later GA
+changes materially invalidate the beta-era mapping above. Program leadership
+must re-review this decision against the final 3.2.0 artifact before opening the
+window; if GA changes a listed competency, update the criterion and rationale
+before targeting learners.
+
+### GA activation gate
+
+The 3.2 delta is recorded but inactive during beta. Before anyone sets a 3.2
+criteria deployment timestamp or targets an existing holder, engineering and
+program leadership must verify all of the following:
+
+- the final 3.2.0 artifact still maps to the criterion IDs above;
+- each affected module has a registered delta definition and independently
+  configurable release gate—one module's window must not activate another;
+- Addie can present only the missing criteria, save criterion-level evidence,
+  and route an unmappable or late record to the full current module;
+- automated tests cover pre-GA suppression, the later-of-GA-and-deployment
+  boundary, the 90-day UTC deadline, already-complete evidence, missing records,
+  and the post-window full-recertification path; and
+- learner notification copy contains the affected credential, exact required
+  demonstrations, absolute deadline, support contact, and appeal path.
+
 ## CPD and accreditation disclosure
 
 Recommended disclosure for continuing professional development records:
@@ -131,7 +185,7 @@ Email notification:
 >
 > Complete the delta by `<computed deadline date>` to keep your credential current. After that window, the current S2 module is required for renewal. If you believe you were targeted in error, email certification@agenticadvertising.org; we acknowledge assessment and targeting review requests within 2 business days and resolve them through the complaints process.
 
-## Implementation gates
+## AdCP 3.1 implementation gates
 
 Engineering must not enable learner targeting or send learner notifications until all of the following are true:
 

docs/learning/specialist/creative.mdx

@@ -37,7 +37,8 @@ The following `specialisms` fall under the `creative` domain. Each has its own c
 - Understand creative agent pricing: the `pricing_options[]` array on discovery responses, how `pricing_option_id` flows through `build_creative` and `report_usage`, and why CPM ad servers show zero `vendor_cost` at build time while transformation agents do not
 - Reason about tracker-slot presence — a format supports third-party measurement only if its `assets` array declares a tracker slot (e.g., `impression_tracker`). Broadcast formats intentionally omit tracker slots; measurement comes from panel and STB data via `billing_measurement`
 - Attach `industry_identifiers[]` to broadcast manifests with the correct `creative-identifier-type` (`ad_id`, `isci`, `clearcast_clock`, or `idcrea`), and give each cut (`:15` vs `:30`) its own traffic identifier
-- Reason about format edge cases, accessibility, and provenance
+- Validate logical image dimensions independently from intrinsic pixels and distinguish accepted `pixel_ratios` from a required rendition set
+- Apply the seller's advertised VAST validation level, supply format-required accessibility detail, and distinguish buyer-declared provenance from independently verified evidence
 
 ## Prerequisite reading
 
@@ -197,15 +198,17 @@ Vendors often offer multiple pricing options per creative — volume/commitment
 10. **Preview modes** — Run `preview_creative` as `request_type: "single"`, then `"batch"` (submit 5 creatives in one call and measure the speedup), then `"variant"` against a prior `get_creative_delivery` result. Compare `output_format: "url"` vs `"html"` for rendering latency.
 11. **Tracker-slot audit** — For each sandbox format, inspect the `assets` array and determine whether it supports third-party measurement. Explain why assigning a DoubleVerify pixel to a broadcast spot won't work, and which `billing_measurement` vendor would instead.
 12. **Broadcast identifiers** — Build a broadcast manifest with distinct `industry_identifiers[]` for `:15` and `:30` cuts of the same spot. Verify the `creative-identifier-type` values and explain why each cut needs its own traffic identifier.
+13. **Pixel density and rendition coverage** — Validate the canonical image reference vectors at 1x and 2x. Show that a 600×500 asset can satisfy a logical 300×250 slot at 2x without creating a new logical placement; trigger `pixel_ratio_ambiguous` on an ambiguous undeclared density; then satisfy `required_pixel_ratios: [1, 2]` with exactly one valid rendition at each required density. Explain why accepted densities do not require every density unless `required_pixel_ratios` says so.
+14. **VAST, accessibility, and provenance** — Read `creative_specs.vast_validation` before syncing one structurally valid but document-invalid VAST asset and predict whether the seller may return `VAST_PARSE_FAILED`. For a format with `accessibility.requires_accessible_assets: true`, submit the applicable alt text, captions, or transcript and interpret a structured accessibility violation. Finally submit synthetic creative metadata that declares `synthetic_depiction` and provenance evidence; distinguish a declaration from an independent verifier result and do not treat unverified metadata as an attestation.
 
 ## Assessment
 
 | Dimension | Weight | What Addie evaluates |
 |-----------|--------|---------------------|
 | Interaction models | 20% | Correctly identifies and works with all three creative agent types |
-| Cross-platform adaptation | 15% | Adapts creatives across display, video, native, preview, measurement, and broadcast workflows |
+| Cross-platform adaptation | 15% | Adapts creatives across display, video, native, preview, measurement, broadcast, and density-aware rendition workflows |
 | Canonical formats | 10% | Reads `format_options[]`, selects `format_kind` and `format_option_id`, explains single-option, multi-option, and `v1_format_ref[]` fan-out cardinality, maps `asset_source` values to buyer-provided, agent-synthesized, seller-rendered, seller-designed, and publisher-hosted workflows, and explains canonical-first/product-second validation order |
-| Compliance | 25% | Configures disclosures, provenance, and regulatory requirements |
+| Compliance | 25% | Applies advertised VAST validation, configures accessibility and disclosures, and distinguishes provenance declarations from verified evidence |
 | Pricing and accounts | 15% | Understands rate cards, reads pricing from `list_creatives` and `list_transformers`, interprets build costs, closes the `report_usage` loop |
 | Analytical skill | 15% | Interprets creative feature evaluation and delivery results |