list-creative-formats-response asset oneOf omits 5 asset types that asset-union.json defines (pixel_tracker, vast_tracker, daast_tracker, card, published_post)

[KonstantinMirin]

Summary

list-creative-formats-response.json inlines an assets.items.oneOf that has drifted from core/assets/asset-union.json. Five asset types are in the union and missing from the response schema, so a format carrying one of them cannot validate against the response that is supposed to carry it.

This is self-contradictory within a single release bundle: the spec's own canonical format catalogue declares assets the spec's own response schema rejects.

Evidence, v3.1.1 (release bundle 3.1.1.tgz)

core/assets/asset-union.json — 20 branches:

image, video, audio, vast, text, url, html, javascript, zip, webhook, css, daast,
markdown, brief, catalog, published-post, card, pixel-tracker, vast-tracker, daast-tracker

bundled/creative/list-creative-formats-response.json → properties.assets.items.oneOf — 15 individual branches (plus RepeatableGroupAsset):

image, video, audio, text, markdown, html, css, javascript, zip, vast, daast,
url, webhook, brief, catalog

In the union, missing from the response: card, daast_tracker, pixel_tracker, published_post, vast_tracker

Still present in v3.2.0-rc.1

The response schema was restructured into a nested discriminated oneOf (item_type → asset_type), but the individual branch list is unchanged at 15 and the same five are still absent. asset-union.json grew to 21 branches (adds display-tag-asset.json) and still includes all three trackers.

The contradiction is inside one bundle

In the v3.2.0-rc.1 bundle:

• 4 of the 16 files under formats/canonical/ declare pixel_tracker assets (e.g. coordinated_placements.json);
• bundled/creative/list-creative-formats-response.json mentions pixel_tracker 128 times — every one in a description or an enum vocabulary, including "pixel_tracker / vast_tracker / daast_tracker are the renderer-fired measurement-tracker primitives — see /schemas/core/assets/pixel-tracker-asset.json" — and none as a oneOf branch;
• core/assets/pixel-tracker-asset.json exists and is a complete asset schema;
• the Python SDK generates PixelTrackerAsset, PixelTrackerEvent and PixelTrackerMethod from it.

How it surfaces

A sales agent serving formats captured from the reference creative agent (pinned image adcp-creative-agent, 467fd93d7711 = the v3.1.1 tag) fails response validation on list_creative_formats:

at formats.12.assets.1: {'asset_type': 'pixel_tracker', 'event': 'impression',
  'method': 'img', 'item_type': 'individual', 'asset_id': 'impression_tracker',
  'required': False, 'requirements': {'description': '3rd party impression tracking pixel URL'}}
  is not valid under any of the given schemas

Reproduced on 92 conformance checks in one run, across four transports.

Expected

assets.items.oneOf in list-creative-formats-response.json (and any sibling response schema that inlines the asset union) should be generated from core/assets/asset-union.json rather than maintained as a second list, so the two cannot diverge again.

[bokelley]

Triage

Classification: Conformance failure (Bug)
Bucket(s): spec / protocol, schema, creative
Status: ready-to-implement

What the experts said:

• ad-tech-protocol-expert: Non-breaking — all six missing types were normatively defined in asset-union.json from 3.1.0; adding them repairs an overly-restrictive validator, not a new requirement (IETF errata test: a conformant 3.1.0 implementation emitting these types would already satisfy the updated constraint). Patch-eligible in principle but needs explicit release-manager sign-off before the 3.1.x backport. Also found a second drift site: format.json's repeatable_group.assets inner oneOf is short at 13 of 21 types.
• adtech-product-expert: P1 — the affected surface (list_creative_formats, format.json) is deprecated in 3.2 and no production serving is broken (manifests validate against asset-union.json, which is correct). However, creative QA pipelines that validate format declarations against format.json will silently false-reject formats carrying pixel_tracker/vast_tracker/daast_tracker assets — revenue-adjacent risk for any operator running automated creative acceptance. Recommends hand-adding missing variants + a CI set-difference lint to prevent future drift, over full code generation.

My take: Experts converge on a clear, non-breaking fix with two drift sites in format.json that should be repaired together. The bump level and 3.1.x patch eligibility need a release-manager call.

• File: static/schemas/source/core/format.json
• Site 1 — individual-asset oneOf (~line 219): add 6 branches for display_tag, card, published_post, pixel_tracker, vast_tracker, daast_tracker. Pattern: allOf [#/$defs/baseIndividualAsset] + asset_type: { const: "…" } with no requirements ref (none exist for these types — follow IndividualZipAsset/IndividualBriefAsset pattern).
• Site 2 — repeatable_group inner oneOf (~line 428): add 8 branches — the 6 above plus brief and catalog (also absent).
• Non-breaking: adding oneOf branches is additive; existing consumers unaffected.
• Release routing: minor changeset on main; 3.1.x backport pending release-manager decision on patch vs. minor eligibility. media-buy/list-creative-formats-response.json delegates to format.json via $ref — no separate edit needed.
• Follow-up: separate issue for a CI drift-prevention lint (set-difference between asset-union.json's $ref list and format.json's discriminator values) — this is the structural fix the reporter asks for, at low build cost.

---

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

---

Generated by Claude Code