[Comment] § 1, § 4.1 — Name the operations that move a proposal, and which AAMP binding carries them #113

Which section?

Whole document / more than one section

Field(s) involved

status, negotiation_history[], hold_status, commitment, assent

Your comment

OpenProposal defines an object and its states, but not the operations that change them, so two implementations can agree on every field and still not interoperate. The draft implies these operations without naming them:

• fetch summary and fetch full (§ 2.1)
• request a requestable value (§ 3)
• counter, accept, decline and withdraw (negotiation_history[].action, § 4.1)
• request and release a hold (§ 5.6.2)
• commit with an idempotency_key (§ 5.6.1)
• assent (§ 4.1)

We are not asking 3.0 to define a wire protocol. We ask for two things:

1. A short operations table in § 4: operation, which party may call it, which status it requires, and the status and negotiation_history[] entry it produces. This complements [Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65 ("who moves each status"). [Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65 covers who, and this covers by which call.
2. One sentence naming where the binding lives. For example: "Operations are carried by the AAMP buyer/seller agent protocol (MCP / A2A mapping, see …)." Or, if no binding is settled, say so and name the workstream that will set it.

Without (2), buy-side platforms will bind OpenProposal to whatever agent protocol they already speak. We would bind it to AdCP's get_products / request_proposals / create_media_buy today, and so would others. That is the fragmentation AAMP set out to avoid.

Filed after the 2026-10-22 close of the comment period, so we understand this is post-comment and for the next draft. Submitted by Hypermindz (buy-side agentic media planning platform).