| UI or UX | UI + UX - Pre-execution review of high-impact actions that may affect money, access, production systems, legal status, customers, external recipients, or safety | UI + UX - Final destructive commit review | UI + UX - Exact target phrase gate before severe commit | UI + UX - Runtime checkpoint that pauses AI or automation until an eligible human authorizes the next step | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Security-risk warning and safe interruption before unsafe navigation, download, submission, preview, or sensitive action |
| UI guidance | Render dangerous-action review as a pre-execution checkpoint that names the armed action, actor, target, scope, affected systems, external effects, risk reason, evidence, freshness, permissions, alternatives, and exact outcome of Run, Cancel, Edit, or Escalate. | Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription. | Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables. | Render a human approval gate as a paused automation checkpoint with the proposed action, tool or workflow step, triggering rule, risk level, payload snapshot, requester or agent, approver eligibility, timeout, and explicit approve, reject, edit, cancel, or bypass controls. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Render a security warning as a high-clarity interruption that names the detected risk, identifies the destination or object, explains the concrete threat, presents the safest action as the primary path, and separates any override behind deliberate risk detail. |
| UX guidance | Help users decide whether to run, revise, cancel, defer, or escalate the action by making the action payload inspectable, comparing it with safer alternatives, revalidating stale state, and recording what the reviewer saw before execution. | Make the safe path explicit and easy, keep the destructive action unavailable until required review is satisfied, and report whether the object was kept, blocked, or permanently committed. | Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential. | Use human approval gate when automation is ready to act but policy, risk, confidence, cost, access, publication, deployment, customer impact, or legal consequence requires a human decision before execution continues. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Use security warning when a product, browser, operating system, or service has evidence that proceeding could expose credentials, install harmful software, leak sensitive data, bypass trust, or weaken account protection. |
| Good UI | A production console shows Restart payment workers, affected region, open incidents, customer impact, rollback owner, evidence links, change window, dry-run result, and Run restart only after the reviewer checks the risk inventory. | Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project. | Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository. | An AI support agent pauses before issuing a refund, shows the proposed amount, customer, policy match, confidence, source grounding, approver role, timeout, Approve refund, Edit amount, Reject, and Stop run controls. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | A browser interstitial says Deceptive site ahead, shows the suspicious domain, explains that attackers may steal passwords, and makes Back to safety the primary action while placing Visit unsafe site behind Details. |
| Bad UI | A warning says This may be risky but hides the target, policy trigger, evidence, and whether the action can be undone. | A soft archive action opens the same severe deletion confirmation used for permanent account closure. | The typed field is masked like a password, making users unable to check the repository name they entered. | A reviewer can approve an automation run after the action already executed, making the gate only decorative audit text. | Change links lack context, so assistive technology users hear a list of identical Change links. | A red page says Security issue with Continue as the only visible action. |
| Good UX | A release manager sees that a deploy action affects production EU, has a stale smoke test, cancels execution, refreshes checks, and then runs the action with an audit record. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository. | A billing lead opens the paused refund gate, sees that the amount is under policy but source grounding is partial, edits the refund to the verified amount, approves, and the agent resumes only that step. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | A user clicks a payroll link that visually resembles the company domain, sees the suspicious-domain warning, returns to the trusted site, and reports the link to security. |
| Bad UX | A user approves a notification from email after the underlying payload changed, and the system executes against a different customer. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | A user believes typing the phrase is the only safeguard, but the dialog hides forks, members, billing effects, and recovery limits. | A human approves a stale agent action from email and the agent applies it to a different customer state. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A user sees a vague warning, assumes it is routine maintenance, proceeds, and enters credentials into a phishing page. |
| Best fit | A user, agent, automation, or admin tool is about to execute a high-impact action that can affect money, access, production systems, legal/compliance state, customers, external recipients, sensitive data, or safety. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope. | An AI agent, workflow, deployment, or automation is ready to perform a high-impact step and must pause for human authorization. | A user has provided multiple answers and should verify them before a consequential submit action. | A threat signal indicates phishing, malware, deceptive site, unsafe download, invalid certificate, insecure connection, mixed-content submission, suspicious redirect, file preview risk, or account-security danger. |
| Avoid when | The risk is narrowly permanent deletion or loss of a named object; use destructive action confirmation. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The action is routine, reversible, local, or recoverable through undo or trash restore. | The action has already happened and users only need an audit log. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The message is only a general severe consequence before a product action; use warning text. |
| Required state | Armed action state with verb, target, payload, actor, source, and exact execution boundary. | Review state that names the destructive verb, target object, and affected scope. | Required phrase state showing the exact target phrase to reproduce. | Paused gate state with proposed action, payload snapshot, reason for gate, and run context. | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Safe path state with primary Back to safety, Cancel, Remove, Use trusted route, or Contact admin action. |
| Accessibility burden | Use headings and labels that name the action and target before risk details. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Associate the input with a label that includes or references the required phrase. | Expose gate status, proposed action, target, payload summary, risk, approver rule, timeout, and current run state as text. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Use a heading and text that name the risk before the destination or details, so screen reader users hear the warning context first. |
| Common misuse | Showing a risk warning but hiding the action payload, target, recipients, amount, command, environment, or external effect. | Labelling the destructive commit OK, Yes, Continue, or Confirm. | Requiring users to type yes, confirm, or delete instead of the target name. | Using a post-action audit record as if it were a pre-action human gate. | Labelling the final commit button Continue. | Making Continue the primary or only visible action. |