§ 1.1, § 5.4, § 5.9 — Handoff to OpenDirect and the Deals API (#132, #133)

.github/ISSUE_TEMPLATE/change-request.yml

@@ -46,7 +46,7 @@ body:
         - "5.7 — Guarantees"
         - "5.8 — Transaction eligibility"
         - "5.9 — Execution"
-        - "5.10 — External references and settlement"
+        - "5.10 — External references, agreement, and billing"
         - "6 — Examples"
         - "Appendix A / B — Field index"
         - "Whole document / more than one section"

.github/ISSUE_TEMPLATE/comment.yml

@@ -34,7 +34,7 @@ body:
         - "5.7 — Guarantees"
         - "5.8 — Transaction eligibility"
         - "5.9 — Execution"
-        - "5.10 — External references and settlement"
+        - "5.10 — External references, agreement, and billing"
         - "6 — Examples"
         - "7 — Why this split"
         - "8 — Open questions"
@@ -47,7 +47,7 @@ body:
     attributes:
       label: Field(s) involved
       description: Comma-separated, if your comment is about specific fields.
-      placeholder: "pricing[].floor, transaction_mechanism"
+      placeholder: "pricing[].min_rate, transaction_mechanism"
   - type: textarea
     id: comment
     attributes:

.github/ISSUE_TEMPLATE/config.yml

@@ -8,6 +8,6 @@ contact_links:
   - name: Read the comment process first
     url: https://github.com/IABTechLab/OpenProposal/blob/main/docs/comment-process.md
     about: Timeline, dispositions, and what happens to your comment.
-  - name: The seven open questions
+  - name: The open questions
     url: https://github.com/IABTechLab/OpenProposal/blob/main/docs/open-questions.md
     about: Where the working group is genuinely undecided. Highest-value place to comment.

.github/labels.yml

@@ -10,7 +10,7 @@
   description: Proposes specific normative wording
 - name: open-question
   color: "d93f0b"
-  description: Relates to one of the 7 open questions in § 8
+  description: Relates to one of the open questions in § 8
 - name: implementation-feedback
   color: "0e8a16"
   description: From someone who built against the draft

.github/workflows/validate.yml

@@ -67,3 +67,14 @@ jobs:
           python-version: "3.12"
       - name: Check every field in the body appears in Appendix A
         run: python3 scripts/check_appendix.py
+
+  examples-match-spec:
+    name: Examples match the tables
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - run: pip install pyyaml
+      - run: python3 scripts/check_examples.py

CONTRIBUTING.md

@@ -16,15 +16,15 @@ GitHub account may file an issue or a pull request.
   thread rather than opening a duplicate, so the disposition covers one
   discussion, not five.
 - Check [docs/open-questions.md](docs/open-questions.md). If your point lands on
-  one of the seven questions the draft explicitly asks, comment there.
+  one of the questions the draft explicitly asks, comment there.
 
 ## 2. Pick the right route
 
 | Route | Use it for | Where it lands |
 | :--- | :--- | :--- |
 | **Comment** issue | Something is unclear, wrong, internally inconsistent, or missing. You are not proposing wording. | Triaged, dispositioned, logged |
 | **Change request** issue | You are proposing specific normative wording, a new field, a changed marker, or a removal. | Triaged, dispositioned, logged |
-| **Open question** comment | You are answering one of the 7 questions in § 8. | Feeds the resolution of that question |
+| **Open question** comment | You are answering one of the questions in § 8. | Feeds the resolution of that question |
 | **Implementation feedback** issue | You built against the draft and hit something. **This is the most valuable kind of comment we receive.** | Triaged with priority |
 | **Pull request** | You want to supply the exact diff for a change already discussed. | Reviewed against its issue |
 | **Discussion** | You have a question, or want to think out loud before filing. | No disposition; not part of the formal record |

README.md

@@ -15,7 +15,7 @@ server.
 | :--- | :--- |
 | **Current draft** | [`spec/openproposal-3.0.md`](spec/openproposal-3.0.md) |
 | **Comment period opens** | 2026-09-22 |
-| **Comment period closes** | 2026-10-22 |
+| **Comment period closes** | 2026-11-10 |
 | **Announcement** | [IAB Tech Lab introduces AAMP 3.0 with OpenProposal](https://iabtechlab.com/press-releases/iab-tech-lab-introduces-aamp-3-0-with-openproposal/) |
 | **Short link** | [iabtechlab.com/AAMPv3](https://iabtechlab.com/AAMPv3) (points to this repository) |
 | **How to comment** | [CONTRIBUTING.md](CONTRIBUTING.md) |
@@ -56,7 +56,7 @@ Pick the route that matches what you have to say:
 | :--- | :--- |
 | Flag something unclear, wrong, or missing | [Open a **Comment**](https://github.com/IABTechLab/OpenProposal/issues/new?template=comment.yml) |
 | Propose specific normative wording | [Open a **Change request**](https://github.com/IABTechLab/OpenProposal/issues/new?template=change-request.yml), or send a pull request against `spec/openproposal-3.0.md` |
-| Answer one of the 7 open questions | Comment on that question's [tracking issue](docs/open-questions.md) |
+| Answer one of the open questions | Comment on that question's [tracking issue](docs/open-questions.md) |
 | Report what happened when you tried to implement it | [Open **Implementation feedback**](https://github.com/IABTechLab/OpenProposal/issues/new?template=implementation-feedback.yml) |
 | Ask a question rather than raise an issue | Use [Discussions](https://github.com/IABTechLab/OpenProposal/discussions) |
 
@@ -69,15 +69,15 @@ in [docs/disposition-log.md](docs/disposition-log.md). See
 
 Three things to understand before the field tables make sense:
 
-1. **No inheritance.** Every line item is fully self-contained. A field never
+1. **No inheritance.** Every term of a line item is on the line item. A field never
    takes its value from the parent proposal or a sibling line item.
 2. **Every field carries exactly one mutability marker** (§ 3) — `immutable`,
-   `seller-set`, `selectable`, `settable`, `supplied`, `requestable` or
-   `derived`. The marker is what tells a buying agent whether it can act
-   unilaterally.
-3. **Composition is constraint satisfaction, not negotiation.** Of 71 fields,
-   only 3 require a round trip with the counterparty. That ratio is the design
-   claim the draft is asking you to test.
+   `seller-set`, `selectable`, `settable`, `supplied`, `requestable`, `derived`,
+   `lifecycle`, `recorded`, `asserted` or `mixed`. The marker is what tells a
+   buying agent whether it can act unilaterally.
+3. **Composition is constraint satisfaction, not negotiation.** Only `requestable`
+   fields require a round trip with the counterparty to resolve. Appendix B has the
+   count. That ratio is the design claim the draft is asking you to test.
 
 ## Downstream standards
 
@@ -89,8 +89,8 @@ OpenRTB 2.6). See § 1.1.
 
 Machine-readable schemas are coming. They are not published with this first
 draft, because the comment period is still deciding questions that shape
-them. They will follow the first revision, after the comment period closes on
-2026-10-22. Until then, [`examples/`](examples/) is the best reference for
+them. They will follow the first revision, after the comment period closes.
+Until then, [`examples/`](examples/) is the best reference for
 shape. See [schema/README.md](schema/README.md).
 
 ## Contributors and governance

docs/comment-process.md

@@ -8,14 +8,14 @@ or a documented decision not to change it.
 | Phase | Dates | What happens |
 | :--- | :--- | :--- |
 | **1. Comment period opens** | 2026-09-22 | Draft frozen at a tagged version. Announcement published. Issues open. |
-| **2. Comment period** | 2026-09-22 → 2026-10-22 (30 days) | Anyone may file. Maintainers triage and label within 5 business days of filing, but do not resolve. |
-| **3. Comment period closes** | 2026-10-22 | No new comments enter the formal record. Later issues are labelled `post-comment` and considered for the following draft. |
+| **2. Comment period** | 2026-09-22 → 2026-11-10 | Anyone may file. Maintainers triage and label within 5 business days of filing, but do not resolve. |
+| **3. Comment period closes** | 2026-11-10 | No new comments enter the formal record. Later issues are labelled `post-comment` and considered for the following draft. |
 | **4. Adjudication** | `TBD` → `TBD` | Working group works the queue. Every open comment gets a disposition. |
 | **5. Disposition published** | `TBD` | [disposition-log.md](disposition-log.md) published in full. Commenters notified on their issue. |
 | **6. Revised draft** | `TBD` | New draft tagged. Either ratification or a second comment period, depending on how much moved. |
 
 > **Maintainers: phases 4–6 are still `TBD`.** Fill them before the comment
-> period closes on 2026-10-22.
+> period closes.
 
 ## Dispositions
 
@@ -59,7 +59,7 @@ Triage labels, applied on filing:
 | :--- | :--- |
 | `comment` | General comment on the draft |
 | `change-request` | Proposes specific normative wording |
-| `open-question` | Relates to one of the 7 questions in § 8 |
+| `open-question` | Relates to one of the questions in § 8 |
 | `implementation-feedback` | From someone who built against the draft |
 | `editorial` | Typo, formatting, broken link — no normative effect |
 | `normative` | Changes what the spec requires |

docs/disposition-log.md

@@ -3,7 +3,7 @@
 The formal record of every comment filed during the OpenProposal 3.0 public
 comment period, and what was decided.
 
-**Status: comment period open (2026-09-22 → 2026-10-22). No dispositions yet.**
+**Status: comment period open (2026-09-22 → 2026-11-10). No dispositions yet.**
 
 This file is updated as comments are adjudicated and published in full at the
 end of the period. See [comment-process.md](comment-process.md) for what each

docs/open-questions.md

@@ -1,7 +1,7 @@
 # Open questions
 
-The draft asks seven questions it does not answer. These are the highest-value
-places to comment, because the working group is genuinely undecided.
+These are the questions the draft asks and does not answer. They are the
+highest-value places to comment, because the working group is genuinely undecided.
 
 Each has its own tracking issue, labelled
 [`open-question`](https://github.com/IABTechLab/OpenProposal/issues?q=label%3Aopen-question).
@@ -24,13 +24,15 @@ whether resolving inside one is worth the modelling cost.
 
 ---
 
-### OQ-2 — Do seller catalogs (`catalog_ref`) belong in 3.0?
+### OQ-2 — Is a fetchable reference to a seller catalog needed?
 
-**Issue:** [#3](https://github.com/IABTechLab/OpenProposal/issues/3)  ·  **Spec:** § 2.2
+**Issue:** [#3](https://github.com/IABTechLab/OpenProposal/issues/3)  ·  **Spec:** § 2.1
 
-Or should the object stay fully inline until a later version? `catalog_ref`
-buys compactness across a large shelf at the cost of a resolution step during
-discovery and a versioning regime sellers must operate.
+The object is fully inline. A seller reuses catalog entries in its own systems, and
+a summary lists what § 2.1 names. A reference a buyer could fetch would buy
+compactness across a large shelf at the cost of a fetch rule, a resolution step
+during discovery, and a versioning regime sellers must operate. A `Line.productid`
+would be one use: an agreed record doesn't say which OpenDirect `Product` it books.
 
 **What would settle it:** how large a real shelf gets, and whether sellers
 already maintain versioned, immutable catalog entries or would have to build
@@ -65,48 +67,83 @@ proposed fallback behaviour.
 
 ---
 
-### OQ-5 — Is a `min_line_items` field needed?
+### OQ-5 — Do `linked_execution` and `requires` cover bundle purchases?
 
 **Issue:** [#6](https://github.com/IABTechLab/OpenProposal/issues/6)  ·  **Spec:** § 2, § 4
 
-The draft makes proposals subsettable unless binding terms mandate linked
-execution. Does the proposal need an explicit `min_line_items` to require a
-bundle purchase, or is that left to buyer discretion and the binding terms?
+The draft makes proposals subsettable unless `linked_execution` is `all`, and a line
+item can state `requires`. Does the proposal also need a `min_line_items` field?
 
-**What would settle it:** whether sellers actually merchandise bundles that must
-be bought whole, and whether "binding terms" is a precise enough hook.
+**What would settle it:** whether sellers merchandise a bundle these two fields
+can't express.
 
 ---
 
-### OQ-6 — Should `payment_terms` and `invoicing_party` be catalog references?
+### OQ-6 — Should `payment_terms` and `invoicing_party` repeat on every line item?
 
 **Issue:** [#7](https://github.com/IABTechLab/OpenProposal/issues/7)  ·  **Spec:** § 5.10
 
-Rather than repeated on every line item, given they are usually identical across
-a seller's shelf. Note this is in tension with the no-inheritance rule (§ 2) —
-a `catalog_ref` is explicitly not inheritance, but the ergonomics are similar.
+They are usually identical across a seller's shelf. Note this is in tension with the
+no-inheritance rule (§ 2): sharing them would need another mechanism.
 
 **What would settle it:** whether `billing` genuinely varies per line item in
 practice (different supplier of record, different invoicing entity per
 property).
 
 ---
 
-### OQ-7 — `environments[]` needs validation against real inventory
+### OQ-7 — `environments.available[]` needs validation against real inventory
 
 **Issue:** [#8](https://github.com/IABTechLab/OpenProposal/issues/8)  ·  **Spec:** § 5.2
 
-The enum — `web_desktop`, `web_mobile`, `app_mobile`, `ctv`, `dooh`,
-`audio_streaming` — is proposed, not derived from implementation experience.
+The enum — `web_desktop`, `web_mobile`, `app_mobile`, `ctv`, `dooh`, each
+defined in § 5.2.1 — is proposed, not derived from implementation experience.
 
 **What would settle it:** sellers mapping their real inventory onto the enum and
 reporting what does not fit.
 
 ---
 
+### OQ-8 — How does a receiver read a document from a later release?
+
+**Issue:** [#131](https://github.com/IABTechLab/OpenProposal/issues/131)  ·  **Spec:** § 2.5, § 4.1
+
+`spec_version` names the release a document follows, and § 2.5 makes a key the
+receiver's release does not list invalid. Nothing says whether a receiver rejects a
+release it does not know, or keeps and ignores keys it does not list.
+
+**What would settle it:** how an implementer upgrades a seller and its buyers when
+they don't move at the same time, and whether unread keys can reach an assent.
+
+---
+
+### OQ-11 — Must a manifest response carry both `ETag` and `Last-Modified`?
+
+**Issue:** [#29](https://github.com/IABTechLab/OpenProposal/issues/29)  ·  **Spec:** § 2.3
+
+The draft requires at least one, so a buyer's client handles whichever the seller
+sends.
+
+**What would settle it:** which validator polling clients use, and what the hosts
+that serve the manifest send by default.
+
+---
+
+### OQ-12 — How does a `change_requests[]` entry state a change other than a cancellation?
+
+**Issue:** [#68](https://github.com/IABTechLab/OpenProposal/issues/68)  ·  **Spec:** § 4.4
+
+`cancellation` states a notice to cancel. The OpenDirect 2.1 ChangeRequest has no
+structured statement of any other change, only free-text `comments`.
+
+**What would settle it:** how sellers and buyers state a change today, and what a
+system that applies one needs to read.
+
+---
+
 ## Not on this list but worth saying
 
 If you think the draft has a problem it has not asked about, file it as a
 [Comment](https://github.com/IABTechLab/OpenProposal/issues/new?template=comment.yml) or a
-[Change request](https://github.com/IABTechLab/OpenProposal/issues/new?template=change-request.yml). The seven
+[Change request](https://github.com/IABTechLab/OpenProposal/issues/new?template=change-request.yml). The questions
 above are where we know we are undecided, not the limit of what we will consider.

docs/repo-setup.md

@@ -52,7 +52,7 @@ unchecked are outstanding.
 
 ## Tracking issues
 
-- [ ] **File the seven open-question issues** and fill the links in
+- [ ] **File the open-question issues** and fill the links in
       [`open-questions.md`](open-questions.md). Label each `open-question` and
       pin them. These are where you most want comments to land, so they need to
       exist before anyone arrives.
@@ -82,7 +82,7 @@ were closed.
 - [ ] State the closing date.
 - [ ] State explicitly that non-members may comment — otherwise most of the
       market assumes it cannot.
-- [ ] Point at the seven open questions, not just the spec. Asking a specific
+- [ ] Point at the open questions, not just the spec. Asking a specific
       question gets a specific answer; "thoughts welcome" gets silence.
 
 ## During the period

examples/line-item-audio.yaml

@@ -2,34 +2,39 @@
 line_item_id:   "streaming-audio"
 status:         published
 channel:        audio
-environments:   { available: ["audio_streaming"], included: ["audio_streaming"] }
+environments:   { available: ["web_mobile", "app_mobile"],
+                  included:  ["web_mobile", "app_mobile"] }
 formats:        { available: ["audio/host-read-30s", "audio/produced-30s"],
                   included: ["audio/produced-30s"],
-                  pricing: { "audio/host-read-30s": { delta_cpm: 9.00 } } }
+                  deltas: { "audio/host-read-30s": { delta_cpm: 9.00 } } }
 
 production:
-  available:    [{ id: "seller_built", build_owner: seller, lead_time: "10 business days" },
-                 { id: "buyer_supplied", build_owner: buyer, lead_time: "0" }]
+  available:    [{ id: "seller_built", build_owner: seller, lead_time: "P14D" },
+                 { id: "buyer_supplied", build_owner: buyer, lead_time: "P0D" }]
   included:     ["buyer_supplied"]
-  pricing:      { seller_built: { delta_flat: 12000.00 } }
+  deltas:       { seller_built: { delta_flat: 12000.00 } }
 
-frequency_cap:  { max: { min: 1, max: 6 }, period: "day", basis: listener }
+markets:                               # priced by market (§ 5.5)
+  available:    ["US", "CA", "GB"]
+  included:     ["US"]
+  deltas:       { "CA": { delta_cpm: 1.50 }, "GB": { delta_cpm: 3.00 } }
+  max_select:   3
+
+frequency_cap:  { count: { min: 1, max: 6, default: 3 }, period: day, per: listener }
+time_zone:      viewer_local
 
 pricing:
-  - { cost_method: CPM, gross_rate: 18.00, floor: 15.84,
-      price_valid_until: "2026-12-15T23:59:59Z", currency: USD }
+  - { cost_method: CPM, list_rate: 18.00, min_rate: 15.84,
+      price_valid_until: "2026-12-15T23:59:59Z", currency: USD,
+      price_type: 3 }                  # Fixed Price
 
 commitment_bounds: { min_budget: 5000.00 }
-commitment:
-  basis: spend
-  amount: 60000.00
-  currency: USD
-  flight_start: "2026-10-06"
-  flight_end:   "2026-12-21"
-  idempotency_key: "agency-a-camp1-streaming-audio-a7c33e10"
 
 committed_metrics: [{ metric: completion_rate, value: 0.92, basis: seller_reported }]
-buying_route:      SSP_PLATFORM
-transaction_mechanism: { available: ["PREFERRED_DEAL"], included: ["PREFERRED_DEAL"] }
+visibility:        public
+transaction_mechanism:
+  available:  [{ id: preferred_deal, delivery_type: non_guaranteed }]
+  included:   ["preferred_deal"]
+  max_select: 1
 serving_mode:      dai
-correlation_id:    "ep-q4-2026-commitment/streaming-audio"
+deal_origin:       "ssp-a.example"