You must: (1) DATA MIGRATION — can we revert data changes without loss? Expand-then-contract, not rename-then-pray. Add columns before removing old ones, (2) ROLLBACK CRITERIA — define EXACT, MEASURABLE thresholds that trigger automatic rollback. Error rate > X% for Y minutes. Latency > Zms. Not "if something goes wrong", (3) BLAST RADIUS — how many users are affected if this fails? Canary (1% → 10% → 50% → 100%). Never all users simultaneously, (4) DOWNTIME — test time estimates on PRODUCTION-scale data. Development database timing is fiction for production, (5) FEATURE FLAGS — user-facing changes require a kill switch. Flag to 0% in 30 seconds vs redeploy in 15 minutes. (6) POST-MORTEM SIMULATION — imagine the change failed at 2 AM. Can the on-call engineer roll back without waking up the team? If rejected, the change is not safe to deploy.Send ALL parameters in ONE call — the analyses above plus YOUR OWN verdict: every PIVOT boolean, verdict and clarification. The engine cross-checks the pivots against the verdict and rejects incomplete or self-contradictory calls.
Structured reflection tool that forces rollback planning, blast radius mapping, and data preservation analysis before any architectural or deployment change ships. Based on the "Pre-Mortem" methodology (Klein, 1998), change management frameworks (ITIL v4), and deployment safety patterns (Accelerate, Forsgren/Humble/Kim 2018). Catches Irreversible Migration (data migration with no rollback path — migration: "ALTER TABLE users RENAME COLUMN username TO display_name." Deployed. Application code updated to use display_name. Bug discovered: the migration broke a reporting service that queries username. Rollback attempt: "ALTER TABLE users RENAME COLUMN display_name TO username." But: the updated application code expects display_name. Now BOTH the old code and new code are broken. Reversible approach: (1) ADD column display_name. (2) Backfill display_name = username. (3) Update application to read from display_name. (4) Verify for 1 week. (5) THEN drop username column. At any point between steps 1-4, the old code still works. Rule: expand-then-contract. Never rename. Never delete until the old path is confirmed dead), Undefined Abort Criteria (no clear threshold for when to stop and rollback — "We will monitor and roll back if something goes wrong." What is "something"? Error rate > what%? Latency > how many ms? For how long? At 2 AM when the deploy finishes, the on-call engineer sees error rate at 3.2%. Is that "something wrong"? The baseline was 2.8%. Is 0.4% increase significant? Without defined criteria: the engineer waits. Error rate climbs to 5.1%. Still waiting. 8.3%. Now it is clearly wrong — but 45 minutes have passed and 12,000 users were affected. Defined criteria: "Auto-rollback if: error_rate > 4% for > 2 minutes, OR p95_latency > 800ms for > 5 minutes, OR any 5xx > 50/minute." These are measurable, automatable, and remove human judgment from a 2 AM decision), Unbounded Blast Radius (the change affects ALL users simultaneously — "Deploy the new payment flow to production." All users. All regions. At once. The new flow has a subtle bug: it rounds currency to 2 decimal places BEFORE tax calculation instead of after. For a $99.99 item at 8.25% tax: Correct: $99.99 × 1.0825 = $108.239175 → rounded: $108.24. Buggy: $100.00 (rounded) × 1.0825 = $108.25. Difference: $0.01 per transaction. At 50,000 transactions/day: $500/day in overcharges. Customer complaints start immediately — but ALL 50,000 daily users are affected. With canary deployment (1% → 10% → 50% → 100%): 1% = 500 users. Error detected at $5/day overcharge. Blast radius: 500 users × 1 day = 500 affected transactions (refundable). Without canary: 50,000 users × 3 days (time to detect + fix) = 150,000 affected transactions), Downtime Surprise (no estimation of unavailability during the change — "The migration should be quick." Migration: add an index to a 200M-row table. Development database (100K rows): 3 seconds. "Quick." Production database (200M rows): 4.5 hours. The table is locked for writes during index creation. Every user action that writes to this table fails for 4.5 hours. Fix: CREATE INDEX CONCURRENTLY (PostgreSQL) — does not lock the table but takes 6 hours. Or: scheduled maintenance window with user notification. Or: create index on a replica, then promote. The time estimate MUST be tested on production-scale data — not development-scale), and All-or-Nothing Deploy (no incremental rollout or feature flag strategy — "Deploy the redesigned dashboard." Old dashboard: removed. New dashboard: 100% of users. Discovery: the new dashboard loads 3.2 seconds (old: 1.1 seconds). Performance regression. Users complain. Rollback: redeploy the old code. Time: 15 minutes (build + deploy + cache clear). During those 15 minutes: every user sees the slow dashboard. With feature flag: dashboard_v2 flag set to 0% → 5% → 25% → 100%. At 5%: performance regression detected. Flag set to 0% — takes 30 seconds. Zero downtime. Zero redeployment. Instant rollback. Feature flags are not optional for user-facing changes — they are the rollback mechanism). Call once per deployment, migration, architecture change, or infrastructure modification