RFC: preserve one-of creative delivery variants for late seller binding

[bokelley]

Problem

Creative material is often ingested before the destination seller, product, or
player is known. One logical creative can arrive with several equivalent
delivery representations. A CM360 tag sheet is a concrete example:

• display: iframe/JavaScript, JavaScript, Standard, and Internal Redirect;
• video/audio: VAST 2.0, 3.0, and 4.0 pre-fetch URLs.

The correct representation depends on the eventual product's format option and
execution path. Discarding alternatives at parse time makes later assignment
impossible; creating unrelated creative IDs loses logical identity,
provenance, revision correlation, and reporting continuity.

The current CreativeAsset contract selects one format_kind (and optionally
one format_option_ref) with one assets object. Arrays inside asset slots are
cardinality for formats such as carousels, not one_of delivery alternatives.
There is no protocol object or normative workflow for preserving equivalent
representations and selecting one after seller discovery.

References:

• creative-asset.json
• format-option-ref.json
• CM360 placement tag variants

Proposed direction

Define a first-class, explicitly one_of delivery-variant set for pre-binding
creative intake. Each variant should carry:

{
  "variant_id": "cm360-vast-3",
  "format_kind": "video_vast",
  "format_option_ref": null,
  "assets": { "vast_tag": { "asset_type": "vast", "...": "..." } },
  "source": {
    "system": "cm360",
    "source_variant": "VAST 3.0 pre-fetch"
  }
}

The exact envelope could be delivery_variants[] on a creative-source object,
or a new creative-library object that compiles to an ordinary seller-bound
CreativeAsset. It should not overload repeatable asset groups.

Resolution workflow

1. Ingest and preserve all valid source variants without executing them.
2. Discover seller and product format options.
3. Compute compatible variants using canonical kind, format-option
   requirements, seller capabilities, and asset metadata.
4. Select exactly one representation for a seller-bound sync/assignment.
5. Read back selected_variant_id, or return structured rejection reasons for
   every candidate when there is no compatible variant.

The protocol should decide whether selection is always buyer-side or may be
delegated to a seller that advertises deterministic variant resolution. Silent
seller guessing must not be the default.

Non-goals

• Creative rotation or A/B testing. Variants here are equivalent trafficking
  representations, not content intended to rotate.
• Treating a higher VAST version as universally better. Version compatibility
  is product/player-bound.
• Inventing vendor macro replacements during ingestion.

Acceptance criteria

• One logical creative can preserve multiple equivalent delivery
  representations under stable variant IDs.
• Variant sets have explicit one_of semantics distinct from repeatable
  asset cardinality.
• A seller-bound creative identifies the selected source variant.
• Resolution failures return per-variant structured reasons.
• Provenance and revision identity survive selection.
• Worked examples cover a CM360 display row and VAST 2/3/4 alternatives.
• Compliance vectors prove that unsupported alternatives are retained but
  never silently trafficked.

Compatibility and versioning

This can be additive if introduced as a pre-binding creative-source/library
object that compiles to today's CreativeAsset. Adding alternatives directly
to the seller-bound CreativeAsset union may require a larger versioning
discussion.

[bokelley]

Triage

Classification: Feature request / RFC
Bucket(s): spec / protocol, creative
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Well-formed — CM360 multi-variant ingest is the dominant 3PAS workflow (not an edge case); the CreativeAsset oneOf discriminator confirms the schema gap; an additive CreativeSource compiling to CreativeAsset is schema-sound; however, variant_id collides with creative-variant.json's delivery-attribution entity (must be renamed source_variant_id or registered as a distinct x-entity), and three structural design questions block a first draft (see Q2–Q3 below).
• adtech-product-expert: Partially misdiagnosed at the protocol layer — VAST version negotiation is industry-solved via wrapper fallback chains at bid time; format_option_ref already handles same-kind format-option disambiguation; the "compute compatible variants" step (RFC Resolution step 3) has no AdCP data source since player compatibility is held by the SSP/player; not purely additive — every seller agent receiving a CreativeAsset today would need new variant-selection logic.

My take: Experts split on whether this belongs at the protocol wire layer or in a buyer-agent convention. The display-variant case (iframe/JS/standard/internal-redirect — no runtime negotiation exists) is stronger than the VAST-version case (wrapper chains cover it). Three structural questions need WG answers before spec work begins.

@bokelley, your call:

Q1 — Scope: Is the primary pain the display-tag variants (no runtime negotiation) or VAST-version variants (wrapper chains exist), or both? This determines whether a new protocol primitive is load-bearing or whether get_adcp_capabilities returning supported_format_kinds per product is sufficient for the VAST subcase.

Q2 — Wire shape: Two viable directions:

Option A — New pre-binding CreativeSource object (new minor surface on 3.2 line):

{
  "source_id": "cm360-batch-42",
  "source_variants": [
    {
      "source_variant_id": "cm360-display-iframe",
      "format_kind": "display",
      "assets": { "tag": { "asset_type": "html", "html": "<iframe ...>" } }
    },
    {
      "source_variant_id": "cm360-vast-3",
      "format_kind": "video_vast",
      "assets": { "vast_tag": { "asset_type": "vast", "url": "..." } }
    }
  ]
}

Requires a new bind_creative task or extended sync_creatives. Seller agents need variant selection logic. Zero 3.1.x backport.

Option B — Capability advertisement + buyer-side selection (no new pre-binding object):

// get_adcp_capabilities response carries compatibility signal
{
  "capabilities": {
    "creative": {
      "supported_format_kinds": ["video_vast"],
      "supported_vast_versions": ["3.0", "4.0"]
    }
  }
}
// Buyer agent selects once before calling sync_creatives — sellers unchanged

Zero seller-side change; buyer holds variants locally and selects before trafficking.

Q3 — Reporting chain: Must source_variant_id survive into delivery attribution (i.e., appear on creative-variant.json / Tier 2/3 metrics)? If yes, that pulls a second schema into scope and widens the RFC materially.

---

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

---

Generated by Claude Code