feat(compliance): make media-buy baseline delivery-mode aware #7852

Activity

1. bokelley

   added

   claude-triagingTriage routine is actively working on this issue (1-3 min)Triage routine is actively working on this issue (1-3 min)

   on Oct 1, 2026
2. bokelley

   added this to the 3.1.x milestone on Oct 1, 2026
3. bokelley commented on Oct 1, 2026

   

   bokelley

   on Oct 1, 2026

   ContributorAuthor

   More actions

   Triage

   Classification: Feature request / spec-adjacent enablement
   Bucket(s): compliance-suite, media-buy
   Status: ready-for-human
   Milestone: 3.1.x

   What the experts said:

   • ad-tech-protocol-expert: Gap confirmed — base storyboard hardcodes delivery_type: non_guaranteed fixtures and captures media_buy_id unconditionally in context_outputs; a submitted response has no media_buy_id. Fix splits: new additive media_buy_seller_guaranteed baseline is patch-eligible (3.1.x); modifying the base create_buy phase is not (3.2.0). No wire or schema changes needed — the protocol already supports all three create-media-buy response arms.
   • code-reviewer: sales_guaranteed specialism covers the IO-approval loop but not the base baseline failure. Base-flow modification cascades into 50+ $context.media_buy_id references — that's repurposing existing step logic, not additive. Per-step polling budget is an adcp-client SDK concern, not a storyboard YAML change.

   My take: The conformance gap is real. A guaranteed-only seller cannot pass the base media_buy_seller baseline today regardless of how well their implementation conforms to the spec. The issue also recommends trying an extended run for the goTom seller first — that should happen before committing to either option.

   Option A — 3.1.x patch: new additive guaranteed baseline (patch-eligible)

   # New storyboard id: media_buy_seller_guaranteed
   # Additive top-level baseline alongside media_buy_seller, not a modification of it
   track: media_buy
   requires_scenarios:
     - media_buy_seller/create_media_buy_async      # submitted wire shape
     - media_buy_seller/create_media_buy_async_lifecycle  # backport from 3.2
     - media_buy_seller/delivery_reporting
     # shared scenarios that already work with guaranteed products
   fixtures:
     products:
       - product_id: "display_guaranteed"
         delivery_type: "guaranteed"

   Unblocks goTom on 3.1.x now; base media_buy_seller modification deferred to 3.2.0.

   Option B — 3.2.0: delivery-mode-aware base flow (not patch-eligible)

   # media_buy_seller base storyboard create_buy phase — 3.2.0 only
   -  fixture: sports_preroll_q2  # delivery_type: non_guaranteed, hardcoded
   +  pre-discover delivery_type from product before create
   +  context_outputs: media_buy_id | task_id  (conditional on delivery path)
   +  check_buy_status branches on synchronous vs submitted arm

   Unified fix; all conformant sellers (guaranteed-only, mixed, non-guaranteed-only) pass the same base baseline; ships after 3.2 GA.

   @bokelley — once the extended run for goTom completes, your call: Option A (ship a separate guaranteed-only baseline as a 3.1.x patch now) or wait for Option B in 3.2.0?

   ---

   Triaged by Claude Code. Session: https://claude.ai/code/session_019Ed9zLXUXMFiGmyoebC9LJ

   ---

   Generated by Claude Code
4. bokelley

   added

   compliance-suite

   needs-wg-reviewBlocked on a working-group decision — surface in WG meeting agendasBlocked on a working-group decision — surface in WG meeting agendas

   media-buyIssue concerns the media-buy protocol domainIssue concerns the media-buy protocol domain

   claude-triagedIssue has been triaged by the Claude Code triage routine. Remove to re-triage.Issue has been triaged by the Claude Code triage routine. Remove to re-triage.

   and removed

   claude-triagingTriage routine is actively working on this issue (1-3 min)Triage routine is actively working on this issue (1-3 min)

   on Oct 1, 2026
5. bokelley

   modified the milestones: 3.1.x, 3.3.0 on Oct 2, 2026
6. bokelley

   added a commit that references this issue on Oct 6, 2026

   fix(media-buy): harden delivery-mode gates and cover the declaration …

   ...

   a17995c
