[KonstantinMirin]

What this changes

Draft 1 doesn't say what two pricing[] entries mean or which currency applies. Its cancellation and exclusivity options have no keys.

• pricing[] entries are alternatives, named by pricing_id, and the buyer commits under one (§ 5.6). An entry can name the mechanisms it prices.
• § 5.6.5 states the sign of agreed_rate, and a list_rate counter can change included[] (§ 4.3.1), from @aleksUIX. separation adds location, and @premesh's asks add paid_zone and a line item's preemption, with its remedy. A demographic term states co-viewers and unknown age.
• § 5.6.5 opens cost_method, with ten core terms and the unit each counts (FLAT has none). It defines derived_units, the seller total, and FLAT and TIME figures.
• action_type's core terms are the ECAPI 1.0 event_type values in its Standard Events and Additional Events tables, as @franks33 proposes on #80, other than custom.
• A CPA entry MAY name action_definition, a DocumentRef to the rules that make an action billable: the evidence that confirms it, which content or context gets credit, and how cancellations, returns, fraud, and duplicate reports change the count. @monjerillc asked for it on #80.
• A TIME entry's derived_units is the flight rounded to the nearest whole rate_unit, half up, so a daylight-saving change inside the flight doesn't change it, from @jaanijuk's desk test.
• A TIME entry with rate_unit day MAY name a calendar_zone, which is absent on any other rate. derived_units then counts each calendar day in that zone that the flight touches, and delivery each such day the line item runs, from @jaanijuk's Sydney desk test.
• A rate reads in its entry's CurrencyCode, and other amounts in the committed entry's, so commitment.currency and min_commitments[].currency go. Our packages PR moves min_commitments[].
• Every line-item Amount shares one basis, which § 8 question 9 leaves open.
• commitment_bounds.spend replaces min_spend and the budget keys, and pricing[].unit_bounds the impression keys, in the entry's unit.
• § 5.6.6 defines the cancellation option and its CancellationNotice; § 5.6.7, the exclusivity option.

Related issue

Closes #94. Closes #98. Both are ours.

Refs #115, #30, #127, #125, #121, #117, #70, and #80.

Builds on

This PR builds on our holds PR and our handoff PR, and through them on our post-agreement PR, our signing PR, our buyer writes PR, our lifecycle PR, our parties PR, our errors and extensions PR, and our shared types PR. It carries #18, #70, #71, and #72 by @Sirajmx, #73, #74, #75, and #76 by @Kishore-2572, and #118 by @aleksUIX. Review the #117 merge, the holds and handoff merges, and the commits "Define pricing alternatives, money, bounds, and cancellation", "Apply the review of the pricing text", "Add paid_zone to separation, and let a line item state its preemption", "Let a preemptible line item yield to a later exclusivity term", "Hold the decline rule until preemption notice runs, and keep shortfalls whole", "Say what the preemption carve-out covers with no notice period", "Let preemption state its remedy", "Round TIME units to the nearest whole unit", "Round a half unit up in TIME", "Take the core CPA action types from ECAPI 1.0", "Let a day rate count calendar days in a named zone", "Take CPA action types from both of ECAPI's event tables", "Record the pricing changes the changelog left out", "Let a CPA entry name the rules that make an action billable", "Check calendar_zone and action_definition on every pricing entry", "Report a calendar_zone with no rate_unit at its object", and "Keep checking a commitment whose cost_parameters isn't an object".

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.2, § 2.4, § 2.5, § 3.1 to § 3.4, § 4.1, § 4.3, § 4.3.1, § 4.3.2, § 4.3.4, § 4.4, § 5.6, § 5.6.1, § 5.6.3, new § 5.6.5 to § 5.6.7, § 6, § 8, and docs/open-questions.md OQ-9
• Appendix A (field index) matches the body — pricing_id, rate_per, unit_label, cost_definition, cost_parameters, transaction_mechanisms[], and unit_bounds added under pricing[], preemption added, and min_spend removed. Rates are Amount, currency is a CurrencyCode, and availability, commitment_bounds, and exclusivity are typed. scripts/check_appendix.py passes, with Availability, CancellationOption, ExclusivityTerm, MinCommitment, and CancellationNotice off the pending list
• Appendix B (fields by marker, and the counts) matches the body — immutable 9 → 10, seller-set 40 → 45, requestable 4 → 5; 87 → 94 fields
• Any affected example in examples/ is updated and still parses — the renames throughout, and flight bounds. Display shows USD and EUR alternatives, and audio shows priced exclusivity. Display, CTV, and audio offer cancellation options, and the issued proposal records a partial cancellation. Both record_digest values are recomputed, and manifest.json is regenerated. scripts/check_examples.py recomputes the commitment arithmetic, the bounds, and the cancellation shares, 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 key sits on the line item or its pricing[] entry
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — cancellation_policy and exclusivity keep both; the commitment bounds are commitment_bounds.spend and unit_bounds
• No confidential or commercially sensitive content

