Production cutover and rollback
Build a frozen, rehearsed, observable cutover wave and execute it through Airlift's durable workflow.
Production cutover and rollback
Airlift does more than retain a cutover checklist. It computes a production gate from the current migration ledger and then orchestrates the external switch through a durable workflow. The gate fails closed when scope, certificates, transfer reconciliation, release evidence, rehearsal, operational evidence, approvals, or the effector binding does not match.
The cutover control room and fa cutover status show the same materialized control
record. UI state is never the gate.
Cutover remains blocked until scope, evidence, rehearsal, approvals, operational health, and rollback capability all agree.
The control room reflects the durable workflow and governed gate; it is not a manually editable checklist.
Resolve every named blocker, rehearse the exact runbook, and obtain distinct approvals before execution.
Lifecycle
| Stage | What Airlift records or executes | Required authority |
|---|---|---|
| freeze | exact object IDs, active certificate digests, transfer IDs, deployment requirement IDs, and release refs | operator |
| timed runbook | versioned steps, offsets, owners, durations, and explicit rollback links | operator |
| rehearsal | independently produced evidence for the exercised runbook steps | admitted automation |
| effector certification | implementation identity, complete capability set, evidence digest, and expiry | separate human certifier |
| parallel run | SLO verdict from Radar or an admitted external monitor | admitted automation |
| approval | distinct human approvals under the organization policy | approver |
| execute | checkpoint, apply once, verify, and compensate when verification proves a failed effect was applied | authenticated operator plus worker |
| hypercare | operational evidence, incidents, acceptance, and source disposition | operator, monitor, and separate acceptor |
Any object reassignment, certificate invalidation, transfer change, or deployment requirement drift makes the frozen scope stale. Refreeze a new wave revision; do not edit the prior digest.
Implement the cutover effector
Install the worker package and implement the exported interface:
npm install @fabricorg/airlift-workerimport type { CutoverEffector } from '@fabricorg/airlift-worker';
export const effector: CutoverEffector = {
profileId: 'airlift.cutover.customer-routing.v1',
implementationVersion: 'customer-routing@1.4.2',
certificationDigest: process.env.CUTOVER_EFFECTOR_CERTIFICATION_DIGEST!,
async createCheckpoint({ waveId, idempotencyKey }) {
return { checkpointRef: await checkpointRouting(waveId, idempotencyKey) };
},
async applyCutover({ waveId, checkpointRef, idempotencyKey }) {
return applyRoutingOnce({ waveId, checkpointRef, idempotencyKey });
},
async verifyCutover({ waveId, checkpointRef, effectRef, idempotencyKey }) {
return observeRouting({ waveId, checkpointRef, effectRef, idempotencyKey });
},
async compensateCutover({ waveId, checkpointRef, effectRef, idempotencyKey }) {
return restoreRouting({ waveId, checkpointRef, effectRef, idempotencyKey });
},
};The three identity fields must equal the active effector_certification_record for the
wave. The certification must be unexpired and prove all four capabilities:
checkpoint, apply_once, verify, and compensate.
Create the worker with the real effector:
import { createAirliftWorker } from '@fabricorg/airlift-worker';
await createAirliftWorker({ mode: 'temporal', runtime, effector });Temporal mode refuses to start with the stub. The apply and compensate activities each have one attempt. Retries are safe only around idempotent reads and governed mutations.
Verification outcomes
Return one of these outcomes from verifyCutover:
| Outcome | Workflow behavior |
|---|---|
verified | record success and move the wave to completed |
not_applied | record failure; do not infer or retry the external switch |
failed_applied | record failure, compensate once from the checkpoint, then record governed rollback |
uncertain | leave the wave executing for manual reconciliation; do not claim completion or rollback |
An exception after the apply request is also uncertain because the external system may have accepted the request. Airlift never guesses.
Start and observe the workflow
After the governed evidence and approvals are present:
fa cutover start wav_01J00000000000000000000000 \
--window 2030-09-14T02:00Z \
--reason "Approved customer change window" \
--json
fa cutover workflow-status airlift-v2-wav_<digest> --jsonDuplicate starts for the same wave and window attach to the same workflow ID. A payload-free wake can accelerate the next readiness read after an approval:
fa cutover wake airlift-v2-wav_<digest>The wake is not an approval. It carries no actor, organization, decision, or evidence.
Hypercare and source disposition
Hypercare starts only after the wave is completed and independent cutover-verification
evidence is present. Monitors continue submitting hypercare observations. Open
incidents block acceptance. A separate human records accepted or extends the
observation window, and a different human attests the final source disposition.
See cutover CLI for request files and cutover control room for the operator UI.