RFC: bind buyer change rights into accepted proposal terms

[bokelley]

RFC: bind buyer change rights into accepted proposal terms

Summary

Add proposal-bound change_terms to the commercial terms accepted with a media buy. Use those terms to state which changes the buyer is contractually entitled to request, through which service mode, under what conditions and with what processing commitment. Keep runtime available_actions as the current-state projection of those negotiated rights.

This completes the direction established by #4480/#4514 rather than replacing it.

Problem

The current model intentionally makes product-level allowed actions advisory and per-buy available_actions authoritative for the current moment. However, available_actions.mode and SLA are also described as advisory at emission time and may change. The accepted proposal's immutable commercial envelope does not currently preserve the buyer's negotiated change rights.

That leaves two different questions conflated:

1. What changes did the seller agree the buyer may make under this buy?
2. Which of those changes can be submitted right now given the buy's current state?

A seller's internal approval process is not part of either contract. The buyer only needs the externally meaningful route, conditions, expected processing time and consequences.

Proposed model

Add change_terms to the proposal's accepted commercial_terms, reusing the existing action vocabulary where possible.

Illustrative shape:

{
  "change_terms": [
    {
      "action": "increase_budget",
      "service_mode": "self_serve",
      "processing_sla": { "duration": "PT15M" },
      "conditions": ["within_approved_credit_limit"]
    },
    {
      "action": "change_daily_cap",
      "service_mode": "seller_managed",
      "processing_sla": { "business_duration": "P1D" },
      "terms_ref": "change_terms_daily_cap"
    }
  ]
}

The exact field names should be aligned with the existing MediaBuyAvailableAction vocabulary. For 4.0, consider replacing implementation-revealing modes such as requires_approval with buyer-facing terms such as seller_managed or deferred. Whether the seller uses a human, an AI system or a queue is intentionally opaque.

Semantics

• Accepted change_terms are binding for that proposal/media buy.
• An action omitted from change_terms is not a negotiated buyer change right.
• Product-level allowed actions remain advisory templates used during discovery.
• Runtime available_actions is derived from accepted change_terms plus current state, timing, balances and other applicable conditions.
• Runtime availability may temporarily remove or constrain an action, but it must not silently replace negotiated service mode, SLA or commercial conditions. A contractual change requires an amendment/new accepted proposal.
• terms_ref points to detailed negotiated terms where the compact action entry is insufficient.
• Buyer obligations with deadlines and consequences belong in the accepted terms. They are not modeled as seller approval workflow.
• A cancellation right or consequence can have its own effective/processing timing; it must not imply instant execution.
• Async submitted/working states communicate processing. They do not expose internal seller escalation.

Non-goals

• Orchestrating seller-internal approval or HITL.
• Promising that every negotiated action is available in every runtime state.
• Turning the governance agent into the owner of bilateral commercial terms.
• Duplicating full commercial language inside available_actions.

Acceptance criteria

• A proposal can state binding rights and processing commitments for each buyer-initiated change type.
• On media-buy creation from a proposal, the accepted terms are immutable and addressable by terms_ref.
• available_actions has normative derivation/precedence rules relative to accepted change_terms.
• A seller can say that a change normally takes one business day without exposing whether a human approves it.
• Tests cover immediate, deferred/seller-managed, temporarily unavailable, conditionally available and not-negotiated actions.
• Amendments to change terms use proposal refinement and explicit re-acceptance.

Related work

• RFC: allowed_actions on products + buys for pre-flight mutation discovery #4480 / feat(media-buy): allowed_actions + available_actions for update_media_buy (#4480) #4514: current-state available_actions, mode, SLA and forward terms_ref design.
• epic: make proposal negotiation easy to implement, teach, and verify #6556: proposal workflow epic.
• RFC: sell-side governance — seller-authored policies and governance-agent acceptance in campaign governance #6656: seller-authored acceptance/governance policy discussion; the acceptance-discovery portion should move to the first RFC, while buyer change rights move here.
• RFC: structured seller acceptance-policy discovery backed by the policy registry #6749: companion RFC for seller acceptance-policy discovery.

[bokelley]

Triage

