Skip to content

Scheduled and held activation for creative swaps (remainder after #8488) #6780

Open
Open
Scheduled and held activation for creative swaps (remainder after #8488)#6780
Labels
claude-triagedIssue has been triaged by the Claude Code triage routine. Remove to re-triage.creativeenhancementNew feature or requestneeds-wg-reviewBlocked on a working-group decision — surface in WG meeting agendasrfcProtocol change — auto-adds to roadmap boardspec / protocol
Milestone
Spec Backlog

Description

@bokelley
bokelley
opened on Aug 23, 2026

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.

Activity

  1. bokelley
    added
    enhancementNew feature or request
    rfcProtocol change — auto-adds to roadmap board
    creative
    spec / protocol
    needs-wg-reviewBlocked on a working-group decision — surface in WG meeting agendas
    on Aug 23, 2026
  2. github-project-automation
    added this to Ad Context Protocol Roadmapon Aug 23, 2026
  3. bokelley
    added this to the Spec Backlog milestone on Aug 23, 2026
  4. bokelley
    added
    claude-triagingTriage routine is actively working on this issue (1-3 min)
    on Aug 23, 2026

  5. bokelley commented on Aug 23, 2026

    @bokelley
    bokelley
    on Aug 23, 2026
    ContributorAuthor

    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

  6. bokelley
    added
    claude-triagedIssue has been triaged by the Claude Code triage routine. Remove to re-triage.
    and removed
    claude-triagingTriage routine is actively working on this issue (1-3 min)
    on Aug 23, 2026

  7. pkras commented on Aug 24, 2026

    @pkras
    pkras
    on Aug 24, 2026
    Collaborator

    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.

  8. bokelley commented on Oct 25, 2026

    @bokelley
    bokelley
    on Oct 25, 2026 – with conductor.build App
    ContributorAuthor

    #8488 folds the core of this issue into the experimental live creative updates (#8404) surface. A seller can declare serving: "staged" for a change kind. The approved prior version then stays the only serving version under the same creative_id while the change is reviewed, and the seller promotes the change atomically on approval.

    The readback is staged_update, exposed on sync_creatives and list_creatives. The creative.status_changed notification fires approved → approved with staged_update.outcome. Delivery stays split by revision_id.

    Answers to the WG decisions this issue listed:

    1. A new candidate while one is staged. It supersedes the staged one. Re-syncing the content of a pending staged update leaves it as is. Re-syncing the serving content withdraws the staged update.
    2. Promotion failure. Review is one decision across all assignments, so there is no partial promotion. Any transition out of approved discards the staged update.
    3. Transitions. On promotion: approved → approved with review_passed. On rejection, on_rejection decides: keeps_prior is approved → approved with review_failure, and stops is approved → rejected with impairments.
    4. Active-package deadlines, pause behaviour and recovery. A paused package still counts as live. A refused change returns CREATIVE_LIVE_UPDATE_UNSUPPORTED, and the recovery is a new creative_id plus a replace.
    5. Scheduled activation. Out of scope.

    Revision history and rollback stay out of scope, as this issue proposed.

  9. bokelley
    added 3 commits that reference this issue on Oct 25, 2026

    feat(creative): live creative updates with staged activation (experim…

    f2b2d51

    feat(creative): live creative updates with staged activation (experim…

    433a5d1

    feat(creative): live creative updates with staged activation (experim…

    8b5584e
  10. bokelley
    changed the title [-]Experimental staged activation for live creative revisions[/-] [+]Scheduled and held activation for creative swaps (remainder after #8488)[/+] on Nov 2, 2026

  11. bokelley commented on Nov 2, 2026

    @bokelley
    bokelley
    on Nov 2, 2026 – with conductor.build App
    ContributorAuthor

    Retitled. The core of this issue, staged activation under the same creative_id (the prior approved version keeps serving until the change is approved, then it is promoted atomically), shipped as experimental in 3.3 via #8488 (creative.live_updates, serving: "staged", and the creative.staged_update_changed event).

    What remains here:

    • Scheduled activation. Promote an approved change, or swap a creative, at a chosen time rather than on approval.
    • Held assignments for coordinated launches. Assign a creative to packages across buys so it is reviewed but not served, then activate all of them together.
    • Per-product overrides of the creative.live_updates declaration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    claude-triagedIssue has been triaged by the Claude Code triage routine. Remove to re-triage.creativeenhancementNew feature or requestneeds-wg-reviewBlocked on a working-group decision — surface in WG meeting agendasrfcProtocol change — auto-adds to roadmap boardspec / protocol

    Type

    No type

    Projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions