[Sirajmx]

Draft. Do not merge until the working group confirms the disposition of #25.

What this changes

A buyer can now carry its block lists into the proposal. The seller declares which exclusion types it accepts, how many entries, and how it enforces each (exclusions_accepted, seller-set); the buyer supplies its lists within that declaration (exclusions, supplied): domains, apps, content categories, keywords, or a hash-pinned list_ref for large lists. A type the seller doesn't accept is rejected, never silently ignored, and best_effort enforcement is never presented as a guarantee. Exclusions are recompute inputs (§ 3.3) and are never disclosed to anyone but the buyer (§ 5.8).

Related issue

Refs #25

Type

• Editorial — no normative effect
• Normative — changes what the spec requires
• Breaking — would break an implementation already built to this draft
• Examples / schema / docs only

Checklist

• The body section is updated
• Appendix A (field index) matches the body — two rows; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 29 → 30, supplied 3 → 4; 71 → 73 fields; buyer-touched 23 → 24; resolved without a round trip 20 → 21
• Any affected example in examples/ is updated and still parses — the display example declares and supplies lists
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — exclusions is supplied, bounded by exclusions_accepted
• No confidential or commercially sensitive content

Knock-on effects

• App identity. Blocked apps are { platform, bundle }. This goes beyond [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25 as filed, which had a flat list, and comes from the issue's discussion: @aleksUIX proposed it (a bare store id can't say whether it is a Roku or an iOS app), and @fgranata, who first preferred a flat list, agreed on 22 Oct. Both also suggested allowing a flat string where the list declares a single platform; that is not added here and is left to the working group. The platform values match those draft PR § 5.2 — App identity on properties (#15) #17 proposes for properties.available[].apps[].
• Content categories use iab_content_category[] as filed in [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25: IAB Content Taxonomy ids. Which taxonomy version to reference is for the working group. [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48 proposes a version-pinned taxonomy_ref for seller-side content categories.
• CTV example: pending. [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25 asks for the display and CTV examples to be updated, with CTV showing keyword as unsupported or best_effort. Only the display example is updated here, because draft PR § 5.2 — App identity on properties (#15) #17 also edits the CTV example; the CTV change follows once § 5.2 — App identity on properties (#15) #17 lands.
• Guaranteed enforcement is a measurement question, deferred to 4.0 ([Comment] Whole document — Feedback from the Agentic Bootcamp, 24 September 2026 #20 item 9).
• Related: [Change] § 5.2 — separate brand safety / suitability disclosure from content_detail #46 and [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48 (seller-side content signals), [Comment] § 5.2 — Support placement-specific advertising restrictions #53 (OOH placement restrictions).
• Appendix B: other open change requests also change these counts; whichever merges later recounts.

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Sirajmx, five changes to the block lists, which our audience PR carries. Shared types such as DocumentRef come from our shared types PR.

• One map per side. Four structures repeat the type keys. Our PR renames exclusions_accepted to accepted_exclusions, whose types is a Map[ExclusionType, ExclusionTerms], each { enforcement, max_entries }. exclusions is a Map[ExclusionType, ExclusionList]. ExclusionType is a VocabularyTerm, with core terms domains, apps, categories, and keywords for domain, app_bundle, iab_content_category, and keyword.
• Entries. An apps entry is an AppId { store, bundle } from our property option PR, so platform becomes store. A categories entry is a TaxonomyCodes, naming its taxonomy. A domains entry doesn't cover subdomains, and a categories id doesn't cover descendants.
• list_ref names no type, so the types rule and max_entries can't apply. Each type's value becomes an array or a DocumentRef to one, so every list has a type. The agreed record keeps the reference; its digest pins the list.
• Disclosure. "Any party other than that buyer" also bars the ad server or SSP that applies pre_serve blocking (§ 5.9 Execution), and the verification[] vendors. [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25 scoped it to the counterparty. In our PR, § 5.5 replaces it. A seller MUST NOT disclose a buyer's exclusions beyond that buyer and the systems and vendors that enforce or verify them for this line item.
• verification[] is undefined, and names such as "IAS" don't compare. Our settlement PR makes it an OPTIONAL Array[RegistrableDomain], such as integralads.com, of vendors that can attest enforcement, as [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25 had it.

Whether a seller rejects a list over max_entries is a question in the rules issue.

Our audience PR also shows keywords as best_effort in the CTV example (§ 6.3), as #25 asks.

Revised 2026-11-03: Rewritten for our audience PR; the max_entries rejection moves to the rules issue.

Analyzed and generated with the help of Claude, fully reviewed by me.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Sirajmx, our errors and extensions PR carries this PR at its head. It gives the new rows Type and Required cells and drops the catalog_ref clause.

Our audience PR then makes the block-list changes in our revised comment above.

Could you review them there?

Analyzed and generated with the help of Claude, fully reviewed by me.