OpenProposal (AAMP 3.0) explained: the object, its 71 fields and what buyer agents read

What is OpenProposal?

OpenProposal is the object at the center of IAB Tech Lab's AAMP 3.0: a machine-readable description of an advertising offer that a buying agent can parse and evaluate without a person in the loop. One object carries an offer from the first pitch to the binding commercial terms. A seller publishes it, a buyer's agent reads it, selects options within limits the seller declared, commits, and the result lands in an existing execution standard such as OpenDirect 2.1, the Deals API or OpenRTB 2.6 (OpenProposal 3.0 draft 1).

Status on 2026-10-19: version 3.0 draft 1, published for public comment on 2026-09-22. The comment period closes on 2026-10-22. It is a draft, and the spec says it must not be treated as a ratified standard. Anyone with a GitHub account can comment; IAB Tech Lab membership is not required (CONTRIBUTING.md).

Where does a proposal end up?

OpenProposal does not replace IAB Tech Lab's execution standards. Each line item names a transaction mechanism, and that decides where it lands:



Two shapes exist. A standard proposal is published by the seller's agent with no brief. A custom proposal is built in response to a buyer's brief and points at it through brief_ref.

What does the object look like?

Two levels, with one strict rule between them:

Proposal: identity, lifecycle state, assent records, and the pitch (description, specifications, best_for[], not_suitable_for[], seasonality_notes).

Line items: each one a self-contained buyable unit in exactly one channel (display, video, audio, ctv, dooh or native).

The rule: a line item never inherits a value from the proposal or from a sibling line item. A buying agent can hand one line item to a downstream system without resolving anything above it. A buyer may also commit to a subset of a proposal's line items unless the proposal's binding terms require them together.

Every line item has two representations. The summary is what an agent reads when screening many sellers. It must include line_item_id, channel, content_detail, property names, included formats, cost method, gross rate, min_spend, addressable_scale, committed_metrics[] and transaction_mechanism, plus the proposal's ID, seller name, description and validity window. The full representation has every field, with every catalog reference resolved.

Fields drawn from a seller catalog can carry a version-pinned reference such as examplepub/audiences/smb-decision-makers@3 instead of an inline value. When a proposal reaches agreed, every reference is replaced by its resolved value, so the stored deal is self-contained.

The seven mutability markers

Every one of the draft's 71 fields carries exactly one marker. This is the core idea of the spec, because it tells an agent what it may change and whether changing it needs the seller's agreement:



Two fields (pricing[] and buyer_requirements) are mixed. Of the 23 fields a buyer touches, only the 3 requestable ones (materials_due, hold_status, committed_metrics[]) need a round trip (Appendix B of the draft). The spec calls the result constraint satisfaction: because the seller declares options and prices up front, a buyer agent solves for a valid configuration instead of negotiating field by field.

One consequence is easy to miss. Because audiences, properties and formats are selectable, addressable_scale and availability must be recomputed against what the buyer actually picked. A single declared reach figure is only right for the default selection.

Reading a CTV line item the way a buyer agent does

This is the CTV example from the OpenProposal repository (examples/line-item-ctv.yaml), trimmed:

line_item_id:   "weather-app-ctv"
channel:        ctv
formats:        { available: ["ctv/instream-15s", "ctv/instream-30s"],
                  included: ["ctv/instream-15s"],
                  pricing: { "ctv/instream-30s": { delta_cpm: 8.00 } } }
frequency_cap:  { max: { min: 1, max: 4 }, period: "day", basis: household }
pricing:
  - { cost_method: CPM, gross_rate: 45.00, floor: 39.60,
      price_valid_until: "2026-12-01T23:59:59Z", currency: USD }
commitment_bounds: { min_budget: 25000.00 }
committed_metrics: [{ metric: completion_rate, value: 0.95, basis: seller_reported }]
transaction_mechanism: { available: ["PRIVATE_AUCTION"], included: ["PRIVATE_AUCTION"] }
serving_mode:      ssai

What an agent can conclude without asking the seller anything:

Formats are selectable. The 15-second spot is in the base rate; the 30-second spot costs $8.00 more per thousand. Choosing it resolves immediately.

The frequency cap is settable anywhere from 1 to 4 per day, counted per household, which is how CTV usually caps.

The rate is $45.00 CPM, posted until 2026-12-01, with a floor of $39.60. The floor lets a buyer's counter-offer be checked without a round trip.

The buyer must commit at least $25,000 (commitment_bounds), with flight dates and an idempotency key in commitment.

A higher completion-rate guarantee is requestable. Asking for more than the declared 0.95 is the one thing here that needs the seller's assent.

It transacts as a private auction served through server-side ad insertion, so it lands in the Deals API and OpenRTB 2.6.

