B3.03.3Irreversible Actiondesignresearch

The system should not make irreversible decisions on the user’s behalf

Aliases: irreversible operation · automated decision · high-consequence action

What it is

For deletion, publication, payment, sending, permission transfer, and data migration, the system must leave the decision to the user or an explicitly authorized process. Defaults, heuristics, cleanup policies, and automatic optimization must not silently assume a high-consequence irreversible action. Automation can prepare, preview, and recommend, but it should not hide the commitment point.

Why it happens

The risk of irreversibility falls on users, organizations, and third parties, while a system default usually relies on narrow signals such as age, similarity, storage pressure, or model confidence. Without explicit confirmation, users may not know a commitment occurred; with aggressive defaults, one mistaken inference can produce unrecoverable data, financial, legal, or relational loss. Control also includes knowing who authorized what and when.

Studying it

Trace the trigger chain of high-consequence actions: who initiated them, which defaults participated, when the actual commit occurred, and whether preview and compensation existed. Experimentally compare default policies, confirmation forms, delay windows, and undo periods while measuring mistakes, approval quality, confirmation fatigue, and later support requests. Audit settings for attributability and authorization boundaries.

Where it stops holding

Not deciding for users does not mean a dialog for everything. Low-risk reversible actions explicitly configured by users should run; a security system may have to quarantine malware automatically, but it must explain afterward and allow appeal. Professional workflows can use batching when preview, permission, audit, and recovery exist. Excessive confirmation makes users click mechanically.

Applying it

  • Inventory irreversible actions and mark trigger, defaults, permissions, scope, compensation, and audit fields.
  • Make automatic cleanup and publication opt-in; for hazardous actions, show object count, consequences, and why the step is irreversible.
  • Where automation is necessary, provide dry run, delayed execution, undo window, and notification so users never absorb consequences unknowingly.
  • Validate with a “misconfiguration plus automatic trigger” scenario and check whether the system can intercept, delay, audit, or recover.

Related

  • Same group: B3.03.1 Every mistaken state needs a clear exit · B3.03.2 Undo and redo support exploration
  • Nearby: Y3 Error Prevention and Recovery · P4 Trust
  • Search terms: irreversible action · destructive operation · auditability

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/B3.03.3