Scenarios
Shipped in the binary, opened from the server
A new checkout sheet in the mobile app, compiled dark and waiting for approval. Outcome: shipped · one binary. 3 held · 1 adaptation · 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
mobile-dark-binary
SHIPPED · COHORT SPAREDShipped in the binary, opened from the server
A new checkout sheet in the mobile app, compiled dark and waiting for approval.
The plan — drafted before anyone saw it
Strategy Ship dark in the store build; open it server-side after approval
Control points Server-side control point keyed by app-version + device cohorts
Gates store review approved · startup-time check · crash-free ≥ 99.95%
Guardrails crash-free sessions · ANR rate · adoption
Rollback crash or ANR breach → feature goes dark, no resubmission
Ramp — planned outline, actual fill
dark
10%
50%
100%
The run — from the decision log
T+0m read: feature compiled dark into build 8.3 — store review pendingheld
T+3d gate: approval landed — build-8.3 users open at 10%; crash-free 99.97%held
T+4d saw: ANR spike on low-memory devices — that cohort held darkadapted
T+5d ramped: everywhere else to 100% over 48 hheld
T+6d done: one binary, a staged open, one device cohort quietly spared
3 held · 1 adaptation · 0 escapes
learneddevice-class cohorts persist — every mobile ramp now starts with them.