| name | mindit-correctability |
| description | Analyze how reversible a design is if it turns out to be wrong — both user-side undo and system-side rollback. Use this whenever the user asks about launch risk, rollout plan, A/B tests, feature flags, telemetry, monitoring, kill switches, "what if we're wrong," or "how do we know when to roll this back." Also trigger when the user is about to ship a broad-impact change (default change, pricing, schema migration, brand refresh). Produces a structured decision artifact with score, criteria, and anti-pattern matches. |
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
-
Identify the decision. What specifically is being shipped? Who is affected? What state changes?
-
Map the recovery dimensions. For each criterion, ask both "can we" and "have we planned to."
-
Distinguish "reversible in theory" from "reversible in practice." A change is only practically reversible if the rollback is planned, rehearsed, and instrumented.
-
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.
-
Check anti-patterns.yaml.
-
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. |
Anti-patterns
See anti-patterns.yaml. Brief list: no-rollback-plan, big-bang-launch, blind-flight, one-shot-migration, silent-failure, kill-switch-never-tested, telemetry-as-afterthought, all-users-or-none.
Output format
Two files in .mindit/decisions/. Filename: correctability-<yyyymmdd>-<slug>.{md,json}.
JSON conforms to schemas/decision.schema.json with skill: "mindit-correctability" and force: "correctability".
Example
Input: "We're rolling out a new default sort order for the inbox to all users on Tuesday."
Sample findings:
- User-side: users can manually change sort and the choice persists. Match: positive. Severity info.
- System-side: behind a feature flag, deploys can revert in minutes. Severity info.
- Detection latency: no telemetry on sort order interactions. Team will detect the issue only through support tickets. Match:
telemetry-as-afterthought. Severity high.
- Blast radius: 100 percent rollout day one. Match:
all-users-or-none, big-bang-launch. Severity high.
- Pre-commit: no beta cohort, no percentage ramp. Match:
big-bang-launch. Severity high.
Sample weighted score: 38.
Suggested next action: instrument sort interactions, ramp 5 → 25 → 100 percent over two weeks, define rollback trigger (e.g. >X% of users manually reverting within 24 hours of exposure).
What this skill does NOT do
- Does not require every change to be correctable. Some changes (security patches, legal compliance) ship to 100 percent on purpose. The skill surfaces that this is the case so the team confirms it.
- Does not design the rollback. It checks whether one exists and is tested.
- Does not measure post-launch outcomes. It measures the design's readiness to handle wrongness.
