Reference

Change and release states

Every record in Babbit moves through stages by events, looked up in one table. Nothing moves on a schedule. The stages, and the events that move each kind of record.

How states work

A record moves from one stage to the next only when an event arrives that a row of Babbit's state table allows for its current stage. Each row can also check a condition against the record before it moves, and can name the job that runs next. Nothing moves on a timer.

An event that doesn't fit where the record is gets refused, in one sentence.
The same event twice does nothing the second time.
Every event applied is kept on the record, with what moved it, such as a pull request head or a merge.

The screens show friendlier names. The change screen's five steps group these stages: Asked covers brief, needs-you and propose; Approved is review; Built covers implement, writing and publish; Verified covers verify, capture and ready; Live covers landing, done and the release; the step lights only when the release reaches shipped.

Change

Stages

Stage	Meaning
`brief`	Babbit is writing the brief.
`needs-you`	Waiting on a person: a key, a sign-in, an answer or an "already does this" decision.
`propose`	The Product agent is proposing spec lines.
`review`	Waiting for a person to approve the proposed lines.
`implement`	Approved; Code Writing's work is queued or being prepared.
`writing`	The Code Writing agent is working in its workspace.
`publish`	The work was handed off; Babbit is checking it and opening pull requests.
`verify`	Babbit is running each scenario's test at its pull request head.
`capture`	The Verify agent is capturing the app before and after.
`ready`	Every scenario has its evidence. Waiting for Merge & release or Apply change.
`landing`	Babbit is merging the spec, then the code.
`stalled`	The workspace stopped answering or the session ended without a handoff. Resume continues it.
`done`	Every pull request merged. Terminal.
`landed-partial`	The spec merged but a code pull request was refused. Terminal.
`cancelled`	Someone cancelled the change. Terminal.

Events that move a change

From	Event	To
`brief`	`briefed`	`propose`
`brief`	`gates-asked`	`needs-you`
`needs-you`	`gates-answered`	`propose`
`propose`	`proposed`	`review`
`review`	`approved`	`implement`
`implement`	`session-started`	`writing`
`writing`	`handed-off`	`publish`
`writing`	`input-required`	`needs-you`
`writing`	`session-ended` or `two-heartbeats-missed`	`stalled`
`publish`	`prs-opened`	`verify`
`publish`	`publication-refused`	`implement`
`verify`	`evidence-at-head`	`capture`
`verify`	`tests-failed` or `conflicted`	`implement`
`verify`	`identity-required` or `already-asked`	`needs-you`
`needs-you`	`already-answered` or `identity-answered`	`verify`
`needs-you`	`not-yet` or `input-answered`	`implement`
`capture`	`all-green`	`ready`
`ready`	`land-confirmed` or `manage-confirmed`	`landing`
`ready`, `capture`, `landing`	`head-moved`	`verify`
`ready`, `landing`	`main-moved`	`verify`
`landing`	`all-merged`	`done`
`landing`	`member-refused`	`landed-partial`
`landing`	`conflicted`	`implement`
`stalled`	`resumed`	`implement`
Any open stage after `brief`	`request-changes`	`propose`
Any open stage	`cancelled`	`cancelled`

Every working stage also takes job-failed, which keeps the change where it is and offers Retry, and retry, which runs the stage's job again.

Release

Stage	Meaning
`cut`	The release records a commit per repository and deploys.
`preprod`	Deployed to preprod; smoke scenarios run.
`replaying`	Last week's prod traffic is replaying against preprod.
`held`	The replay couldn't cover a call. Waiting for a person allowed to promote to production.
`replayed`	The replay was clean, or a person approved; deploying to prod.
`prod`	Deployed to production; smoke scenarios run.
`shipped`	Production passed its smoke scenarios. Terminal.
`rolled-back`	A smoke run or the replay failed, and every service went back. Terminal.
`superseded`	A newer release was cut first. Terminal.

From	Event	To
`cut`	`deployed-preprod`	`preprod`
`preprod`	`smoke-passed`	`replaying`
`preprod`	`smoke-failed`	`rolled-back`
`replaying`	`replay-clean`	`replayed`
`replaying`	`replay-uncovered`	`held`
`replaying`	`replay-broke`	`rolled-back`
`held`	`approved`	`replayed`
`replayed`	`deployed-prod`	`prod`
`prod`	`smoke-passed`	`shipped`
`prod`	`smoke-failed`	`rolled-back`
`cut`	`superseded`	`superseded`
`cut`	`nothing-deployed`	`shipped`

Base snapshot

Every workspace starts from the project's base snapshot. It's rebuilt because main moved, never on a schedule.

Stage	Meaning
`unbuilt`	No snapshot yet.
`building`	A build is running.
`stale`	Main moved during the build; the next build starts when this one finishes.
`ready`	The snapshot is current. When QA is on, a finished build starts it, so QA runs on the new main.
`failed`	The build failed. The next move of main, or a rebuild request, starts another.

Other records

Record	Stages	Moves on
Onboarding	`queued` → `running` → `drafted` → `approved`	`started`, `drafted`, `approved`; `failed` with `continue` or `refresh` back to `queued`
Session	`queued` → `running` → `handed-off`, `stopped` or `failed`	The agent's session starting, handing off, stopping or failing
Workspace	`running` ⇄ `stopped` → `ended` or `expired`	Stopping for a gate, resuming, ending with the change, or its snapshot expiring
Push	`received` → `read`	Babbit reading a push for drift
Budget	`within` ⇄ `over`	A budget alert, or the budget being raised

Changes: the stages in plain words.
Tiers, releases and hosting: what each release stage proves.

#How states work

#Change

#Stages

#Events that move a change

#Release

#Base snapshot

#Other records

#Related