7. bokelley commented on Oct 6, 2026

   

   bokelley

   on Oct 6, 2026 – with conductor.build App

   Last edited by bokelley

   ContributorAuthor

   More actions

   WG decision brief (3.3)

   Decided (2026-10-19): #7973 is held to 3.4. It stays a draft as the 3.4 candidate; 3.3 keeps the docs note. Option B (scenario adaptation) and the SDK default-resolution fix are the 3.4 path.

   Problem. A guaranteed-only seller returns a submitted task for every create_media_buy, so it has no media_buy_id for the follow-on checks in the inherited media_buy_seller baseline, which also uses non-guaranteed fixtures. It can pass sales-guaranteed and still never get a complete media-buy grade. Who is pulling: goTom was named, but the public record says delivery mode is not what blocks them. Their 20-min owner run passed 51/51 core scenarios (68/74 storyboards, audit-only; #7854), and the 2026-10-02 hosted run was core 58/59 with the single failure unrelated (#7889). The run-time blocker was fixed by #7854. I could not confirm with goTom whether their seller is guaranteed-only. I read 51/51 as "sells whatever the runner seeds".

   Evidence (training seller made faithfully guaranteed-only): 16 of 56 base storyboards fail (23 steps): hard-coded non-guaranteed fixtures, submitted arm with no media_buy_id, or discovery asserting non-guaranteed products. No adopter failure has been reported.

   Proposed shape — draft #7973, a ready option, not a request to merge (additive; changeset + status: proposed DR; CI green):

   { "media_buy": { "supported_delivery_types": ["guaranteed"] } }

   Optional, schema default ["guaranteed","non_guaranteed"] (absent = today's behavior). It gates 35 inherited scenarios and the base not_applicable for a seller that declares guaranteed-only, and adds a media_buy_seller_guaranteed baseline (submitted → controller completion → get_task_status → readback → delivery) selected only for that seller. Result on the training sellers: guaranteed-only 0 failed steps (was 23), mixed unchanged, non-guaranteed-only unchanged by the gates.

   Risks stated plainly (expert review): (1) gates rely on the runner resolving the schema default; with no 3.3 schema root, or a capabilities response with no media_buy block, an undeclared seller silently grades not_applicable on ~35 scenarios (reproduced; SDK-side fix needed); (2) coverage for guaranteed-only sellers drops from 189 to 106 passing inherited steps, so it is a reduced-coverage profile, not parity; (3) the MUST-reject-undeclared-mode rule is attestation-only; a mixed seller could declare guaranteed-only to dodge scenarios.

   Open questions for the WG

   1. Option A or B? Neither as filed. A literal additive baseline cannot replace the base (the runner picks one baseline per protocol); the workable form is declaration + gates + sibling baseline (feat(media-buy): declare delivery modes and grade guaranteed-only sellers on a matching baseline #7973). B (adapt ~25 scenarios, 38 $context.media_buy_id refs) is the complete fix. Pick: (a) ship feat(media-buy): declare delivery modes and grade guaranteed-only sellers on a matching baseline #7973 in 3.3, or (b) hold to 3.4 and do B. Recommend (b): no adopter has failed, and it freezes a schema field and a MUST into 3.3 on a synthetic seller. 3.3 keeps the docs note and a call for a guaranteed-only publisher to run the suite.
   2. Missing approval-controller coverage reported as incomplete, not not_applicable? Yes, using the existing missing_test_controller skip (never a complete grade). A new incomplete reason is a runner-output-contract + SDK change. Recommend defer that to 3.4.
   3. Per-step polling budget vs deterministic controller completion? Pick controller completion: human IO latency does not fit any runner poll window; a polling budget stays an SDK-repo item.
   4. Backport to 3.1.x/3.2.x? 3.3 only. A new schema field plus a new MUST is not patch-eligible under the playbook; the docs-only grading note already shipped (fix(compliance): make full verification resumable and bounded #7854).
   5. (Only if 1a) Declaration seller-wide or per product; error code for an undeclared mode? Recommend seller-wide for 3.3 and UNSUPPORTED_FEATURE (no new code).

   Out of scope / deferred. Adapting scenario bodies (3.4 Option B, which removes the temporary gates); the SDK default-resolution fix for an absent media_buy block; an incomplete skip reason; per-step polling budget (SDK repo); any change to sales-guaranteed / sales-non-guaranteed claims.
8. bokelley commented on Oct 31, 2026

   

   bokelley

   on Oct 31, 2026 – with conductor.build App

   ContributorAuthor

   More actions

   Decided on 2026-10-19 (#7852 (comment)): #7973 (delivery-mode declaration and guaranteed baseline) is held to 3.4, so this moves to 3.4. Objections by Fri 2026-11-06.

   Only the docs grading note and the resumable, bounded full verification from #7854 (3.3.0-beta.0) landed in 3.3. The milestone stays 3.3.0 for now; it will be moved after Nov 6. #8452 overlaps the declaration part.