format.assets[]: distinguish input slots (buyer-provided) from output slots (build_creative-produced)

[bokelley]

Gap

format.assets[] describes the asset slots a format supports, with one boolean discriminator: required: true | false.

Per format.json:24-27:

`required: false` means "optional — enhances but not mandatory"

But this conflates two semantically distinct cases:

1. Optional input — buyer MAY provide it (e.g. an optional CTA in a display banner)
2. Output-only — buyer CANNOT provide it; the agent generates it via build_creative and returns it in the response manifest

The creative-manifest.json schema is bidirectional — the same shape is used for input requests (build_creative.creative_manifest) AND output responses (BuildCreativeSuccess.creative_manifest). Both reference format.assets[] for asset_id keying per creative-manifest.json:14 ("each key MUST match an asset_id from the format's assets array").

Concrete impact

A worked creative-template adapter declares input slots image / headline / cta / click_through (all required) and produces a build_creative output keyed under serving_tag of asset_type: 'html'. To satisfy creative-manifest.json:14, the adapter must declare serving_tag in format.assets[] — but required: true would (incorrectly) tell buyers "you must provide this in your build_creative request," and required: false understates the constraint (buyers can't provide it; rejecting a serving_tag input is a conformance ambiguity).

See examples/hello_creative_adapter_template.ts and examples/hello_creative_adapter_ad_server.ts in adcontextprotocol/adcp-client (PR #1511) — both adapters now declare an output slot with required: false because that's the closest legal expression in 3.0.5, but PE flagged this as an ambiguity that belongs upstream.

Proposal

Add one of:

Option A — produced_by enum (preferred — extensible)

format.assets[]:
  - asset_id: 'serving_tag'
    asset_type: 'html'
    required: false
    produced_by: 'build_creative'  # or 'render_time' | 'buyer'

produced_by: 'buyer' (default) means the buyer provides the asset in input requests. produced_by: 'build_creative' means the agent generates it; buyers MUST NOT include it in input requests. produced_by: 'render_time' reserves a path for assets resolved at impression-serving time (e.g. dynamic creative optimization output).

Option B — output_only: true flag (simpler — boolean)

format.assets[]:
  - asset_id: 'serving_tag'
    asset_type: 'html'
    output_only: true   # or false (default — buyer-provided)

Mutually exclusive with required semantically: output_only: true implies the slot doesn't apply to input validation.

Prior art

OpenRTB Native 1.2 §4.2 distinguishes `required` (bidder-supplied) from publisher-rendered fields. IAB OpenRTB 2.6 separates request-side from response-side fields explicitly. The same shape applies here: an asset slot's role differs between the buyer's request to build_creative and the agent's response.

Why now

@adcp/sdk PR #1511 just landed the spec-aligned output slot declaration in two worked creative adapters (template + ad-server) using required: false. The PR's PE review flagged the conflation as a real spec gap — captured here so adopters reading those adapters have a tracked issue to follow when the conflation is resolved.

Cross-references

• creative_template storyboard: add audio variant (TTS / mix / master pattern) #4015 — adds audio variant phase to creative_template storyboard (separate concern; uses output slot)
• fix(adapters): declare output slot in creative formats per creative-manifest.json:14 adcp-client#1511 — fix(adapters): declare output slot in creative formats per creative-manifest.json:14

[bokelley]

Triage

Classification: Feature request — spec gap
Bucket(s): spec / protocol, creative
Status: drafting-pr

What the experts said:

• ad-tech-protocol-expert: Option A — maps to OpenRTB 2.6 §3.2.7 / Native 1.2 §4.2 named-role precedent; Option B creates an undefined state (output_only: true, required: true). Also: baseGroupAsset must receive the same field addition (not just baseIndividualAsset), and a distinct OUTPUT_ONLY_ASSET_PROVIDED error code belongs in build_creative's error table. Non-breaking minor confirmed.
• adtech-product-expert: Preference for Option B (simpler buyer SDK surface); both experts agree render_time should be deferred — no corresponding AdCP task boundary today.

My take: Protocol expert and author align on Option A; the correctness argument (avoids undefined dual-boolean invariant) outweighs the ergonomic preference for B. Opening a draft PR with produced_by: enum ["buyer", "build_creative"] added to both baseIndividualAsset and baseGroupAsset; render_time deferred to a follow-up; error code noted as a nit in the PR body.

Drafting: feat(schema): add produced_by to format.assets[] to distinguish input/output slots

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code

[bokelley]

Draft PR opened: #4023 (feat(schema): add produced_by to format.assets[] to distinguish input/output slots)

---

Generated by Claude Code