Confirmation Dialog with State Refresh¶

Interactive confirmation tool — instantiates Use-Time Precondition Binding

Re-fetches the live state the instant a person clicks confirm and shows it — with what changed highlighted — so the human commits against current reality, not the stale screen they were looking at.

When the actor is a human, the check–use gap is the time between loading a screen and finally clicking "do it" — seconds or minutes during which the numbers on screen may go stale. Confirmation Dialog with State Refresh binds the person's consent to use-time truth: at the moment of confirmation it re-fetches the live state the action depends on, renders it inside the prompt, and highlights what has changed since the user last saw it. Its defining move is that the confirmation is not a rubber stamp on the old view but a fresh look — the human re-consents against reality as it is now — and, because that friction has a cost, it is spent selectively on the high-stakes, hard-to-reverse actions where a stale decision would actually hurt.

Example¶

A retail brokerage customer pulls up a stock quoted around 50 dollars a share and clicks "Buy 100 at market." Between loading that page and reaching the confirm step, the quote jumps to ≈53.20 on a news headline. A naïve app would confirm against the 50.00 the user last saw. Confirmation Dialog with State Refresh instead re-fetches the live quote at the confirm click and shows: "Live price 53.20 — up from 50.00 when you started. Estimated cost ≈5,320 for 100 shares. Confirm order?" — with the price delta called out. The customer now re-consents against the real price, or backs out, having never been quietly committed to a number that no longer exists.

The dialog's value is entirely in the refresh. A confirmation that re-displayed the original 50.00 would be worse than none: it would launder a stale figure into an informed-looking decision.

How it works¶

The refresh is pinned to the click, not a timer. State is re-read at the moment of intent, so the picture the user approves is the picture at the instant of use.
It surfaces the delta, not just a number. The prompt highlights what changed since the user's last view, because a value shown without contrast is a value nobody re-reads.
It can gate on the size of the change. A small drift may just display; a change past a threshold can require an explicit re-acknowledgement or block outright.
It is rationed by stakes. Only actions whose risk warrants the interruption get the refresh-and-confirm; low-stakes actions proceed without it.

Tuning parameters¶

Refresh trigger — on dialog open, on the final click, or both. Later is fresher but leaves less time to read.
Delta emphasis — show current state only, highlight what changed, or force a re-acknowledgement when the change crosses a threshold.
Friction level — a single extra click, a type-to-confirm, or a cooling-off delay. More friction catches more errors but erodes faster into habit.
Stakes gate — which actions earn the dialog at all. Set too wide, it trains users to click through everything; too narrow, it misses a genuinely risky action.
Staleness tolerance — how old a cached read may be before a forced live re-fetch.

When it helps, and when it misleads¶

Its strength is catching the whole class of "the world moved while I was deciding" human errors on irreversible acts: the price that jumped, the balance already drained, the seat someone else just took, the recipient edited after the amount was entered. It converts a blind confirmation into an informed one at the exact boundary where the human commits.

Its failure mode is confirmation fatigue. If every action raises a dialog, people learn to dismiss them reflexively, and the one that mattered is clicked through with the rest — the safety value collapses through habituation^[1]. The classic misuse is the confirm-as-liability-shield: a dialog added everywhere for cover that either doesn't truly refresh the state (theater) or asks so often it trains the very inattention it was meant to prevent. The discipline is to refresh for real, make the change impossible to miss, and ration the interruption to the high-stakes actions where it still commands a second look.

How it implements the components¶

Confirmation Dialog realizes the human-in-the-loop side of the archetype — binding a person's consent to current state at the point of action:

use_time_state_evidence — it re-fetches and displays the live state at confirm time, making the evidence the human acts on genuinely use-time evidence.
use_action_boundary — the confirm click is the precise boundary the refresh is pinned to, so consent and use coincide.
risk_tiered_gap_budget — it spends the friction of a refresh-and-confirm only where the stakes justify it, treating "how much gap is tolerable" as a per-action risk decision.

It re-checks by asking a human, not by rule or token — the automated use_time_revalidation_rule is Final Revalidation Before Commit, and the state_version_or_freshness_token is Compare-and-Swap Version Token — and it does not define the conflict_abort_and_retry_policy for what happens if the user proceeds on a since-changed value, which is Abort-and-Retry After State Mismatch.

Instantiates: Use-Time Precondition Binding — the dialog binds a human's consent to the precondition as it stands at the moment of use.
Sibling mechanisms: Final Revalidation Before Commit · Timestamp and Freshness Badge · Stale Data Revalidation Gate · Compare-and-Swap Version Token · Abort-and-Retry After State Mismatch · Reservation-Commit Protocol · Snapshot-Pinned Decision · Revocation Status Check at Use · Lease-Bound Capability Token · Lock or Hold Until Use · Two-Phase Commit with Freshness Check

Notes¶

This is the human-facing cousin of the automated re-checks. Where Final Revalidation Before Commit re-runs a predicate silently, this mechanism's whole point is to put a person in the loop and make them see the change — so it is the right tool precisely when the judgment about whether to proceed on new information should belong to a human, not a rule.

References¶

[1] Alert (or confirmation) fatigue is the well-documented erosion of response when warnings are frequent: users habituate and dismiss them without reading, so an over-used confirmation dialog can end up less safe than a rare one. It is the core reason to ration confirmations by stakes rather than attach them to every action. ↩