From cb6cd5ac9db3c749ce964de584d6129c2d8e6714 Mon Sep 17 00:00:00 2001 From: Brian O'Kelley Date: Sat, 2 May 2026 12:26:55 -0400 Subject: [PATCH 1/3] =?UTF-8?q?spec(specialisms):=20deprecate=20sales-prop?= =?UTF-8?q?osal-mode=20=E2=86=92=20sales-guaranteed=20(refs=20#3823)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proposal mode is how guaranteed deals get sold: RFP → proposal → review → finalize → IO → live. Auction-based sales don't have proposals; they're bid-by-bid. Today sales-proposal-mode (proposals + briefs) and sales-guaranteed (IO + guaranteed) are halves of one flow, forcing sellers to declare both or pick wrong. Following the signed-requests precedent (deprecated in 3.1, retained until 4.0): - Add sales-proposal-mode to x-deprecated-enum-values in specialism.json - Update enumDescriptions[sales-proposal-mode] with the deprecation note + migration path (declare sales-guaranteed; proposal_finalize scenario remains accessible regardless of which specialism is declared) - Banner the storyboard at specialisms/sales-proposal-mode/index.yaml with the deprecation announcement Storyboard bundle and enum value retained through 3.x for backward compat — existing sellers continue to grade without any wire break. New sellers should declare sales-guaranteed. Hard removal at 4.0. Migration: replace `sales-proposal-mode` with `sales-guaranteed` in get_adcp_capabilities.specialisms[] (or declare both during the transition window). proposal_finalize scenario unchanged at protocols/media-buy/scenarios/proposal_finalize.yaml — sellers still grade against it through whichever parent specialism they declare. --- .changeset/deprecate-sales-proposal-mode.md | 17 +++++++++++++++++ .../specialisms/sales-proposal-mode/index.yaml | 7 +++++++ static/schemas/source/enums/specialism.json | 5 +++-- 3 files changed, 27 insertions(+), 2 deletions(-) create mode 100644 .changeset/deprecate-sales-proposal-mode.md diff --git a/.changeset/deprecate-sales-proposal-mode.md b/.changeset/deprecate-sales-proposal-mode.md new file mode 100644 index 0000000000..7afbdad9e4 --- /dev/null +++ b/.changeset/deprecate-sales-proposal-mode.md @@ -0,0 +1,17 @@ +--- +"adcontextprotocol": minor +--- + +spec(specialisms): deprecate sales-proposal-mode — proposal-driven flows merge into sales-guaranteed (refs #3823 item 4) + +Proposal mode is how guaranteed deals get sold in practice — RFP → proposal → review → finalize → IO signing → live. Auction-based sales don't have proposals; they're bid-by-bid. Today `sales-proposal-mode` (proposals + briefs) and `sales-guaranteed` (IO + guaranteed) are halves of the same flow that force sellers to declare both or pick the wrong one. + +Following the established `signed-requests` precedent (deprecated in 3.1, retained until 4.0), this PR: + +- Adds `sales-proposal-mode` to `x-deprecated-enum-values` in `static/schemas/source/enums/specialism.json` +- Updates `enumDescriptions[sales-proposal-mode]` with the deprecation note + migration path: declare `sales-guaranteed` instead; the `media_buy_seller/proposal_finalize` scenario remains accessible to agents that support `buying_mode: 'refine'` regardless of which specialism is declared +- Adds a deprecation banner to the storyboard at `static/compliance/source/specialisms/sales-proposal-mode/index.yaml` + +The storyboard bundle and enum value are retained through 3.x for backward compatibility — sellers that declare `sales-proposal-mode` continue to grade against the existing flow without any wire break. New sellers should declare `sales-guaranteed`. At 4.0 the enum value is removed and the storyboard bundle is retired. + +Migration for existing sellers: in `get_adcp_capabilities.specialisms[]`, replace `sales-proposal-mode` with `sales-guaranteed` (or declare both during the transition window). The `proposal_finalize` scenario at `static/compliance/source/protocols/media-buy/scenarios/proposal_finalize.yaml` is unchanged — sellers still grade against it through whichever parent specialism they declare. diff --git a/static/compliance/source/specialisms/sales-proposal-mode/index.yaml b/static/compliance/source/specialisms/sales-proposal-mode/index.yaml index 5b26504dcc..a18dd713b0 100644 --- a/static/compliance/source/specialisms/sales-proposal-mode/index.yaml +++ b/static/compliance/source/specialisms/sales-proposal-mode/index.yaml @@ -25,6 +25,13 @@ invariants: - status.monotonic narrative: | + **DEPRECATED in 3.1 — see https://github.com/adcontextprotocol/adcp/issues/3823** + Proposal-driven flows now grade under `sales-guaranteed`. Sellers that currently declare + `sales-proposal-mode` should additionally declare `sales-guaranteed` for the duration of + 3.x; this storyboard is retained for backward compat and removed at 4.0. The + `media_buy_seller/proposal_finalize` scenario remains accessible to agents that support + `buying_mode: 'refine'` regardless of which specialism declaration is used. + Your seller generates curated media plan proposals. The buyer sends a brief, your platform returns products alongside proposals — curated bundles with budget allocations and rationale for each recommendation. The buyer reviews, optionally refines, and then accepts a proposal diff --git a/static/schemas/source/enums/specialism.json b/static/schemas/source/enums/specialism.json index d728bef769..81082bf56b 100644 --- a/static/schemas/source/enums/specialism.json +++ b/static/schemas/source/enums/specialism.json @@ -5,7 +5,8 @@ "description": "Specialized capability claims an agent can make. Each specialism maps to a compliance storyboard bundle published at /compliance/{version}/specialisms/{id}/. An agent asserts specialisms it supports in get_adcp_capabilities; the AAO compliance runner executes the matching storyboards to verify the claim.", "type": "string", "x-deprecated-enum-values": [ - "signed-requests" + "signed-requests", + "sales-proposal-mode" ], "x-deprecated-enum-values-doc": "Enum values listed here are retained for backward compatibility but their corresponding storyboard has been relocated or removed. Build-time parity checks (scripts/build-compliance.cjs verifyEnumParity) skip filesystem-backing enforcement for these values. Targeted for removal in a future major version.", "enum": [ @@ -46,7 +47,7 @@ "sales-catalog-driven": "Catalog-driven commerce with conversion tracking", "sales-guaranteed": "Guaranteed media buys with human IO approval", "sales-non-guaranteed": "Non-guaranteed auction-based media buys", - "sales-proposal-mode": "Media buys negotiated via proposal acceptance", + "sales-proposal-mode": "DEPRECATED in 3.1 — proposal-driven flows now grade under `sales-guaranteed`. Sellers that currently declare `sales-proposal-mode` should additionally declare `sales-guaranteed` for the duration of 3.x; the `media_buy_seller/proposal_finalize` scenario remains accessible to agents that support buying_mode='refine'. This enum value is retained until 4.0 for backward compat. Migration: declare `sales-guaranteed` in `get_adcp_capabilities.specialisms[]`; the proposal-mode and IO-signing flows are halves of the same guaranteed-deal lifecycle (RFP → proposal → finalize → IO → live), and the spec's specialism vocabulary should reflect that. See https://github.com/adcontextprotocol/adcp/issues/3823 (taxonomy consolidation).", "sales-social": "Social media advertising platform with self-service flows", "signal-marketplace": "Marketplace signal agent reselling third-party data", "signal-owned": "Owned signal agent exposing first-party segments", From 63e113d54c27abe1dd0ea2e37ec2e97a3539458c Mon Sep 17 00:00:00 2001 From: Brian O'Kelley Date: Sat, 2 May 2026 12:32:56 -0400 Subject: [PATCH 2/3] spec(specialisms): add proposal_finalize to sales-guaranteed requires_scenarios Per #3792 review: when sellers migrate from sales-proposal-mode to sales-guaranteed, the proposal lifecycle scenario should still grade. Without this change, sales-guaranteed only required refine_products and the proposal_finalize coverage was lost on migration. Adds media_buy_seller/proposal_finalize to sales-guaranteed's requires_scenarios. The scenario already declares `generates_proposals` capability, so the runner grades it as not_applicable for direct-buy guaranteed sellers (quoted-rate-only flows without RFP) and grades normally for sellers that support proposals. Non-breaking for sellers that don't generate proposals. Updates sales-guaranteed's narrative to mention the proposal flow as part of guaranteed selling. Updates the deprecation note in specialism.json to reflect that proposal_finalize is now actually graded under sales-guaranteed (rather than the original "remains accessible regardless of which specialism is declared" framing, which was technically true but didn't ensure grading). --- .changeset/deprecate-sales-proposal-mode.md | 4 +++- .../source/specialisms/sales-guaranteed/index.yaml | 11 +++++++++++ static/schemas/source/enums/specialism.json | 2 +- 3 files changed, 15 insertions(+), 2 deletions(-) diff --git a/.changeset/deprecate-sales-proposal-mode.md b/.changeset/deprecate-sales-proposal-mode.md index 7afbdad9e4..d8551e51cc 100644 --- a/.changeset/deprecate-sales-proposal-mode.md +++ b/.changeset/deprecate-sales-proposal-mode.md @@ -9,7 +9,9 @@ Proposal mode is how guaranteed deals get sold in practice — RFP → proposal Following the established `signed-requests` precedent (deprecated in 3.1, retained until 4.0), this PR: - Adds `sales-proposal-mode` to `x-deprecated-enum-values` in `static/schemas/source/enums/specialism.json` -- Updates `enumDescriptions[sales-proposal-mode]` with the deprecation note + migration path: declare `sales-guaranteed` instead; the `media_buy_seller/proposal_finalize` scenario remains accessible to agents that support `buying_mode: 'refine'` regardless of which specialism is declared +- Updates `enumDescriptions[sales-proposal-mode]` with the deprecation note + migration path +- Adds `media_buy_seller/proposal_finalize` to `sales-guaranteed`'s `requires_scenarios` so the proposal lifecycle actually grades under the new specialism — sellers that declare `generates_proposals` capability grade against the proposal flow, sellers without it grade proposal_finalize as `not_applicable` (the scenario already declares `generates_proposals` capability so the runner skips gracefully) +- Updates `sales-guaranteed`'s narrative to reflect that proposal flows are part of guaranteed selling - Adds a deprecation banner to the storyboard at `static/compliance/source/specialisms/sales-proposal-mode/index.yaml` The storyboard bundle and enum value are retained through 3.x for backward compatibility — sellers that declare `sales-proposal-mode` continue to grade against the existing flow without any wire break. New sellers should declare `sales-guaranteed`. At 4.0 the enum value is removed and the storyboard bundle is retired. diff --git a/static/compliance/source/specialisms/sales-guaranteed/index.yaml b/static/compliance/source/specialisms/sales-guaranteed/index.yaml index 81bad5d0ed..9ee022e8eb 100644 --- a/static/compliance/source/specialisms/sales-guaranteed/index.yaml +++ b/static/compliance/source/specialisms/sales-guaranteed/index.yaml @@ -10,6 +10,7 @@ required_tools: - create_media_buy requires_scenarios: - media_buy_seller/refine_products + - media_buy_seller/proposal_finalize - media_buy_seller/delivery_reporting - media_buy_seller/measurement_terms_rejected - media_buy_seller/pending_creatives_to_start @@ -40,6 +41,16 @@ narrative: | is modelled entirely at the A2A task layer; there is no interim "pending_approval" media buy status (that value only exists on Account.status, not MediaBuy.status). + Proposal-driven workflows are part of guaranteed selling: most guaranteed deals start with + an RFP/brief, generate a proposal with curated bundles and rationale, refine, finalize to + committed status with firm pricing and an inventory hold, and then the buyer accepts via + create_media_buy. The `media_buy_seller/proposal_finalize` scenario in this specialism's + `requires_scenarios` exercises that flow. Sellers that declare `generates_proposals` + capability grade against it; direct-buy guaranteed sellers (rare; quoted-rate-only flows + with no RFP) grade proposal_finalize as not_applicable. This mirrors the consolidation + from the deprecated `sales-proposal-mode` specialism — proposal mode is how guaranteed + deals get sold, not a separate selling shape. + agent: interaction_model: media_buy_seller capabilities: diff --git a/static/schemas/source/enums/specialism.json b/static/schemas/source/enums/specialism.json index 81082bf56b..9d3fbe583b 100644 --- a/static/schemas/source/enums/specialism.json +++ b/static/schemas/source/enums/specialism.json @@ -47,7 +47,7 @@ "sales-catalog-driven": "Catalog-driven commerce with conversion tracking", "sales-guaranteed": "Guaranteed media buys with human IO approval", "sales-non-guaranteed": "Non-guaranteed auction-based media buys", - "sales-proposal-mode": "DEPRECATED in 3.1 — proposal-driven flows now grade under `sales-guaranteed`. Sellers that currently declare `sales-proposal-mode` should additionally declare `sales-guaranteed` for the duration of 3.x; the `media_buy_seller/proposal_finalize` scenario remains accessible to agents that support buying_mode='refine'. This enum value is retained until 4.0 for backward compat. Migration: declare `sales-guaranteed` in `get_adcp_capabilities.specialisms[]`; the proposal-mode and IO-signing flows are halves of the same guaranteed-deal lifecycle (RFP → proposal → finalize → IO → live), and the spec's specialism vocabulary should reflect that. See https://github.com/adcontextprotocol/adcp/issues/3823 (taxonomy consolidation).", + "sales-proposal-mode": "DEPRECATED in 3.1 — proposal-driven flows now grade under `sales-guaranteed`. The `media_buy_seller/proposal_finalize` scenario is included in `sales-guaranteed`'s `requires_scenarios`; sellers that declare `generates_proposals` capability grade against the proposal flow, sellers without it grade proposal_finalize as not_applicable. This enum value is retained until 4.0 for backward compat. Migration: replace `sales-proposal-mode` with `sales-guaranteed` in `get_adcp_capabilities.specialisms[]` (or declare both during the 3.x transition). The proposal-mode and IO-signing flows are halves of the same guaranteed-deal lifecycle (RFP → proposal → finalize → IO → live), and the spec's specialism vocabulary now reflects that. See https://github.com/adcontextprotocol/adcp/issues/3823 (taxonomy consolidation).", "sales-social": "Social media advertising platform with self-service flows", "signal-marketplace": "Marketplace signal agent reselling third-party data", "signal-owned": "Owned signal agent exposing first-party segments", From 31afa2e3b47ae3a2561b483cc606c57a967fedcd Mon Sep 17 00:00:00 2001 From: Brian O'Kelley Date: Sat, 2 May 2026 12:45:28 -0400 Subject: [PATCH 3/3] =?UTF-8?q?spec(specialisms):=20walk=20back=20proposal?= =?UTF-8?q?=5Ffinalize=20=E2=86=92=20sales-guaranteed;=20needs=20capabilit?= =?UTF-8?q?y=20flag=20first=20(refs=20#3844)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per #3840 review (protocol expert): the storyboard runner gates only on storyboard.requires_capability and required_tools, not on scenario- level agent.capabilities metadata. So adding proposal_finalize to sales-guaranteed.requires_scenarios would FAIL direct-buy guaranteed sellers (auction PG, retail SKU; no RFP) at the proposal-finalize step, not skip it as not_applicable. My earlier claim about graceful N/A grading was wrong — there's no requires_capability path in get_adcp_capabilities for "this seller supports proposals" yet. Walk back the requires_scenarios change. Document the gap: through 3.x, sellers that do proposals continue to declare BOTH sales-guaranteed AND sales-proposal-mode (the latter's existing storyboard bundle still grades the proposal flow). Pure-direct-buy guaranteed sellers declare only sales-guaranteed. File #3844 to add a `supports_proposals` capability flag in the get_adcp_capabilities media_buy block. With that in place, 4.0 can fold proposal_finalize into sales-guaranteed.requires_scenarios with capability-gated skip semantics, drop sales-proposal-mode entirely, and finish the consolidation cleanly. Update the deprecation note in specialism.json and the sales-guaranteed narrative to reflect this state. Refs: #3823, #3844. --- .changeset/deprecate-sales-proposal-mode.md | 13 +++++++------ .../specialisms/sales-guaranteed/index.yaml | 16 +++++++++------- static/schemas/source/enums/specialism.json | 2 +- 3 files changed, 17 insertions(+), 14 deletions(-) diff --git a/.changeset/deprecate-sales-proposal-mode.md b/.changeset/deprecate-sales-proposal-mode.md index d8551e51cc..a2dc9e81e5 100644 --- a/.changeset/deprecate-sales-proposal-mode.md +++ b/.changeset/deprecate-sales-proposal-mode.md @@ -2,18 +2,19 @@ "adcontextprotocol": minor --- -spec(specialisms): deprecate sales-proposal-mode — proposal-driven flows merge into sales-guaranteed (refs #3823 item 4) +spec(specialisms): deprecate sales-proposal-mode (refs #3823 item 4, #3844) Proposal mode is how guaranteed deals get sold in practice — RFP → proposal → review → finalize → IO signing → live. Auction-based sales don't have proposals; they're bid-by-bid. Today `sales-proposal-mode` (proposals + briefs) and `sales-guaranteed` (IO + guaranteed) are halves of the same flow that force sellers to declare both or pick the wrong one. -Following the established `signed-requests` precedent (deprecated in 3.1, retained until 4.0), this PR: +Following the established `signed-requests` precedent (deprecated in 3.1, retained until 4.0): - Adds `sales-proposal-mode` to `x-deprecated-enum-values` in `static/schemas/source/enums/specialism.json` - Updates `enumDescriptions[sales-proposal-mode]` with the deprecation note + migration path -- Adds `media_buy_seller/proposal_finalize` to `sales-guaranteed`'s `requires_scenarios` so the proposal lifecycle actually grades under the new specialism — sellers that declare `generates_proposals` capability grade against the proposal flow, sellers without it grade proposal_finalize as `not_applicable` (the scenario already declares `generates_proposals` capability so the runner skips gracefully) -- Updates `sales-guaranteed`'s narrative to reflect that proposal flows are part of guaranteed selling - Adds a deprecation banner to the storyboard at `static/compliance/source/specialisms/sales-proposal-mode/index.yaml` +- Updates `sales-guaranteed`'s narrative to explain how proposal flows relate to guaranteed selling and why proposal_finalize is not yet folded into its `requires_scenarios` -The storyboard bundle and enum value are retained through 3.x for backward compatibility — sellers that declare `sales-proposal-mode` continue to grade against the existing flow without any wire break. New sellers should declare `sales-guaranteed`. At 4.0 the enum value is removed and the storyboard bundle is retired. +The clean folding of `proposal_finalize` into `sales-guaranteed.requires_scenarios` (so both flavors of guaranteed selling grade against the proposal lifecycle) needs a wire-level capability flag the storyboard runner can use to skip the scenario as `not_applicable` for direct-buy guaranteed sellers (auction PG, retail SKU; no RFP). The runner gates only on `requires_capability` predicates against `get_adcp_capabilities`, not on scenario-level metadata. Tracked as a follow-up in #3844 (`add supports_proposals capability flag`). -Migration for existing sellers: in `get_adcp_capabilities.specialisms[]`, replace `sales-proposal-mode` with `sales-guaranteed` (or declare both during the transition window). The `proposal_finalize` scenario at `static/compliance/source/protocols/media-buy/scenarios/proposal_finalize.yaml` is unchanged — sellers still grade against it through whichever parent specialism they declare. +**Migration through 3.x**: sellers that do proposals continue to declare BOTH `sales-guaranteed` AND `sales-proposal-mode` so the proposal flow grades under the proposal-mode specialism's existing storyboard bundle. Pure-direct-buy guaranteed sellers (auction PG, retail SKU) declare only `sales-guaranteed`. The wire shape is unchanged — both enum values remain valid through 3.x. + +**At 4.0**: with the `supports_proposals` capability flag in place (#3844), `proposal_finalize` joins `sales-guaranteed.requires_scenarios` with capability-gated skip semantics, the `sales-proposal-mode` enum value is removed, and the storyboard bundle is retired. diff --git a/static/compliance/source/specialisms/sales-guaranteed/index.yaml b/static/compliance/source/specialisms/sales-guaranteed/index.yaml index 9ee022e8eb..d15558b6f9 100644 --- a/static/compliance/source/specialisms/sales-guaranteed/index.yaml +++ b/static/compliance/source/specialisms/sales-guaranteed/index.yaml @@ -10,7 +10,6 @@ required_tools: - create_media_buy requires_scenarios: - media_buy_seller/refine_products - - media_buy_seller/proposal_finalize - media_buy_seller/delivery_reporting - media_buy_seller/measurement_terms_rejected - media_buy_seller/pending_creatives_to_start @@ -44,12 +43,15 @@ narrative: | Proposal-driven workflows are part of guaranteed selling: most guaranteed deals start with an RFP/brief, generate a proposal with curated bundles and rationale, refine, finalize to committed status with firm pricing and an inventory hold, and then the buyer accepts via - create_media_buy. The `media_buy_seller/proposal_finalize` scenario in this specialism's - `requires_scenarios` exercises that flow. Sellers that declare `generates_proposals` - capability grade against it; direct-buy guaranteed sellers (rare; quoted-rate-only flows - with no RFP) grade proposal_finalize as not_applicable. This mirrors the consolidation - from the deprecated `sales-proposal-mode` specialism — proposal mode is how guaranteed - deals get sold, not a separate selling shape. + create_media_buy. The `media_buy_seller/proposal_finalize` scenario covers that flow but + is NOT (yet) in this specialism's `requires_scenarios` because the storyboard runner + cannot currently grade it as `not_applicable` for sellers without proposal support — there + is no `requires_capability` path in `get_adcp_capabilities` for "this seller supports + proposals" (tracked at #3844). Until that capability flag exists, sellers that do + proposals should declare BOTH `sales-guaranteed` AND `sales-proposal-mode` through 3.x; + pure-direct-buy guaranteed sellers (auction PG, retail SKU) declare only `sales-guaranteed`. + At 4.0, with the capability flag in place, `proposal_finalize` joins `sales-guaranteed`'s + `requires_scenarios` and the `sales-proposal-mode` enum value is removed. agent: interaction_model: media_buy_seller diff --git a/static/schemas/source/enums/specialism.json b/static/schemas/source/enums/specialism.json index 9d3fbe583b..2108c15c9f 100644 --- a/static/schemas/source/enums/specialism.json +++ b/static/schemas/source/enums/specialism.json @@ -47,7 +47,7 @@ "sales-catalog-driven": "Catalog-driven commerce with conversion tracking", "sales-guaranteed": "Guaranteed media buys with human IO approval", "sales-non-guaranteed": "Non-guaranteed auction-based media buys", - "sales-proposal-mode": "DEPRECATED in 3.1 — proposal-driven flows now grade under `sales-guaranteed`. The `media_buy_seller/proposal_finalize` scenario is included in `sales-guaranteed`'s `requires_scenarios`; sellers that declare `generates_proposals` capability grade against the proposal flow, sellers without it grade proposal_finalize as not_applicable. This enum value is retained until 4.0 for backward compat. Migration: replace `sales-proposal-mode` with `sales-guaranteed` in `get_adcp_capabilities.specialisms[]` (or declare both during the 3.x transition). The proposal-mode and IO-signing flows are halves of the same guaranteed-deal lifecycle (RFP → proposal → finalize → IO → live), and the spec's specialism vocabulary now reflects that. See https://github.com/adcontextprotocol/adcp/issues/3823 (taxonomy consolidation).", + "sales-proposal-mode": "DEPRECATED in 3.1 — proposal-driven flows are conceptually part of `sales-guaranteed` (RFP → proposal → finalize → IO → live is one lifecycle). For 3.x, sellers that do proposals continue to declare BOTH `sales-guaranteed` AND `sales-proposal-mode` so the proposal flow grades under the proposal-mode specialism's existing `requires_scenarios`. Pure-direct-buy guaranteed sellers (auction PG, retail SKU; no RFP) declare only `sales-guaranteed`. This enum value is retained until 4.0 for backward compat. The clean merge — folding `proposal_finalize` into `sales-guaranteed.requires_scenarios` with capability-gated skip — needs a `supports_proposals` capability flag in `get_adcp_capabilities` so the runner can grade it as `not_applicable` for direct-buy sellers; tracked at #3844. At 4.0, with that flag in place, `sales-proposal-mode` is removed and proposal grading lives entirely under `sales-guaranteed`. See https://github.com/adcontextprotocol/adcp/issues/3823 (taxonomy consolidation).", "sales-social": "Social media advertising platform with self-service flows", "signal-marketplace": "Marketplace signal agent reselling third-party data", "signal-owned": "Owned signal agent exposing first-party segments",