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-23: version 3.0 draft 1, published for public comment on 2026-09-22. The repository README lists the comment period as closing on 2026-10-22, and 85 issues and 14 pull requests had been filed by then (README). 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.

A worked example: matching three briefs to line items

To see how far the draft's fields go, we built a small shelf of 11 line items from four fictional sellers, in the shape of the spec's examples, and matched three briefs against it on 2026-10-19. Each line item's content_detail was classified into IAB Content Taxonomy 3.1, items were ranked against the brief by meaning, and the hard constraints were checked the way the spec composes a proposal: channel, commitment_bounds.min_budget, and the offer window against the flight.



Three things came out of it. The betting show is semantically close to a football brief, and only its category marks it as gambling, which free-text content_detail cannot carry reliably. A semantic score alone over-matches: some items passed every constraint with no shared category, so a matcher should say which fields drove each match. And category quality matters, since one running podcast was classified as Extreme Sports and Climbing, close but not right.

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?

What commenters asked to change

Read from the public IABTechLab/OpenProposal repository on 2026-10-23: 85 issues and 14 pull requests from 17 GitHub accounts. Each issue is counted once, under the first theme its title matches; the counts come from titles, so read the linked issues before relying on any one of them.



Most-cited sections of the draft, by issues that name them in the title:

§ 5.2 (23), § 5.6 (20), § 4.1 (12), § 5.3 (8), § 5.5 (6), § 5.7 (5), § 5.1 (5), § 5.4 (5).

Out-of-home: screens, venues and plays

Out-of-home sellers filed the most channel-specific comments. They ask for OOH as its own channel next to DOOH (#49); printing, installation and removal terms for static faces (#78); availability and reservation of physical inventory (#77); share of voice and loop constraints (#79); a definition of a play, and of who supplies the multiplier that turns plays into impressions (#92); and DOOH properties described by venue type, screens, operating hours and loop (#96). On the format registry thread, a US out-of-home media owner listed what a dooh/* entry needs: resolution and orientation per screen type, whether motion is allowed, a maximum duration that fits the slot, and file type (#5).

None of these says what else plays in the loop next to the ad. A screen that runs news headlines and one that runs sports highlights look the same in the proposal. The content_categories field proposed for § 5.2 (#48) would let a DOOH seller declare it, with classification.method set to model when the categories come from classifying the loop itself.

Audio: feeds, episodes and recorded ads

The audio filing asks for the AdCOM feed type on every audio line item (music streaming, broadcast, podcast, catch-up radio and the rest), whether a podcast buy covers new episodes, the back catalog or both, and a serving_mode of embedded for ads recorded into the content, with a retention window (#101). On the registry thread, a broadcaster separated produced spots, which are files with duration and loudness specs, from host-read ads, which are scripts and talking points (#5).

What an episode is about is still free text in content_detail. For a catalog buy that matters more than for a live one: the episodes already exist, so their topics can be classified from the audio before the buyer commits. Mixpeek does that against IAB Content Taxonomy 3.1 (IAB Content Taxonomy classification).

How to comment

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. The comment process says issues filed after the close date are labelled post-comment and held for the next draft (comment process). Check the README for the current close date before filing.

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-23: "What commenters asked to change", a digest of the 85 public issues by theme and section, with out-of-home and audio subsections; status lines dated 2026-10-23.

2026-10-19: worked example matching three briefs to line items.

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, published for public comment on 2026-09-22; the README lists the close as 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