[KonstantinMirin]

What this changes

Draft 1 sells DOOH, but doesn't say what a screen, a play, or an impression is, or whose multiplier turns plays into impressions. This PR states each.

• When channel is dooh, a property is a set of screens of one venue type (§ 5.2). It carries venue_type, allocation, min_screens, screens[], slots_per_loop, and sync_groups[].
• frequency_cap.per becomes a VocabularyTerm with the core term screen (§ 5.5).
• New § 5.6.4 defines a play and an impression. delivery_counting, REQUIRED on a dooh line item, holds the play tolerance, proof of performance, partial-play credit, and the multiplier. A line item that counts only plays needs no multiplier.
• The committed quantity is in the committed entry's unit, so PLAY commits plays and CPM commits impressions.
• The multiplier's source controls the count of impressions, and counted_by names that source. § 5.7.1 adds the count term impressions.
• A loop_time share derives from the loop and requires allocation: all. A domination is guaranteed with sole exclusivity (§ 5.9).
• Summaries carry venue_type and the multiplier's type and source (§ 2.1). New § 6.9 shows a DOOH line item.

Related issue

Closes #92. Closes #96.

Refs #79 and #134.

Builds on

This PR builds on our settlement PR and, through it, on:

• Our pricing PR
• Our handoff PR
• Our post-agreement PR
• Our holds PR
• Our signing PR
• Our buyer writes PR
• Our lifecycle PR
• Our parties PR
• Our errors and extensions PR
• Our shared types PR

Through them it carries #18 and #70 to #72 by @Sirajmx, #73 to #76 by @Kishore-2572, and #117 and #118 by @aleksUIX. Review "Define DOOH properties, plays, and what a commitment commits" and the two DOOH commits after it.

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 — § 2.1, § 2.2, § 2.6, § 3.3, § 5.2, § 5.5, § 5.6, new § 5.6.4, § 5.7.1, § 5.9, and new § 6.9
• Appendix A (field index) matches the body — one row, delivery_counting seller-set; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 45 → 46; 95 → 96 fields
• Any affected example in examples/ is updated and still parses — new line-item-dooh.yaml (§ 6.9): CPM on looped screens, with a vendor multiplier and no count that repeats commitment. manifest.json doesn't change, because the example isn't public. scripts/check_examples.py reads the new paths, checks counted_by against the multiplier's source, 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 — delivery_counting sits on the line item, and the DOOH keys on each property option
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — no new selectable or settable fields; frequency_cap keeps its bounds
• No confidential or commercially sensitive content

Knock-on effects

• Breaking. A dooh line item built to draft 1 lacks delivery_counting, and its properties lack venue_type. A property needs screens[] unless its allocation is seller_allocated.
• Filings this answers.
  • Sync groups follow @premesh on #92, and partial_play_credit their follow-up, with pro_rata divided as they answered. One proof_of_performance with typed evidence follows their #125 proposal.
  • @premesh on #79: a pooled product and a fixed loop are different products, so under seller_allocated a buyer doesn't pick screens. A domination is modeled as they suggested.
  • On [Impl] DOOH line items have no standardized fields for venue, screens, spot and loop length, share of voice or impressions per play #134, @premesh derives a loop_time share and names its eligible screens. § 5.9 states both.
  • @jaanijuk's evidence on #96 backs screen as a core term. Their [Impl] DOOH line items have no standardized fields for venue, screens, spot and loop length, share of voice or impressions per play #134 test finds fields here for venue, screens, loop, and impressions per play.
  • @clerongi's [Comment] § 5.2, § 5.6 — Support share-of-voice and digital screen loop constraints #79 asks for loop constraints. § 5.2 derives plays from the loop and slot.
• Changes from the filed text.
  • [Change] § 5.6, § 5.7 — DOOH: define a play, and whose multiplier turns plays into impressions #92: impression_multiplier nests inside delivery_counting. sourcetype becomes source_type, logged_by a Measurer, and evidence[] a VocabularyTerm. A restatement counts until the count is final, which answers question 2.
  • [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96: slots and sync_group become slots_per_loop and sync_group_id, and screen joins per, formerly basis. "The committed quantity follows the product" gives way to the committed entry's unit.
• What later PRs of ours complete.
  • Our property option PR gives the property, screen, loop, and sync group keys their own tables. Here they stay a list under the properties row.
  • Our video and audio PR links source_type to its AdCOM list and excludes Unknown (0).

Open questions

1. What does a delivered FLAT day count on dooh: plays, or impressions? Does a FLAT entry on seller_allocated need an impression_multiplier?
2. [Change] § 5.6, § 5.7 — DOOH: define a play, and whose multiplier turns plays into impressions #92 questions 1, 3, 4, and 5, and [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96 questions 1 and 3 to 9, stay open.

---

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

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