mindit-correctability

mindit-correctability

The eighth of the eight forces. Run this when the question is "if this is wrong, how fast can we find out and how cleanly can we fix it."

The force

Most design decisions are bets. Some bets are right; some are wrong. The cost of being wrong depends on three things: how quickly can the team tell, how broadly does it apply when it's wrong, and how cleanly can they reverse course.

A change behind a 5 percent rollout with a kill switch and rich telemetry is cheap to be wrong about. A change shipped to 100 percent of users with no instrumentation and a destructive data migration is catastrophic to be wrong about.

Correctability asks: given that this decision might be wrong, what is the cost of being wrong, and what mechanisms are in place to recover?

When to run this

• The user is planning a launch, rollout, or migration.
• The user mentions A/B tests, feature flags, percentage rollouts, kill switches, or telemetry.
• The user is about to make a broad-impact change: default change, pricing change, schema migration, brand refresh, design system overhaul.
• The user uses words like "rollback," "revert," "kill switch," "monitoring," "blast radius."

How to analyze

1. Identify the decision. What specifically is being shipped? Who is affected? What state changes?

2. Map the recovery dimensions. For each criterion, ask both "can we" and "have we planned to."

3. Distinguish "reversible in theory" from "reversible in practice." A change is only practically reversible if the rollback is planned, rehearsed, and instrumented.

4. Surface the blast radius explicitly. Even good correctability is wasted if the blast is too big. A bad change behind a 100 percent rollout with a working rollback still affected every user for the duration of the rollback.

5. Check anti-patterns.yaml.

6. Write the artifact.

Rubric

Criterion	Weight	What you are scoring
User-side reversibility	0.20	Can users undo what they did inside this design? Cancel, revert, restore, change-of-mind paths.
System-side reversibility	0.20	Can the team roll back the change? Feature flag, deploy revert, data migration reversibility.
Detection latency	0.20	How quickly will the team know if this change is wrong? Telemetry, error tracking, support tickets, business metrics.
Blast radius	0.20	If wrong, how many users does it affect before someone can intervene? 5 percent rollout is small; 100 percent is large.
Pre-commit checks	0.20	What gates does the change pass through before broad release? Internal test, beta cohort, percentage rollout, holdback.