Experimental staged activation for live creative revisions

[bokelley]

Problem

The core revision contract in #6347 gives buyers immutable source identity, re-review safety, cross-seller correlation, and historical delivery attribution. It deliberately does not solve live hot-swap: a newly accepted revision follows the ordinary update lifecycle and does not keep a prior approved revision serving while review is in flight.

Some premium direct and managed-service workflows need to change legal copy or assets without either stopping delivery or minting a new creative_id that breaks the reporting join.

Proposed experimental scope

Define staged activation as a separate capability-gated extension after the core revision contract lands:

• creative.supports_staged_updates implies creative.supports_revisions;
• at most one active revision and one staged revision per creative;
• the active approved revision remains the only servable revision while the staged revision is reviewed;
• approval promotes the staged revision atomically;
• rejection leaves the active revision unchanged;
• sync readback and status webhooks identify both the revision reviewed and whether it is staged;
• delivery attribution continues to report the revision that actually served.

The first release MUST be marked experimental. Revision identity remains independently implementable and does not imply staged serving orchestration.

WG decisions required

1. Replacement/cancellation semantics when a second candidate arrives while one is staged.
2. Promotion failure and retry behavior across review, trafficking, and serving systems.
3. Observable status/webhook transitions and initiator/reason values.
4. Active-package update deadlines, pause behavior, and buyer recovery actions.
5. Whether promotion is immediate only or whether scheduled activation belongs in a later RFC.

Out of scope

• Multiple pending revisions
• General revision history or payload retention APIs
• Rollback APIs
• Scheduled activation
• Protocol-level content diffs

Dependency

Depends on the core immutable revision identity and re-review contract from #6347. This issue owns staged activation so that #6347 can land without committing all sellers to a serving-layer state machine.

[bokelley]

Triage

Classification: RFC / proposal
Bucket(s): spec / protocol, creative
Status: deferred

Blocked-on: #6347 — resurfaces on merge. The five WG decisions enumerated in the issue body (replacement/cancellation semantics, promotion failure/retry, status/webhook transitions, package update deadlines, immediate-vs-scheduled activation) require the core revision identity contract to land first; needs-wg-review already applied. Milestone: Spec Backlog.

---

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

---

Generated by Claude Code

[pkras]

Coming here from #6781 — this is the issue that closes the gap I flagged there, so a few things on the open WG decisions, mostly around #4 (active-package deadlines, pause behavior, buyer recovery):

Single-creative lines vs. rotation. The "active approved revision stays servable while the staged one reviews" promise is exactly right, but we should state the behavior explicitly for both shapes: a single-creative line (staging is the whole point — no gap) and a rotation of multiple creatives (does staging one creative touch the others' eligibility at all?). "What happens to the rest of my rotation while one is staged?" is the first question a buyer asks, and today it's unstated in both #6781 and here.

Buyer visibility during staging. #6781 acks the buyer-initiated transition on the sync response and fires creative.status_changed on the seller decision. For staging, decision #3 (observable transitions) should make it unambiguous which revision is active vs staged at every step, and give the buyer a clear signal on promotion success/failure — not just infer it from delivery reports.

Managed service. Good that the problem statement calls out managed-service workflows explicitly — that's the authorship gap I raised on #6781 (seller builds the creative and hands it back). Whatever staging state machine lands, it should have a defined answer for the case where the seller, not the buyer, authored the content being staged.

Recovery (decision #2 + #4). On promotion failure mid-flight, the buyer's recoverable state should be explicit: does the active revision keep serving untouched (I'd argue yes), and is there a defined retry vs. re-stage path rather than leaving the creative in an ambiguous state?

Happy to help pin down the rotation and recovery semantics.