Emergency Override Retirement & Cleanup Readiness Review

NOT READY

Case analyzed

During an outage we enabled a global 'skipFraudHold' override so paid orders could continue. The vendor is healthy again, but the flag has stayed enabled for three weeks. Support created a manual review spreadsheet during the incident and one regional job still reads the override directly.

The supplied facts are sufficient to perform a concrete readiness review for this case. No repository, production, vendor, or legal access is assumed.

Verified evidence

• VERIFIED: skipFraudHold is still globally enabled three weeks after the outage.
• VERIFIED: The fraud vendor is healthy again.
• VERIFIED: Support created a manual review spreadsheet.
• VERIFIED: One regional job still reads the override directly.

Concrete findings

1. The override is not ready for removal merely because the vendor is healthy; the regional job and manual spreadsheet are dependencies created during the incident.
2. A three-week global override has become operational state and needs an owner, expiry decision, and removal evidence.
3. Change the regional job back to normal fraud-decision flow before disabling the flag.
4. Reconcile/retire the support spreadsheet or assign it an explicit owner; otherwise manual review work can be stranded.
5. The admin bypass similarly remains unsafe while the runbook still references it.

The canonical acceptance rule is

An emergency override is ready to retire only when the original failure is resolved, all consumers and compensating procedures are known, removal has a bounded rollback path, and post-removal evidence proves normal controls are authoritative again.

The current result is based on that invariant, not on a generic success banner or a reusable checklist.

Required actions

1. Override Inventory: close thi