---
title: Staging and publishing
nav: Stage and publish
description: How a deployment draft is built and validated, what publishing does, and the release gate that keeps it off by default.
group: workflows
order: 3
status: beta
updated: 2026-09-21
---

> Live publishing is **default-off** and gated behind a release check. Building and inspecting a draft is always available and always zero-write.

## Building a draft

Approved recommendations are turned into a deployment draft in one action. The draft is idempotent: running it twice with the same approved set produces the same draft rather than a second one.

Building a draft writes nothing to any store. It is a local plan.

## What a draft contains

Per item: the application, product, and market; the exact **before** price read from the store; the exact **target** price; and any validation messages.

Draft-level checks run before it is considered ready:

- **Stale-state refusal** — the draft is built against the latest store read, and refuses if the store has moved since.
- **Confidence checks** — items whose confidence dropped below threshold since approval do not pass.
- **Protected-market checks** — a protected market cannot be included.
- **Plan-relationship checks** — the change must not invert the economics of a plan ladder, such as making an annual plan cost more per month than the monthly one.
- **New-customer-only warnings** — subscription price changes apply to new customers; existing subscribers are governed by store policy and consent rules. The draft says so explicitly rather than leaving it implied.

A withdrawn product fails the whole selection, which is why withdrawn items are excluded when the draft is assembled rather than left to break it.

## Publishing

Publishing is a separate, explicit action on a ready draft, and it is only enabled when the deployment is configured to allow live writes or the connection is running in fixture mode.

When it runs:

1. An **atomic execution claim** is taken, so two workers cannot publish the same deployment.
2. The store is **re-read immediately before the write**. If the live state no longer matches the diff, the write is refused.
3. Each item is written **independently**. A rejection on one market does not roll back or hide the others.
4. Each item is **read back** from the store and compared against what was intended.
5. Every item reports its own status and result.

The publish worker retries provider failures and isolates per-item failures. Nothing is reported as succeeded that was not verified by a read-back.

## Why this is still beta

Three things are missing before live publishing can be generally enabled:

- **Controlled real-account mutation proof.** The path has not been exercised end-to-end against a real Google product under release conditions.
- **Stale publishing-claim recovery.** If a worker crashes mid-publish, the claim is not yet reclaimed automatically.
- **Rollback as a new forward deployment.** Reverting currently means staging the inverse change by hand.

Until all three are done, treat publishing as a capability that exists and is tested but is not yet warranted for production use — and do not rely on rollback existing.

## Fixture mode

Fixture mode runs the entire loop against a fixture provider instead of a live store. The orchestration is identical, which is the point: the same code path is exercised, so a fixture run is a real test of the flow rather than a simulation of it.