Correction entry points belong where the outcome occurs

What it is

After intent inference errs and the action has executed, the correction entry point must appear where the action's consequence surfaces — the notice that the heating was wrongly switched off carries "turn it back on" right there; the notification of a mis-sent message carries "recall". The moment a user notices the error is the moment correction motivation peaks; an entry point elsewhere (open the app, dig through settings, find the history) forces a journey that races against the motivation window.

This leaf concerns already-executed actions: the result is out, and the question is the shortest path to pressing it back. It differs from the other kind of correction — amending the system's context judgement so future ones stop erring — which belongs to the sensing-inference side; this one is about the present, single, action-level undo.

Why it happens

Why does position matter so much? Because the motivation window is short. At the instant of noticing, attention is centred on that very thing; minutes later it has flowed back into the ongoing task, and correction becomes a fresh interruption — the cost structure flips from "a tap in passing" to "a dedicated errand". The desktop-era finding that undo beats confirmation rested on undo being at hand; ambient computing dilutes "at hand" — actions happen all over space while entry points traditionally gather in one central interface, and the positional mismatch is born there.

A second layer is memory and attribution decay. At error time the user still holds the context (what was happening, what changed); past the window, correcting requires reconstructing "what did the system just do" — precisely what intent-inference actions resist (why did the light go off? who did it?). An entry point at the consequence zeroes the reconstruction cost.

A third layer is physical distance. Consequences surface in physical space (room lights, temperature, locks) while the entry point may live only on the phone, demanding the five-step chain "notice → fetch phone → unlock → find app → find control"; every link leaks. Voice, on-device buttons, and interaction surfaces near the consequence are alternative routes.

Studying it

• Undo research: the classic desktop conclusion — cheap undo supports exploration and outperforms prior confirmation — establishes that undo's value rides on its reachability; ambient settings extend "reachability" from cursor distance to physical and navigational distance.
• Notification interaction research: usability comparisons of actionable notifications — inline buttons versus app round-trips for the same operation — with stable gaps in completion rate and response latency.
• Field deployment comparisons: two recovery paths after the same misfire (in-place undo vs central app), comparing recovery completion, latency, and the share of "leave it uncorrected"; the abandonment rate is the most informative outcome — it directly measures the race between motivation window and path length.

One methodological caution: lab-measured recovery paths run short — participants are on standby with attention already on the system; real errors land mid-life-stream with the motivation window squeezed by the task. Recovery research must sit inside realistic multi-task contexts, or the difference between paths is systematically underestimated.

Where it stops holding

• "At the consequence" fails for invisible consequences. Actions whose effects never surface (silently changed background settings, quietly stopped recording) have no natural mounting point — the problem regresses to making the consequence visible first; adding an undo entry alone means nothing.
• Undo does not cover the irreversible. Sent, purchased, deleted — there is no "press it back"; for these, what the consequence can offer is the reason and a recourse channel, not an undo button — a button there would be a lie.
• "At the consequence" is ambiguous with multiple devices. When a misfire affects several devices, the user sees only the local slice (this room's light); an entry mounted at that device undoes the slice, not the act. The entry must point at trigger-level undo (this automation, this once), not single-device operation.

Applying it

• For every undoable inferred action, mount undo at every position where the consequence surfaces: inline notification button, on-device interaction near the affected device, voice command — at least two of the three.
• Co-present the undo with the reason tag (why it acted + one tap to revert), settling attribution and recovery together.
• Undo acts on this instance, not on permanent configuration: default to undoing once, with the permanent change ("never do this again") as an explicit secondary option — merging the two into one button forces a choice between "I want the light now" and "I want to change the rule".
• How to check: track recovery completion and latency after misfires, watching the "left uncorrected" share above all; the completion-rate gap between paths (in-place vs central app) is the measured value of entry-point position.

Related

• Same group: Z3.03.1 Users often cannot tell why the system did that · Z3.03.3 Uncorrectable inferences get switched off wholesale
• Nearby: Z2.08 Users correcting context judgements · Z3.06 Editing and taking over automation
• Search terms: undo · actionable notifications · in-place correction · reversibility