Knock-on effects

• Breaking. Removed keys no longer conform. Each entry needs a pricing_id. availability renames type and as_of, drops basis, and requires window.
• What this completes. Availability types our holds PR's held_availability, and CancellationNotice our post-agreement PR's cancellation. Our handoff PR's totals read the seller total, and Line.ratetype maps CPMV and daily TIME.
• What later PRs complete. Our DOOH PR adds § 5.6.4, and our video and audio PR removes ProductionOption.cost. Our settlement PR adds the mrc term and reads shortfalls against these bounds.
• Account for seller fees after selecting one price #117. @aleksUIX's fixtures, adapter, and discussion document take the spec's names. A granted rate is the next version's list_rate, so accepted_counter and selection_key go.
• CONTRIBUTING.md and the comment template drop the PG and PMP floor scenario.
• Filings this answers.
  • @EvgenyAndroid's evidence on #94 backs the alternatives and pricing_id. derived_units rounds down, the first rule they offered.
  • loop and install_date are core terms, as @premesh asked on #98. unit_periods counts their [Comment] § 5.2 Static OOH: posting cycles, printed material, install lead time and proof of posting #125 posting cycle.
  • A spend includes delta_flat charges, answering @dineshbhat's [Change] § 5.6.1 — State what commitment.amount includes (rate basis, third-party fees, tax) #115 and @aleksUIX on #30.
• Changes from the filed text.
  • [Change] § 5.6 — Give cost_method an extensible vocabulary, and say what several pricing[] entries mean #94: pricing[].unit becomes unit_label, and cost_definition a DocumentRef. Only unit bounds move into each entry (question 1).
  • [Change] § 5.6 — Give cancellation_policy and exclusivity options a typed shape #98: notice_period, fee[], basis, rate, before_start, periods[], and flight_start become notice_duration, fees[], calculation, share, before_reference, dated_shares[], and flight. cattax becomes taxonomy, and start and end become window.

Open questions

1. Answered by @aleksUIX. A counter on a composed rate needs no separate final rate: list_rate carries it, with the negotiated options in included[], so a counter may change both. Dropping accepted_counter and selection_key stands.
2. Yes, answered by @aleksUIX. § 5.6.5 states the rule, and scripts/check_examples.py flags a spend commitment with no rate.
3. Should a CancellationNotice name the dated_shares[] entry it cancels under?
4. [Change] § 5.6 — Give cost_method an extensible vocabulary, and say what several pricing[] entries mean #94 questions 3 and 4, and [Change] § 5.6 — Give cancellation_policy and exclusivity options a typed shape #98 questions 1, 3, 5, and 6, 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.

[jaanijuk]

Thanks, @KonstantinMirin, for adding calendar_zone. The fixtures are here, in a secret gist, so feel free to share the link: https://gist.github.com/jaanijuk/945498af2f9ddb0b510fccc10c6cc4bd

It has 30 synthetic line items and a README with the results:

• billable-day-* (13 files): the ones behind the table on this PR, unchanged.
• calendar-zone-* (17 files): new, built on the stack's display example, to test calendar_zone.

I ran them at 6d5a6f9b, the head of op30-packages, with scripts/check_examples.py unmodified, on Python 3.13 and 3.10 with identical output:

• The five flights from our table give 1, 2, 2, 2 and 3 days. Writing the 18:00 to 06:00 flight as 1 unit is rejected.
• calendar_zone with hour or week, and an invalid zone name, are rejected.
• A flight across the 4 April Sydney clock change counts 3 days, where the elapsed rule gives 2.
• The billable-day-* files give the same results as at 43f4c72.

One thing the files turned up. An Interval's end is the last second, inclusive, so a flight that runs to the end of Monday ends at 23:59:59 and counts one day (calendar-zone-d14). The same flight written with an end of exactly Tuesday 00:00:00 passes the checker and counts Tuesday too (calendar-zone-d13). That follows from the text. But a midnight end is an easy habit to carry over from systems with exclusive ends, and with calendar_zone it adds a billable day with no diagnostic. Would a sentence beside calendar_zone pointing at the inclusive end be worth adding?

These show what the checker does. They don't test what makes a delivered day.