[Change] § 5.2 — separate brand safety / suitability disclosure from content_detail #46

What kind of change?

Add a new field

Which section?

5.2 — Inventory composition

Current text

| properties     | Object | selectable | available[] of { id, name, domains, supported_formats }, included[], pricing, max_select |
| content_detail | Object | seller-set | Shows, series, sections, network verticals |
| environments   | Object | selectable | available[] from web_desktop | web_mobile | app_mobile | ctv | dooh | audio_streaming |

Proposed text

1. Add a row to the section 5.2 table:

| content_safety | Object | selectable | disclosure_level, plus available[] of { id, framework_ref, suitability_floor, category_exclusions[], classification_provider }, included[], pricing, max_select. See content_safety below. |

2. Add the following block beneath the section 5.2 table:

content_safety

Declares the brand safety and suitability profile of the inventory, independently of content identity.

• disclosure_level (Enum, seller-set, REQUIRED): content_identified | suitability_only | unclassified. One value per line item. content_identified means content_detail is populated and content_safety describes that content. suitability_only means the seller discloses suitability but not content identity. unclassified means the seller has no suitability classification for this inventory.
• available[] follows section 3.1. Each option is { id, framework_ref, suitability_floor, category_exclusions[], classification_provider }. included[], pricing and max_select key on id as for every other selectable field.
• framework_ref (String, REQUIRED per option): a version-pinned reference to a published brand safety and suitability category set, in the form <publisher>/<framework>@<version>. This specification MUST NOT hardcode the taxonomy. Two options on the same line item MAY reference different frameworks.
• suitability_floor (String, REQUIRED per option): a tier identifier drawn from the referenced framework. The set of valid values is defined by the framework, not by this specification.
• category_exclusions[] (Array[String], OPTIONAL): category identifiers drawn from the referenced framework that the seller excludes from the inventory for this option. MAY be empty.
• classification_provider (String, REQUIRED per option): seller_self or the name of the third party that performed the classification.
• When disclosure_level is suitability_only or unclassified, the seller MAY leave content_detail empty. A buyer agent MUST be able to evaluate content_safety without resolving content identity.
• When disclosure_level is unclassified, available[] and included[] MUST be empty.

3. Consequential edit to section 2.1 Summary Representation, after the MUST-contain list:

content_detail MAY be empty when the line item carries content_safety with disclosure_level of suitability_only or unclassified.

Worked example (proposed for section 6.3, CTV line item)

Today, a CTV seller that withholds titles ships section 5.2 as:

properties:     { available: [{ id: "weather-app" }], included: ["weather-app"] }
environments:   { available: ["ctv"], included: ["ctv"] }
# content_detail omitted: titles withheld for rights reasons.
# A buyer agent with a suitability floor has nothing to evaluate.

With content_safety, the same seller, still withholding titles:

properties:     { available: [{ id: "weather-app" }], included: ["weather-app"] }
environments:   { available: ["ctv"], included: ["ctv"] }
# content_detail still omitted. Permitted because disclosure_level is suitability_only.

content_safety:
  disclosure_level: suitability_only
  available:
    - { id: "cs-medium", framework_ref: "iabtechlab/brand-safety-suitability@1.0",
        suitability_floor: medium_risk,
        category_exclusions: ["adult_explicit", "arms_ammunition", "crime_harmful_acts"],
        classification_provider: seller_self }
    - { id: "cs-low-3p", framework_ref: "iabtechlab/brand-safety-suitability@1.0",
        suitability_floor: low_risk,
        category_exclusions: ["adult_explicit", "arms_ammunition", "crime_harmful_acts",
                              "death_injury", "hate_speech", "terrorism"],
        classification_provider: examplevendor }
  included: ["cs-medium"]
  pricing:  { "cs-low-3p": { delta_cpm: 1.50 } }
  max_select: 1

A buyer agent with a medium-risk policy takes the default at the base rate. One with a low-risk, third-party-classified policy selects cs-low-3p at +1.50 CPM. Both resolve without a round trip. A seller with no classification declares disclosure_level: unclassified with empty available[], and an agent with any floor skips it deterministically rather than inferring from a sparse content_detail. The content_identified case is the same object with content_detail populated, so the buyer can verify the claim against named content.

Why

Today section 5.2 conflates two things a buying agent treats differently: the identity of content (content_detail: show, title, section) and its suitability profile. Many sellers will not disclose content identity pre-transaction (user-generated and premium catalog inventory where title is withheld for rights or competitive reasons) but are willing to disclose suitability attributes. A buyer agent with a suitability floor has no field to read, so it either over-blocks a seller that left content_detail sparse, or transacts blind and relies on post-bid verification. This field lets a seller express "I will negotiate on suitability but will not expose show or title" (disclosure_level: suitability_only), which a buyer agent can act on deterministically.

Knock-on effects

• Appendix A and Appendix B: new field must be added to both (body is normative, appendices are generated from it and must not drift).
• Section 6 examples: at least one example should show a suitability_only line item.
• No-inheritance rule: unaffected. content_safety sits on the line item and is self-contained like every other field.
• Section 3 "resolves without a round trip" guarantee: preserved. A taxonomy_ref for framework_ref follows the existing catalog_ref pattern; if the seller inlines the value, the buyer evaluates it without a round trip, consistent with pricing.floor being evaluable inline.
• Downstream: aligns with OpenRTB brand safety / content category signals (content category and objectionable-content fields) without requiring OpenRTB changes; this is the pre-transaction equivalent.

Would this break an implementation already built to this draft?

No — additive or editorial

Alternatives you considered and rejected

1. Overload content_detail with suitability attributes. Rejected: it keeps identity and suitability in one field, so a seller cannot withhold identity while disclosing suitability, which is the exact case that needs solving.
2. Put suitability in the non-normative best_for[] / not_suitable_for[] advisory fields. Rejected: those are explicitly "never the basis for a match," so a buyer agent cannot transact on them.
3. Leave it to post-bid verification. Rejected: that moves the decision out of the proposal and back into reconciliation, which is what the spec is trying to avoid.

You are commenting as

DSP

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This contains no confidential or commercially sensitive information.