The Release That Had to Explain Its Rollback

The story

10:12 — one service is green and one release is red

At 10:12, Ava Chen, Bluejay Works' release duty manager, sees a green whole-service dashboard hiding a failed candidate cohort. Seven document-delivery jobs also have no current terminal state from the external provider. Ava must decide what the evidence supports before authorizing expansion, retry, or rollback; the wrong shortcut could increase exposure or duplicate an effect the provider already accepted.

Thirty minutes earlier, Bluejay's Dispatch service had prepared release dispatch-api@3.8.0+7f2c for a 20-percent canary while retaining known-good coordinate dispatch-api@3.7.4+91ad as its rollback target. The registry pinned both artifacts and an uncomfortable boundary: application rollback cannot undo jobs already submitted to the external provider.

At 10:00, Ava authorized only the canary. The deployment platform acknowledged the request, and a later workload report showed candidate instances serving the declared cohort. The sequence remains intact:

canary authorized → request acknowledged → candidate observed serving

Ava's approval does not move traffic. Platform acceptance does not prove execution. Observing candidate instances does not prove that every eligible job entered the expected cohort. The registry establishes which artifacts Bluejay intended to use, not that the candidate is reliable or that rollback will be safe or complete.

The first closed observation window looks reassuring from far away:

Cohort	Eligible jobs	Receipt-deadline misses	Exact rate	Authored gate
Incumbent 3.7.4+91ad	4,800	24	0.5000%	Pass
Candidate 3.8.0+7f2c	1,200	23	1.9167%	Fail
Blended service	6,000	47	0.7833%	Informational pass only

Bluejay's authored policy applies a one-percent timeout ceiling to each release cohort. The candidate therefore fails even though the blended service metric passes. A green whole-service dashboard cannot erase a red candidate gate.

Seven candidate jobs have another problem. Bluejay recorded each submission, but the provider has supplied no current terminal state. The exact job identities remain in the evidence packet; their state is unknown—not failed. Blindly retrying them could duplicate an effect the provider already accepted.

10:13 — the evidence link degrades

The telemetry bridge disappears for seventy-five seconds. Bluejay's authored freshness limit is forty-five. The last accepted observation becomes stale for any current expansion decision, so expansion remains closed. Its recorded candidate failure remains historical evidence of what happened in the closed 10:12 window.

When the bridge returns, it redelivers the same window-close event twice. The first copy is retained against that historical window. The second is marked as a duplicate and changes no count or decision. Neither copy becomes current clearance to expand: a recent delivery time cannot make an old observation current, and silence cannot be filled with invented zeroes. The retained failure can support stopping exposure while fresh evidence remains required for any later expansion.

10:15 — three responses expose the real decision

The authored model evaluates exactly three responses:

Response	Result	Why
Expand the candidate to 50 percent	Rejected	The cohort gate fails and seven effects are unknown.
Restore the incumbent and retry all seven jobs	Rejected	Code can be reversed; unknown provider effects cannot safely be assumed failed.
Stop candidate traffic, restore the incumbent for new work, and quarantine the seven jobs	Conditional proposal	It limits new exposure while preserving each unknown state for provider reconciliation.

“Complete” means the fixture compared these three authored alternatives. It does not mean the system discovered every possible response, proved a root cause, or found a universal optimum.

10:16 — the model stops at authority

The surviving packet binds the exact release, telemetry, policy, and deployment revisions; the candidate and blended arithmetic; all seven unknown job IDs; the evidence gap and duplicate; the rollback target; validation gates; and the boundary around incident communication.

Ava authorizes alternative C under Bluejay's represented emergency-change policy. Her signed assertion records who approved which exact packet and why. It is not an instruction from Grid, proof of actual delegation, a workload change, a provider reconciliation, or permission to publish a customer message.

10:18 — an accepted rollback is not a rolled-back service

The external platform accepts rollback request RB-419. Only a later platform report shows zero candidate instances and new eligible work returning to 3.7.4+91ad. A separate observation window then passes the incumbent gates.

The full evidence line remains visible:

proposed → authorized → request accepted → deployment observed → service validated

The seven earlier jobs are still outside that rollback. The code has gone back. Its external effects have not.

10:21 — corrected evidence advances the present

Provider revision PROVIDER-889 reports that JOB-1184 and JOB-1190 were delivered. The current unknown count falls from seven to five. The first incident note and support snapshot become stale, but the earlier observation and Ava's decision packet remain intact because seven jobs were genuinely unknown when she acted.

At 10:44, PROVIDER-890 reports six of the original jobs delivered and JOB-1198 rejected before acceptance. Only that exact job becomes eligible for a separately authorized retry. The authored result is not a promise that a real provider, release, or rollback will resolve this way.

A successor release, 3.8.1, must still carry a new artifact digest, repeat the deterministic fixture, pass independent tests, and begin a new authorized canary. A successful rollback cannot promote an untested root-cause hypothesis into truth.

Why this setting is recognizable

CISA's safe software deployment guidance discusses controlled, measured rollouts, monitoring, rollback planning, validation, safeguards, incident communication, and learning. NIST SP 800-128 describes controlled configuration change as a documented sequence rather than a single button press. NIST SP 800-218 supports preserving release files, integrity information, and provenance.

Those official sources ground only the release-management context. They do not establish Bluejay, its one-percent gate, its canary size, the seven jobs, the correct response, a Grid deployment, or any outcome. This Scenario recommends no universal SLO, retry rule, canary percentage, or rollback procedure.

Where the model stops

Grid can represent revisioned evidence, calculate the authored gates, expose stale or contradictory state, compare declared responses, retain a decision packet, and propagate corrections across modeled derivatives. It cannot operate CI/CD, infer authority from authentication, execute a rollback, declare an external effect complete, retry an unknown job, approve communication, or turn a successful scenario recovery into a reliability claim.

What remains to prove

Source revision 2026-08-27.1 has reviewed domain context, product boundaries, and a public-suitability finding, so this authored scenario can be published at R2. The fixture itself remains authored.

The next proof is narrower and harder: implement the exact deterministic counts, gates, seven job identities, stale interval, duplicate event, three alternatives, authority stop, deployment states, and two provider corrections; freeze a separately identified independent oracle; run the negative cases; and retain exact execution and verification evidence. A later intended-environment evaluation would still need Bluejay-owned source, identity, authority, deployment, provider, security, records, incident, and reconciliation controls. None of that would turn this editorial Scenario into proof that Grid manages software releases or that the authored rollback succeeded.