Confidence: low. Evidence: failure case studies; under-researched as a program. Last substantive change: 2026-07.
This subsystem owns the data: schema design, migrations, backfills, data contracts, privacy, lineage, destructive operations, and restoration. It is separated out because data is where mistakes are largest and least reversible.
The conclusion
Data operations are the highest-blast-radius, least-reversible surface in the factory and deserve their own controls rather than being folded into general implementation. A dropped table or a bad migration is not a diff you can revert; it is an incident. The most vivid failures in the whole corpus are data-destruction events that completed in seconds.
How the thinking got here
Data was treated as a subset of implementation until production incidents made the difference undeniable. A nine-second database deletion and other production wipes showed that the reversibility assumptions that make code changes safe do not hold for data changes, and that "can execute" must be gated by "may execute" most strictly here.
Credible alternatives, and when each is right
| Approach | Right when |
|---|---|
| Human-gated schema and migration | any irreversible change |
| Expand-and-contract migrations | zero-downtime schema evolution |
| Shadow writes and dual-run | validating a change before cutover |
| Immutable or event-sourced data | auditability and replay are required |
| Rehearsed backup and restore | catastrophic recovery must be fast |
Where it fails and what we still don't know
The failure mode is catastrophic and immediate: destructive operations run without containment, backfills that silently corrupt, and restores that were never tested. This is one of the least-researched areas in the map. Open questions include safe destructive operations, migration correctness, backfill validation, data contracts, lineage, privacy handling, and restoration testing.
What would change our mind
A documented, safe pattern for autonomous schema and data operations, with tested rollback and restoration, would let the factory own data changes rather than routing all of them to a human.