Wire enum gaps: creative-builder specialism, audio MediaChannel, cpv/vcpm pricing

[bokelley]

Background

scope3data/agentic-adapters ported all 13 platform adapters to @adcp/sdk v6 DecisioningPlatform shape during Phase B (PRs #207–#221). Across that fan-out, three wire-enum gaps surfaced where the v6 TypeScript surface anticipated a value the wire schema doesn't know about. Adapters had to claim adjacent values that fit imperfectly. Filing as a single tracking issue since the diagnosis is shared (adapter port surfaced cases the spec didn't anticipate).

Gap 1: creative-builder not in AdCPSpecialism

The v6 SDK has a CreativeBuilderPlatform TypeScript interface (referenced in RequiredPlatformsFor<S> mapping). The wire AdCPSpecialism enum only knows the legacy split: creative-template and creative-generative. Adapters using CreativeBuilderPlatform (e.g., AudioStack — a stateless brief→creative agent) had to claim creative-template even though structurally they're builders. The TS interface unifies both, but the wire enum still bifurcates.

Ask: add creative-builder to AdCPSpecialism and map both legacy values to it for backwards compat. The SDK's RequiredPlatformsFor already unifies them at the type level; the wire enum should follow.

Gap 2: MediaChannel has no generic audio

AudioStack outputs MP3 ads applicable to radio + streaming_audio + podcast — there's no umbrella audio value. Adapters had to advertise all three.

Current enum: display, olv, social, search, ctv, linear_tv, radio, streaming_audio, podcast, dooh, ooh, print, cinema, email, gaming, retail_media, influencer, affiliate, product_placement, sponsored_intelligence.

Ask: add audio as a parent / coverage value. Spec needs to define the relationship to the existing radio/streaming_audio/podcast values (semantic broadening vs. additional concrete value).

Gap 3: pricing models missing cpv, vcpm

Google Ads supports CPV (cost-per-view, video). Amazon DSP supports vCPM (viewable CPM). Neither is in the pricing-model enum — adapters used the values inline but they're not strictly-validated.

Ask: add cpv and vcpm to the pricing-model enum.

Why bundle

All three gaps share the same root cause: adapters from established ad-tech platforms encoding values the spec didn't anticipate at v3.0 freeze. Fixing them in one spec PR keeps the discussion coherent (semantics of "broader coverage" applies across all three) and lets adopters track one issue rather than three.

References

• Workspace migration PRs: scope3data/agentic-adapters#207 (snap), scope3data/agentic-adapters#218 (flashtalking — CreativeAdServerPlatform), scope3data/agentic-adapters#219 (audiostack — CreativeBuilderPlatform).
• Each packages/adapter-*/src/platform.ts carries inline TODO markers at the gap seams.
• Cross-ref: adcp-client#1145 (umbrella tracking issue for v6 interface gaps observed across the port).

[bokelley]

Triage

Classification: Feature request (spec enum gaps)
Bucket: spec / protocol
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Gap 1 — creative-builder as a collapsing alias conflicts with the build-enforced enum/storyboard 1:1 parity check; either it's a new first-class specialism with its own storyboard, or it stays off the wire; compliance-runner behavior for an agent claiming only creative-builder is undefined either way. Gap 2 — a parent value in a flat enum with no normative expansion rule is unresolvable for receivers; IAB OpenRTB 2.6 uses separate arrays for this kind of broadening, not enum hierarchy.
• adtech-product-expert: Gap 1 — buyers route on supports_generation/supports_transformation capability flags, not the specialism; creative-builder adds no buyer-visible routing signal, and the TS friction is cleanly fixed at the SDK layer with a union type alias. Gap 2 — buyers need discrete channel values for rate negotiation, measurement-vendor selection, and delivery reconciliation; an audio umbrella silently excludes products from channel-filtered avails queries (seller declares audio, buyer queries ?channel=streaming_audio → invisible exclusion).

Gap 3 (cpv / vcpm): Already shipped — both values are in static/schemas/source/enums/pricing-model.json with full descriptions and dedicated option schemas (cpv-option.json, vcpm-option.json). No action needed here.

My take: Both open gaps have cleaner resolutions than direct wire-enum additions. @bokelley, your call on each:

---

Gap 1 — creative-builder specialism

Option A — SDK-layer union type, no wire change:

// Per-SDK type alias — resolves the TypeScript friction without touching the wire enum
type CreativeBuilderPlatform = 'creative-template' | 'creative-generative';

Spec and storyboards unchanged. Adapters keep declaring whichever wire value matches their compliance storyboard. Zero adoption cost on the wire.

Option B — New first-class wire specialism with its own storyboard:

// static/schemas/source/enums/specialism.json
+ "creative-builder"
// + static/compliance/source/specialisms/creative-builder/index.yaml  ← required by build parity check

Agents claiming creative-builder must pass the new storyboard. Existing creative-template / creative-generative remain valid. Requires authoring new compliance scenarios that define what a "builder" must do beyond either legacy value.

---

Gap 2 — audio MediaChannel umbrella

Option A — Add audio as a discrete peer enum value (no expansion semantics):

// static/schemas/source/enums/channels.json
+ "audio"

Seller-side relief for cross-substrate inventory. Breaks buyer channel filtering: GET /products?channel=streaming_audio silently excludes audio-tagged products until every buyer agent is updated to expand the term.

Option B — No wire change; sellers enumerate all applicable channels explicitly:

{ "channels": ["radio", "streaming_audio", "podcast"] }

Filtering works today with zero spec change. An optional channel_display_name field (or equivalent) could surface "Audio" as a UI label without touching filter semantics — worth a separate small RFC if the display problem is the real pain.

---

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

---

Generated by Claude Code