Classification: RFC — normative additive (buyer amendment-right binding in accepted proposals)
Bucket(s): spec / protocol, governance, media-buy
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Architecturally correct; directly fills the terms_ref forward-reference already on media-buy-available-action.json and product-allowed-action.json ("will tighten when the buy-terms RFC ships"). Three schema-coherence blockers: (1) illustrative duration/business_duration keys don't exist in sla-window.json — only response_max/completion_max do; (2) seller_managed is absent from every mode enum (media-buy-action-mode.json, canonical-media-buy-action-mode.json); (3) no normative fallback specified for accepted proposals that predate this RFC and carry no change_terms. No IAB/OpenRTB upstream precedent — AdCP is defining new ground.
• adtech-product-expert: Solves a real footgun (available_actions.mode is explicitly advisory today; buyers cannot bind service-mode expectations to the immutable deal record); additive/non-breaking if optional. Key structural issue: commercial-terms.json has additionalProperties: false, so change_terms must be a sibling in canonical-proposal.json, not nested inside commercial_terms — this places it outside terms_digest SHA-256 scope, which is a tamper-evidence gap the WG must address. Recommends voting RFC: structured seller acceptance-policy discovery backed by the policy registry #6749 + RFC: bind buyer change rights into accepted proposal terms #6750 together (they share the terms_ref seam).

My take: Both experts converge on the same finding — the direction is correct, the schema was pre-wired for it, and four concrete structural questions block schema authoring. #6749 (seller acceptance-policy discovery) and #6750 should be batched for a single WG ballot.

---

Decision memo (draft — awaiting WG ratification)

id: DR-NNNN
title: change_terms binds buyer amendment rights in the accepted proposal; available_actions derives from it
class: normative
status: recorded
date: 2026-08-21
decided_by: pending WG ballot
refs: ["#6750", "#4480", "#4514", "#6749"]
dissent: none recorded

Decision: AdCP proposals carry a change_terms array in the accepted commercial envelope, as a sibling field to commercial_terms in canonical-proposal.json. Each entry names one buyer-changeable action, its service mode, processing SLA commitment, and applicable conditions. Runtime available_actions is the current-state projection of accepted change_terms plus deal state: it may temporarily restrict or gate an action, but must not silently replace the negotiated service mode, SLA, or conditions. An action absent from change_terms is not a negotiated buyer change right. Amendments to change_terms require a new accepted proposal.

Rationale: The terms_ref placeholder on every variant of media-buy-available-action.json and product-allowed-action.json was explicitly reserved for this RFC. Separating contractual rights (immutable, proposal-bound) from runtime availability (current-state projection) removes the inherent ambiguity where available_actions.mode is advisory and can change between acceptance and mutation.

Implications: Settles the contractual-rights / runtime-state architectural split and the placement of change_terms in canonical-proposal.json. Does not settle: SLA field names; whether seller_managed ships in 3.2 or 4.0 only; the conformance consequence of violating declared change_terms; whether change_terms must be folded into terms_digest scope.

---

Four questions for the WG before ratification:

Q1 — SLA field names. Does change_terms[].processing_sla reuse sla-window.json (response_max/completion_max), or does this RFC introduce a new type for business-hours durations?

Option A — reuse existing sla-window.json:

{ "processing_sla": { "response_max": "PT15M" } }

Option B — new business_duration field (requires new schema type definition):

{ "processing_sla": { "business_duration": "P1D" } }

Q2 — service_mode vocabulary for 3.2. Current enum values: self_serve, conditional_self_serve, requires_approval. seller_managed does not exist in any live schema.

Option A — use existing enum in 3.x; defer seller_managed rename to 4.0 breaking change:

{ "service_mode": "requires_approval" }  // 3.x wire — normative bridge text required

Option B — add seller_managed as new 3.2 minor enum value; deprecate requires_approval:

{ "service_mode": "seller_managed" }  // new value; requires minor bump

Q3 — Binding force (normative MUST vs. guidance). If a seller populates change_terms declaring pause as self_serve but later returns ACTION_NOT_ALLOWED on a pause request, is that a conformance violation? Without a normative MUST, change_terms is advisory — the same problem that motivated this RFC.

Q4 — Digest coverage. With change_terms as a sibling to commercial_terms in canonical-proposal.json, it falls outside the terms_digest SHA-256. Is the buyer's archived copy of the accepted proposal sufficient tamper evidence, or must terms_digest be extended to cover change_terms?

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01PwbMZTsryLUSLQVwnQ1sbb

---

Generated by Claude Code