Repository navigation
[Comment] § 1, § 4.1 — brief_ref is REQUIRED for a custom proposal and points at an object the specification does not define #34
Description
Which section?
4 — Proposal
Field(s) involved
brief_ref, type (§ 4.1); § 1 "Custom proposal"; § 4.2 specifications; #20 item 5
Your comment
This responds to #20 item 5, which proposes "no change" on the custom proposal flow because type: custom and brief_ref are "already in the draft" and "the gap was in the demonstration, not the specification." We read the draft differently: the fields exist, and the object one of them is REQUIRED to reference does not.
What the draft says. § 1 defines a custom proposal as "built in response to a buyer's agent brief, referenced via brief_ref." § 4.1 marks brief_ref as supplied and "REQUIRED when type is custom." That is the complete text. Three mentions of a brief; no definition, no shape, no location, no citation to where one is defined.
Why that is a specification gap and not a demonstration gap. A normative REQUIRED field must be fillable by a conforming implementation. A seller's agent receiving a custom brief has nothing to parse it against. A buyer's agent wanting a custom proposal has nothing to produce. Nothing says whether brief_ref is a URL, a registry id, a content hash or a pointer into a system the draft has not named. Nothing says whether the brief must be immutable, resolvable during discovery, or retained after agreed, all of which § 2.2 takes care to say about catalog_ref, the other reference type the draft defines. A custom example, which item 5 suggests adding later, would have to invent all of this, and the example would then be the specification.
Why it matters more than an ordinary missing definition. The draft solves semantic drift on the seller's side by making the offer structured and enumerated: a buying agent does arithmetic over declared options rather than interpreting prose. The custom flow starts on the buyer's side. If the buyer's need arrives as prose, the seller's agent is back to reading natural language and guessing, which is the failure the structured object exists to prevent. A brief that used the § 5 enumerations (channel, environments, transaction_mechanism, geo codes, taxonomy_ref, measurement_source.vendor) would make matching a brief to a shelf set intersection. An undefined brief makes it inference. The draft has built the seller's half of that bridge and left the buyer's half unmentioned.
A smaller point. The buyer's brief is also the natural home for the boundary between what the buyer discloses (channels, budget range, flight, required guarantees) and what it must never share (its ceiling price, its approval thresholds). The draft gives the buyer nowhere to hold either, so the boundary cannot be drawn.
Two fixes, either acceptable.
-
Cite it. If an AAMP 3.0 workstream defines the brief, § 4.1 should say so and link it, and should require the brief to use the § 5 enumerations where they apply. Then "no change" to the object is right and the dependency is visible.
-
Admit it is unstructured. State that a custom proposal MAY be built from an unstructured brief; that
brief_refMUST resolve to an immutable artefact retrievable by both parties for the life of the proposal; and that the seller MUST record inspecificationshow it interpreted the brief. That makes the interpretation auditable without defining the brief.
What the draft cannot do is leave a REQUIRED field pointing at nothing. We would accept "deferred to workstream X" as a disposition, provided the spec text itself names the deferral so a reader does not have to discover it.
Concrete scenario
A buyer's agent sends a brief to three sellers and asks each for a custom proposal. Seller A's agent expects JSON with channel, budget, flight and geo keys. Seller B's agent expects a URL to a PDF. Seller C's agent expects a free-text paragraph. The buyer's agent produced one of those three, so two sellers cannot respond, and the draft says nothing about which of the three was conformant.
The seller that could respond publishes a custom proposal with brief_ref: "https://buyer.example/briefs/q4-fin-services-2026". The buyer's agent receives it and tries to check that the proposal answers the brief: that the channels, geo and flight match what was asked. The proposal has no field that references a requirement in the brief, and the brief has no structure a check could run against. The agent can read description and specifications, both prose, and form an opinion. That is exactly the step § 3 and § 7 remove from the seller's side.
Six weeks later the buyer disputes whether the agreed proposal met the brief. brief_ref still points at the URL. Nothing in the draft said the brief had to be immutable, and the buyer has since edited it. There is no record of what the seller was answering.
Under fix 1 all three sellers parse the same structured brief and the proposal's selectable fields can be checked against it. Under fix 2 the brief is pinned, the seller's interpretation is written in specifications, and the dispute has a document to look at. Under the current text none of this is defined, which is the demonstration gap and the specification gap being the same gap.
You are commenting as
AdTech Provider
Before you submit
- I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
- This comment contains no confidential or commercially sensitive information.
Activity
alamshukla commentedon Oct 13, 2026
I am commenting on behalf of So What Labs, a buyer-side marketing decisioning and optimisation provider working on autonomous performance marketing.
We support the concern raised in this issue and favour defining, or explicitly referencing, a structured buyer brief rather than leaving
brief_refas a reference to an undefined object.We would add one further requirement: the design should distinguish between the advertiser’s seller-visible brief and its private buyer-side decision policy.
A structured brief should be capable of representing:
However, an advertiser may not want to disclose its complete evaluation model to the seller. Information such as maximum willingness to pay, internal profitability calculations, approval thresholds and channel-allocation logic may need to remain private to the buyer.
For example, a seller-visible brief might request UK new-customer acquisition, suppression of existing customers, a defined flight and specified reporting. The buyer’s private decision policy may additionally require forecast CAC below £80, minimum contribution margin and human approval above a particular commitment threshold.
The seller needs enough structured information to produce a valid proposal. It does not need access to every rule the buyer’s agent uses to evaluate or approve that proposal.
We therefore suggest that:
brief_refMUST identify a versioned and immutable brief that remains available for the life of the proposal.The brief SHOULD distinguish objectives, hard constraints, preferences and measurement requirements so an agent can evaluate compliance without relying entirely on prose.
OpenProposal SHOULD permit an opaque reference to the buyer-side decision or approval record without requiring the seller to access the buyer’s confidential evaluation model.
The agreed proposal and its downstream
correlation_idSHOULD preserve the relevant brief version so that the buyer can later demonstrate which objective and constraints the decision was evaluated against.This separation would allow a seller agent to understand what it must satisfy while allowing the buyer agent to retain control of commercially sensitive decision logic.
It would also make the workflow auditable: the industry could determine which brief a proposal answered, which requirements were disclosed, and which buyer-controlled policy authorised the eventual commitment.
esteininger commentedon Oct 20, 2026
Implementation feedback, commenting as a content classification vendor (Mixpeek).
We built a small seller-side matcher against this draft on 2026-10-19: 11 fictional line items from four sellers, in the shape of the § 6 examples, and three buyer briefs. Results are in the section "A worked example: matching three briefs to line items" at https://mixpeek.com/guides/openproposal-aamp-3-explained. Two findings bear on what the brief should be.
The hard filters only worked when the brief used the § 5 enumerations. Channel,
commitment_bounds.min_budgetand the offer window rejected the right items every time, because the brief stated them in the spec's own terms. The content constraint ("no gambling content") was the one we could not express that way, and a sports betting show scored above one of the correct football packages until we filtered on content category. That supports the point here: a brief built from § 5 fields makes matching a set intersection. We would add content categories withtaxonomy_refto that list (proposed for line items in [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48).A semantic score over-matched without an explanation. Some items passed every constraint and shared no category with the brief. We had the matcher return the field names that drove each match, and that is what let a person check the result. We suggest that a custom proposal's line items carry an optional
matched_on[](field names from § 5), so the buyer's agent can explain why the seller offered each one.So when the brief is defined, we would support a free-text
objectiveplus optional structured fields that reuse § 5 enumerations, including content categories, and we agree with the comment above that the seller-visible brief should stay separate from the buyer's private decision policy.Sirajmx commentedon Oct 21, 2026
Thank you, and thank you to So What Labs and Mixpeek for the additional comments.
#20 item 5 records the position we proposed after the bootcamp. It is not a disposition. This issue will be considered at adjudication together with that item, including the two fixes proposed here, the separation between a seller-visible brief and the buyer's private decision policy, and the proposed
matched_on[]field.KonstantinMirin commentedon Nov 4, 2026
Postindustria (IAB Tech Lab member). @VJAlkimi, your dispute scenario also bears on our binding record (#63). In the change that closes it,
record_digestcoversbrief_id(brief_refin the public draft), but only the string. If the buyer edits the brief behind an unchanged id, the digest still matches, and the record doesn't show what the seller answered. The record holds only if the brief can't change. The scope change leaves the form of a brief to the AAMP wire and lifecycle contract, but doesn't say whether a brief can change. Your second fix closes that gap: the brief's reference "MUST resolve to an immutable artefact". So does the versioned brief @alamshukla asks for. We support either rule, wherever the brief is defined.Analyzed and generated with the help of Claude, fully reviewed by me.