§ 5.3, § 5.5 — Audience: composition, disclosure, and one map of exclusions (#91, #97)

.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:
@@ -63,9 +63,8 @@ body:
         A specific case where the draft as written produces the wrong outcome or
         cannot express what you need. This is what makes a comment actionable.
       placeholder: >-
-        A seller offering the same inventory as both PG and PMP cannot express a
-        different floor per mechanism, because pricing[] sits above
-        transaction_mechanism.
+        A [seller, buyer, or agent] doing [a specific case] can't express [what it
+        needs], because [the field or rule in the draft].
   - type: dropdown
     id: perspective
     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/ISSUE_TEMPLATE/editorial.yml

@@ -12,7 +12,7 @@ body:
     id: location
     attributes:
       label: Where
-      placeholder: "spec/openproposal-3.0.md § 5.6, Appendix A row for `hold_status`"
+      placeholder: "spec/openproposal-3.0.md § 5.6, Appendix A row for `hold_terms`"
     validations:
       required: true
   - type: textarea

.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,24 @@ 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
+
+  pricing-fixtures:
+    name: Pricing arithmetic vectors
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - run: python3 scripts/check_pricing_fixtures.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 |
@@ -40,10 +40,8 @@ them, but the short version:
 
 - **Cite the section.** `§ 5.6.1 commitment`, not "the commitment bit".
 - **Say what breaks.** A concrete scenario — a seller, a buyer, a field, and the
-  wrong outcome — beats a general objection. "A seller offering the same
-  inventory as both PG and PMP cannot express different floors per mechanism,
-  because `pricing[]` sits above `transaction_mechanism`" is actionable. "The
-  pricing model is too simple" is not.
+  wrong outcome — beats a general objection such as "the pricing model is too
+  simple".
 - **Say what you'd do instead**, even roughly. A rejected alternative is more
   useful to the working group than an unanswered complaint.
 - **Declare your interest.** Tell us whether you are commenting as a buyer,

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,113 @@ 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-9 — What basis is a money value on?
+
+**Issue:** [#30](https://github.com/IABTechLab/OpenProposal/issues/30), [#115](https://github.com/IABTechLab/OpenProposal/issues/115)  ·  **Spec:** § 5.6
+
+Every `Amount` on a line item is on one basis. The draft doesn't say whether that
+basis is gross or net of agency commission, or whether it includes tax. A
+`commitment.amount` of 80,000.00 at an `agreed_rate` of 24.00 `CPM` buys 3,333,333
+impressions if 24.00 is what the seller invoices. If 24.00 is gross of a 15%
+commission, the seller invoices 20.40, and 80,000.00 stated net buys 3,921,568.
+
+**What would settle it:** how sellers and agencies state a rate today, and what the
+invoice is expected to match.
+
+---
+
+### OQ-10 — What settles a shortfall once no remedy remains?
+
+**Issue:** [#95](https://github.com/IABTechLab/OpenProposal/issues/95), [#146](https://github.com/IABTechLab/OpenProposal/pull/146)  ·  **Spec:** § 5.7.1, § 5.6.7
+
+A buyer may refuse a sole or last `makegood`, and § 5.7.1 then points at `remedy_terms`,
+whose keys describe only a makegood. The draft also doesn't state what a `credit` is
+worth. Such a shortfall could settle under terms the seller states or fall back to a
+credit, or a sole makegood within the flight could bind the buyer. Nor does the draft
+say how much delivery a preemption takes (§ 5.6.7).
+
+**What would settle it:** what sellers and buyers do today when a makegood is refused,
+how they value a credit, and how they measure the delivery a preemption takes.
+
+---
+
+### 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.