Repository navigation
Scheduled media: booking rounds and expected confirmation time #8010
Description
Problem
A lot of scheduled media is not booked "now". It is booked in rounds on a published calendar.
Dutch linear TV is a clear example. For each airing month:
- buying opens on a fixed date;
- the first request round closes about eight days later;
- the sales house confirms orders about two weeks after that.
Requests after the first round are still accepted, but at a different price index and without a placement guarantee. Other TV markets, radio and print have similar cycles.
AdCP has the pieces for single deadlines but not for a round:
installment.deadlines.booking_deadlineanddeadline-policy.booking_lead_dayssay when booking closes for an installment. They don't say when it opens, when the seller will confirm, or what happens to a request made after the round closes.create_media_buycan returnsubmittedwith atask_id, which is right for a request the seller confirms later. But the buyer has no way to know when the confirmation is due, so it can only poll.
A buyer agent therefore cannot plan "submit before the round closes, expect confirmation on the 20th, put the creative in by the material deadline". Nor can it explain to a person why a buy made today won't be confirmed for two weeks.
Proposed shape
- Product or collection: booking rounds. An optional
booking_rounds[], each with:covers(the airing window, for example a month)opens_atrequest_deadlineconfirmation_expected_atlate_requests:accepted | accepted_without_guarantee | rejected, with an optional reference to the price adjustment that applies, per RFC: declare price adjustments for buyer-selectable product dimensions #7659
create_media_buysubmitted response: an optionalexpected_confirmation_at, so the buyer can schedule a check instead of polling.
Relationship to other work
- Delivery evidence gaps for scheduled and offline channels: change cutoff, package installment selection, cinema and print proof #7777 gap 1 covers when a stop or change takes effect (the traffic cutoff). That is the other end of the same calendar, and the two should share vocabulary.
- RFC: pDOOH booking horizons and finite loop contention #7620 covers pDOOH booking horizons, which is a similar problem with a different inventory model.
Milestone: 3.3.0.
Activity
bokelley commentedon Oct 8, 2026
WG decision brief (3.3)
Split. (1)
expected_confirmation_aton submitted envelopes: PR #8016, small, stable optional, proposed for 3.3. (2)booking_rounds[]: draft sketch in PR #8022 (experimental), default 3.4 unless the WG agrees quickly. Scope freeze is about a week out, and the round shape has two adopters (the Dutch linear TV pilot, O-N-X) and no field experience.Decisions needed
expected_confirmation_atin 3.3 as stable? Recommend yes. One optional date-time, "estimate, not a commitment",x-added-in: 3.3.0. It is useful beyond TV (IO signing, manual review) and does not depend on the round design. It is oncreate_media_buy,buy_productsandaccept_proposal, not on the shared compact envelope.update_media_buy's submitted envelope (changes confirm on the same calendar, pairs with Delivery evidence gaps for scheduled and offline channels: change cutoff, package installment selection, cinema and print proof #7777) in 3.3 if cheap. Exposing the estimate onget_task_statusfor non-terminal tasks waits for 3.4.booking_rounds[]in 3.3 or 3.4? Recommend 3.4, and ship it experimental then. feat(schema): selection-dependent price_adjustments on fixed-price pricing options #7955's own brief already defers late-booking surcharges tied to rounds to 3.4, and the price piece (Q5) is where the open design is. If the WG wants it in 3.3, feat(schema): draft booking_rounds on product for scheduled media (experimental) #8022 is a starting point, not a finished spec.Product. Recommend product-level for now, with a stableround_idand only the open and next rounds listed. A shared seller-level calendar that products reference is better long term, since the calendar belongs to a sales house, not a product. Collections don't fit because products span them. Revisit with the pilot's real product count.price_adjustmentsrows are evaluated at the purchasestart_timeand priced by selection. Recommend: in the sketch,late_request_pricing_option_idpoints at an ordinary pricing option on the same product, so the price stays insideterms_digest. For 3.4, add a round-keyed dimension to theprice_adjustmentstable. Note: feat(schema): selection-dependent price_adjustments on fixed-price pricing options #7955 does carryindexandpremiumkinds, but they cannot express lateness today.submittedis returned. A later confirmation must not reprice.round_id, a late flag and the effective guarantee on the accepted media buy. Otherwiseaccepted_without_guaranteeon aguaranteedproduct leaves terms that contradict the product. The downgrade must be visible before commitment.coverswindow (same rule feat(schema): selection-dependent price_adjustments on fixed-price pricing options #7955 uses for price windows); otherwise the buyer splits the buy. Iscoversa plain date range in the seller's timezone, or datetimes? TV broadcast days don't end at midnight.booking_deadline(hard close) on the round now, and ask the pilot whether a distinct second round exists in practice.expected_confirmation_ateverywhere (matches feat(schema): add expected_confirmation_at to submitted media-buy envelopes #8016),request_deadlinefor the soft close,booking_deadlinefor the hard close (matchesinstallment.deadlines), andchange_cutoff(Delivery evidence gaps for scheduled and offline channels: change cutoff, package installment selection, cinema and print proof #7777) reused unchanged if rounds ever carry it. The enum islate-request-handling, not "policy", to avoid colliding withdeadline_policy.PRODUCT_EXPIREDis the nearest). Needs the normal error-code process before any normative text.Not blocking: #7620 (pDOOH booking horizons) has a different inventory model and should stay separate; the sketch has no compliance vectors or storyboard yet.
feat(schema): add expected_confirmation_at to submitted media-buy env…
feat(schema): draft booking_rounds on product for scheduled media (ex…
bokelley commentedon Oct 31, 2026
Part of this shipped:
expected_confirmation_aton submitted envelopes, in #8016, #8104 and #8203 (all 3.3.0-beta.0).booking_rounds[]is #8022, an unmerged draft with 3.4 as the stated default and no decision to pull it into 3.3 (#8010 (comment)). Per the WG rule ('anything not decided moves to 3.4') only the booking rounds move to 3.4. Objections by Fri 2026-11-06. The milestone stays 3.3.0 for now; it will be moved after Nov 6.