Scenarios
Bugfix, shipped before standup
One-line fix to a date-parsing bug in invoice generation. Outcome: shipped · 41 min. 4 of 4 plan rows held · 0 adaptations · 0 escapes
one control point a woven topology
“a one-line bugfix” ●shipped · 41 min“a CLI release to every laptop” ↶re-pinned in 51 s · then shipped“a mobile feature stuck behind store review” ●shipped · one binary“a rewrite that claims it’s 10× faster” ●proven · 2.1M comparisons“a risky change to a feature most orgs ignore” ●verdict · 5 h“a new skill for your agent fleet” ●fleet-wide · 0 broken sessions“a feature that spans API and UI” ●shipped · 3 days“one contract across three services” ●zero drift · one 40-min hold“a feature built on another feature” ●2 ships · 1 graph“the change that looked safe” ↶reversed · 43 s
invoice-parser-bugfix
SHIPPED 100%Bugfix, shipped before standup
One-line fix to a date-parsing bug in invoice generation.
The plan — drafted before anyone saw it
Strategy Canary — a slice of real traffic proves the fix
Control points One kill-switch at the fixed path
Gates CI e2e green · error-budget intact
Guardrails error rate · p95 · affected-path logs
Rollback Error rate above baseline → control point off
Ramp — planned outline, actual fill
1%
10%
50%
100%
The run — from the decision log
T+0m read: diff touches invoice-svc date parser only — no schema, no API changeheld
T+2m chose: one server-side kill switch — blast radius is a single code pathheld
T+9m gate: CI e2e green · error budget intact — the ramp opensheld
T+26m ramped: 1% → 50% → 100%, error rate flat against every guardrailheld
T+41m done: live for everyone; the control point retired itself a week later
4 of 4 plan rows held · 0 adaptations · 0 escapes
learnedinvoice-svc parser fixes tolerate fast ramps — default schedule tightened.