Ambiguous status name: `pending_creatives` should clarify buyer action required

[kapoost]

Problem

The media buy status pending_creatives is ambiguous — it can be read as "waiting for creative approval" (publisher/governance side) rather than the intended meaning: "buyer has not yet submitted creatives via sync_creatives."

Proposed change

Rename to missing_creatives or awaiting_creatives to make it unambiguous that the required action is on the buyer side.

Current behavior

After create_media_buy succeeds with empty creative_assignments, the status is pending_creatives. A reader unfamiliar with the flow may interpret this as the publisher or governance agent needing to approve submitted creatives.

Expected behavior

Status name should unambiguously signal "buyer needs to call sync_creatives." Suggested options:

• missing_creatives
• awaiting_creatives

Affected spec files

• Media Buy protocol — status enum definition
• create_media_buy task reference (response shape)

[bokelley]

Triage

Classification: Feature request — naming ergonomics
Bucket(s): spec / protocol
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Ambiguity is genuine; OpenRTB 2.6 §7.4 uses notsubmitted vs pendingapproval to split "not submitted" from "awaiting approval" — pending_creatives maps to the wrong bucket for first-time readers. Rename is MAJOR; non-breaking enumDescription patch available and patch-eligible under the "prior spec demonstrably ambiguous" test.
• adtech-product-expert: creative-status: pending_review already exists for the publisher-side approval gate — pending_creatives on the buy status creates a semantic collision in multi-agent orchestration loops that filter on status before inspecting valid_actions. missing_creatives preferred over awaiting_creatives — "missing" is a deficit descriptor with no implied actor, matching how DSPs label buyer-missing-creative warnings. The pending alias precedent (accepted on pending_start) shows AdCP already ships backwards-compat aliases for this migration pattern.

My take: Both experts confirm the ambiguity is real and missing_creatives is the stronger name if a rename ships. The decision is whether to accept a enumDescription doc patch now (non-breaking, shippable on 3.0.x) or absorb the clean rename into AdCP 4.0 with a one-major alias. @bokelley, your call: Option A or Option B?

Option A — Patch enumDescription only (non-breaking, 3.0.x-eligible):

- "pending_creatives": "Media buy is approved but has no creatives assigned. The buyer must attach creatives via sync_creatives before the buy can serve."
+ "pending_creatives": "Buyer action required: no creatives have been submitted via sync_creatives. The buy cannot serve until at least one creative is assigned per package."

Wire value unchanged. No SDK churn. Resolves the doc-level ambiguity immediately.

Option B — Rename to missing_creatives at AdCP 4.0 (breaking, with one-major alias):

  "enum": [
-   "pending_creatives",
+   "missing_creatives",
    "pending_start",
    ...
  ]

Sellers emit missing_creatives; buyers match on it. Keep pending_creatives as a 4.x alias (same pattern as pending for pending_start). Hard break for any agent that doesn't update.

---

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

---

Generated by Claude Code