Adopter runtime declaration honesty: 'declared on catalog, not wired in adapter' has no spec expression

[bokelley]

Context

Surfaced during a v2 canonical-mapping audit of the universalads adapter (scope3data/agentic-adapters#202, PR scope3data/agentic-adapters#203). The adapter's catalog declares a generative-offerings format (which would map to sponsored_placement with item_production_model: seller_pre_rendered_from_brief per #3307 6882b0cf2), and the format is assigned to two products. But the adapter's create_media_buy and sync_creatives runtime do not actually wire the per-item generation path — create_media_buy ignores pkg.offerings, sync_creatives is a single-asset-per-creative loop. The catalog declaration is intended-state; the runtime is media-upload-only.

This is going to bite v2 migration. Adopters will copy v1 catalog declarations forward, claim the new production-source axis (image_source / video_source / item_production_model), and ship — and buyers will discover at sync_creatives time that the per-item rendering doesn't happen. The seller is technically not lying because the spec has no field where they'd be lying.

What the spec already has

• _base.json :: status: stable | preview | deprecated (_base.json) — describes the canonical's spec stability, with a stabilization rubric. This is about whether the v2 working group has stabilized the format definition.
• since_version / migration_target_version — same axis: spec-evolution, not adopter-runtime.
• synthesis_nondeterministic — about per-run output variance, not about whether the runtime fans out at all.

None of these speak to: "this adopter has declared this format/source on this product, but their runtime currently can or can't honor it." That's a different axis — adopter readiness vs canonical maturity.

Proposal

Add an optional runtime_status field on the v2 product-format declaration (not the canonical itself). Values like:

• stable — adopter's runtime fully honors the declared format + production source.
• preview — runtime supports the basic path; some axes (e.g., per-item fan-out, brief overrides) may be partial.
• declared_only — catalog declaration is forward-looking; runtime does not yet implement this path. Buyers SHOULD treat as informational and confirm via validate_input or a sandbox storyboard before purchase.

Defaults to stable. Buyers can filter on it; sandbox compliance storyboards can require stable for cert.

This isn't redundant with status on the canonical: status says "is this canonical itself stable in the spec?"; runtime_status says "does this seller's runtime actually honor what they declared?" Both can vary independently — a stable canonical can have declared_only adopters, and a preview canonical can have stable adopters who built against the preview shape.

Why now

• Migration path matters most. Adopters will declare aspirationally during v2 rollout because the new production-source axis is a strict superset of v1 expressivity. Without runtime_status, every "I declared seller_pre_rendered_from_brief because that's where I'm headed" silently lies to buyers.
• Compliance storyboards need a way to skip-gate "runtime declared but not wired" gracefully — same pattern as requires_capability (scope3data/agentic-adapters#151 storyboard fix lineage).
• Cheap to add: optional field, defaults preserve current behavior, no producer breakage.

Alternative considered

Reusing status on the product-format declaration. Rejected: status is on the canonical, not on the per-product instance, and conflating spec-maturity with adopter-runtime confuses two genuinely different signals.

Ref

• adcp#3307
• scope3data/agentic-adapters#202 — universalads cleanup
• scope3data/agentic-adapters#203 — audit PR with the exact "declared but not wired" comment block

[bokelley]

Triage

Classification: Feature request
Bucket(s): spec / protocol, schema, creative
Status: deferred — fold candidate

My take: runtime_status targets product-format-declaration.json, a schema introduced in PR #3307 that has not yet merged. Adding it there avoids reopening the same file in a follow-up PR and prevents the "declared aspirationally, discovered broken at sync_creatives" failure mode from landing in 3.1.0 without the guard.

Blocked-on: #3307 — resurfaces on merge

---

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

---

Generated by Claude Code

[bokelley]

Fixed in adcontextprotocol/adcp@b3c29bc17 on #3307.

Added runtime_status: stable | preview | declared_only to ProductFormatDeclaration (defaults to stable). Distinct from canonical-level status per your proposal — the two axes vary independently.

Specifically addresses the universalads _generated_offerings situation surfaced in scope3data/agentic-adapters#202: the adapter's catalog can now declare the generative-offerings format with runtime_status: declared_only, which honestly signals to buyers that the catalog declaration is forward-looking while the runtime hasn't yet wired the per-item generation path. Buyers filter on it; sandbox compliance storyboards skip-gate declared_only entries gracefully rather than failing.

Documentation in v2-overview.mdx adds a "Two stability axes" section explicitly framing the canonical-spec axis vs the adopter-runtime axis. The migration walkthrough's sales-agent step 3 calls out runtime_status as a first-class deliverable so adopters set it deliberately during translation rather than discovering its absence in compliance review.

Thanks for the well-articulated proposal — your draft was almost verbatim what landed.