[KonstantinMirin]

What this changes

Draft 1 can't say where in a break an ad plays, or which show or game it runs in. Nor can it name the audio feed, or say if the ad is recorded into the content.

• placement gets a Placement key table (§ 5.2.2), with feed and ssai. It is REQUIRED on a video or audio line item, and plcmt on video.
• New § 5.2.3 sells pre-roll, mid-roll, and pod slots as priced break_position options, which availability recomputes against (§ 3.3).
• New § 5.2.9 makes programs and live events selectable, with AdCOM Content and a LEAP EventSchedule. It says what happens when an event doesn't air.
• content_detail is removed. episodes is its own field, REQUIRED on a podcast or catch-up radio feed.
• § 5.9 defines dai, scheduled, and embedded for every channel, and the rules for an embedded line item. A buyer can ask for an embedded line item's retention, from @jaanijuk and CRA.
• § 4.1: RequestedValue gains retention, so a request can carry the retention it asks for.
• creative_delivery.protocols[] takes AdCOM Creative Subtypes codes, and other_protocols[] takes terms. They replace protocol and third_party_tags.
• ProductionOption loses cost, since deltas prices a build, and build_owner becomes built_by.
• § 1.1 maps a ctv line item that carries plcmt to adtypes 2. New § 6.10 and § 6.11 show an embedded podcast and a live event series.

Related issue

Closes #99. Closes #100. Closes #101.

Refs #89, #120, and #121.

Builds on

This PR builds on our placement PR (#120), which merges first, and our DOOH PR. It builds on our settlement PR, our pricing PR, our handoff PR, our post-agreement PR, and our holds PR. Those build on our signing PR, buyer writes PR, lifecycle PR, parties PR, errors and extensions PR, and shared types PR. Through them it carries #18, #70, #71, and #72 by @Sirajmx, #73 to #76 by @Kishore-2572, and #117 and #118 by @aleksUIX. Review the commits "Define video and audio placement, programs, and break position", "Name the advertiser in the embedded podcast example", "Let a buyer ask for a retention", "Count retention among the requestable fields", "Let a request carry the retention it asks for", and "Record the video and audio changes the changelog left out".

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 — § 1.1, § 2.1, § 2.6, § 3.3, § 4.1, § 4.1.1, § 5.2, § 5.2.2, new § 5.2.3, new § 5.2.9, § 5.4, § 5.6.4, § 5.7, § 5.7.1, § 5.9, § 6.3, § 6.4, § 6.7, new § 6.10 and § 6.11, and § 7
• Appendix A (field index) matches the body — rows for programs, episodes, break_position, and retention; content_detail and third_party_tags removed; placement and controlling_measurement rows updated. scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body. selectable goes from 14 to 16, and the field count from 97 to 99. seller-set goes from 47 to 46: episodes in, content_detail and third_party_tags out. requestable goes from 5 to 6 with retention.
• Any affected example in examples/ is updated and still parses — new line-item-podcast-embedded.yaml (§ 6.10) and line-item-ctv-live-series.yaml (§ 6.11). line-item-rewarded-video.yaml (§ 6.7) uses the current field names. The CTV examples gain placement.ssai and serving_mode: dai, § 6.3 gains priced break_position options, and the audio example gains placement.feed. Both record_digest values are recomputed, and manifest.json is regenerated. scripts/check_examples.py checks tentative events and the embedded rules, and passes. scripts/check_pricing_fixtures.py passes 60 of 60
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — every new field sits on the line item
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — programs and break_position declare both; no new settable fields
• No confidential or commercially sensitive content

Knock-on effects

• Breaking. A record with content_detail, third_party_tags, creative_delivery.protocol, production.available[].cost, build_owner, serving_mode client_side or ssai, or source_type 0 no longer conforms. A video or audio line item needs placement, with plcmt on video and feed on audio. An embedded line item needs retention and controlling_measurement.
• Filings this answers. @esteininger on #101 supports feed and episodes. Here episodes leaves free-text content_detail. Their per-episode categories stay with [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48.
• Changes from the filed text.
  • [Change] § 5.2 — Make programs and live events selectable, and say what happens when one doesn't air #100: AdCOM keys nest under content, and schedule takes Instant times. Over OpenRTB 2.6, content values take OpenRTB key names, such as livestream. episodes stands alone, answering [Change] § 5.2 — Make programs and live events selectable, and say what happens when one doesn't air #100 question 5 and [Change] § 5.2, § 5.9 — Audio: name the feed, and say when an ad is recorded into the content #101 question 3.
  • [Change] § 5.2, § 5.9 — Audio: name the feed, and say when an ad is recorded into the content #101: serving_mode has three core terms, and placement.ssai states server-side insertion. An embedded line item omits markets.
  • § 2.1, § 5.2 — Placement: what each impression is (#89) #120: plcmt is REQUIRED only on video. On ctv its presence states video, answering its question 7. placement moves to § 5.2.2, and the OM SDK rule reads measured_by. reward, instl, and skip take IntegerFlag, and § 6.5 becomes § 6.7.
  • [Impl] A schema can't be derived from the tables yet: seven authoring rules and a CI lint would fix that #121: placement and refresh gain key tables, as its rule 2 asks.
• Sibling and later PRs. Our property option PR adds § 5.2.4 to § 5.2.8, so programs is § 5.2.9. Our formats PR reconciles the two with our audience PR.

Open questions

1. [Change] § 5.2 — Sell break position and pod slot as priced options: pre-roll, mid-roll, first in pod #99 questions 1 to 5, [Change] § 5.2 — Make programs and live events selectable, and say what happens when one doesn't air #100 questions 1 to 4, and [Change] § 5.2, § 5.9 — Audio: name the feed, and say when an ad is recorded into the content #101 questions 1, 2, 4, 6, and 7 stay open. § 6.4 answers [Change] § 5.2, § 5.9 — Audio: name the feed, and say when an ad is recorded into the content #101 question 5 as proposed, with Music streaming service (1).
2. final_after is OPTIONAL. Without it, § 5.9 sets no end to post-flight counting on an embedded line item, and § 5.7.1 leaves that to terms_refs[]. Should embedded require final_after? This extends [Change] § 5.2, § 5.9 — Audio: name the feed, and say when an ad is recorded into the content #101 question 4.
3. Without placement.feed, as on a video line item, every copy the seller distributes counts toward delivery under retention. Should an embedded video line item name which copies count?
4. What does a seller promise by writing ssai: 0, which AdCOM defines as status unknown?

---

Contribution Terms

• I have read and agree to the Contribution Terms in CONTRIBUTING.md, including the patent license, on behalf of myself and any entity I represent.

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