The format IDs ctv/instream-15s and ctv/instream-30s are worth a second look: open question 4 of the draft notes that the format registry has no audio/*, ctv/* or dooh/* entries yet, so the example uses identifiers the registry cannot resolve today.

How does a buyer agent match a brief to a proposal?

The draft leaves most of this to implementers. What it does say:

The summary representation is the screening surface, so description, content_detail, channel, formats, price and scale are what an agent compares across sellers.

description is required and must be prose, "not a name", and is where the seller makes the case for buying.

best_for[] is advisory and explicitly "never the basis for a match".

A custom proposal must carry brief_ref, but the brief object it points to is not defined in the spec. That gap is filed as a public comment (issue #34).

So an agent matching a brief like "home renovation content, CTV, Q4" has prose to read and very little structure to filter on, which brings up the content question.

Where are content categories in OpenProposal?

Mostly absent in draft 1. Compare how the spec treats audiences and content:



The targeting envelope in § 5.5 covers geo, device, daypart and frequency_cap. There is no contextual or content-category targeting field. Downstream, OpenRTB 2.6 already carries content categories in content.cat with cattax naming the taxonomy (9 for IAB Content Taxonomy 3.1), so the information exists in the bidstream, but the proposal a buyer agent reads first has no standard place for it. Of the public issues filed by 2026-10-19, none proposes one; the closest asks for content language on properties.

Until the spec settles this, a seller can still be consistent: classify each show, series or section against IAB Content Taxonomy 3.1, put those category IDs inside content_detail alongside the names, and send the same IDs in content.cat with cattax: 9 when the line item runs. A buyer agent that reads one can then check the other. For how to fill the bid-request side, see why CTV bid requests lack content categories.

The draft's seven open questions

The spec asks for comment on these specifically (open questions):

1. Does per-field mutability belong in 3.0, or should buyers select whole line items and round-trip everything else? 2. Do seller catalogs (catalog_ref) belong in 3.0? 3. How should a buying agent compare guarantees across channels, such as a viewable rate against a completion rate? 4. The format registry has no audio/*, ctv/* or dooh/* entries. 5. Is a min_line_items field needed to require a bundle? 6. Should payment_terms and invoicing_party be catalog references? 7. Does the environments enum match real inventory?

How to comment before October 22

Comments go in as GitHub issues or pull requests on IABTechLab/OpenProposal; discussions are not part of the formal record. The contributing guide asks commenters to cite the section, describe a concrete scenario that breaks, propose an alternative, and say whether they write as a buyer, seller, SSP, DSP or vendor. It names implementation feedback, from someone who built against the draft, as the most valuable kind of comment. Every comment gets a written disposition (accepted, accepted with modification, rejected, deferred, duplicate or withdrawn) in the repository's disposition log. Issues filed after October 22 are labelled post-comment and held for the next draft (comment process).

Where Mixpeek fits

Mixpeek indexes video, audio and pages from object storage and classifies them against IAB Content Taxonomy 3.1, including per scene for long video (IAB Content Taxonomy classification). For a seller writing proposals, that gives one source for the categories in content_detail and the content.cat values in the bidstream. IAB Tech Lab says AAMP 2.3 integrates contextual enrichment technology that Mixpeek donated (IAB Tech Lab, AAMP 2.3). Mixpeek does not implement OpenProposal. For how AAMP relates to AdCP, ARTF and Agentic Audiences, see AdCP, AAMP, ARTF and Agentic Audiences: what each one does.

Changelog

2026-10-19: first version, written against OpenProposal 3.0 draft 1 (repository commit 44dfaaf).

Frequently Asked Questions

What is AAMP 3.0?

AAMP 3.0 is IAB Tech Lab's release built around OpenProposal, announced on 2026-09-22 (IAB Tech Lab). AAMP (Agentic Advertising Management Protocols) is the umbrella for IAB Tech Lab's agentic standards work.

Is OpenProposal a ratified standard?

No. It is version 3.0 draft 1, in public comment until 2026-10-22. The draft says it must not be treated as a ratified IAB Tech Lab standard. After the comment period, the working group dispositions every comment and publishes a revised draft; schemas are planned after that revision.

Do I need to be an IAB Tech Lab member to comment on OpenProposal?

No. Anyone with a GitHub account can file an issue or pull request on the IABTechLab/OpenProposal repository (CONTRIBUTING.md).

How many fields does an OpenProposal have, and how many can the buyer change?

71 fields. A buyer touches 23 of them: 12 selectable, 5 settable, 3 supplied and 3 requestable. Only the 3 requestable fields need the seller to respond.

What is the difference between valid_until and flight_end?

valid_from and valid_until are the window in which the seller's offer holds. flight_start and flight_end, inside commitment, are the buyer's campaign dates. The spec marks the distinction in bold because the two are easy to confuse.

Does OpenProposal support IAB Content Taxonomy categories?

Not as a dedicated field in draft 1. Audiences carry a taxonomy_ref, but content_detail is a seller-set object with no taxonomy reference, and the targeting envelope has no content-category field. OpenRTB 2.6 carries categories downstream in content.cat with cattax.

Sources

OpenProposal 3.0 draft 1 specification

OpenProposal repository

CONTRIBUTING.md

Public comment process

Open questions

CTV line item example

IAB Tech Lab, AAMP 3.0 with OpenProposal, 2026-09-22

IAB Tech Lab, AAMP 2.3

AdCOM category taxonomies list