Correction entry points must appear the moment the judgement takes effect

What it is

Errors in context judgements are almost always noticed at the moment the judgement surfaces: the lights went off because "left home" was concluded, the recommendations rotated because "resting" was concluded — and right there, beside the visible consequence, is the user's only chance to say "wrong". The correction entry point must live in that moment: where the judgement takes effect and the behaviour appears, adjacent to the consequence.

"You can change it later in Settings" fails this requirement. The judgement view sits buried in menus; by the time the user arrives, the scene of identification is gone — reconstructing "what it thought, what was actually true" becomes an act of memory. The error-reporting window is open at the scene and closed by the settings page.

Why it happens

Why is timing the lifeblood of correction? Because all the information correction needs is complete only in situ:

• The judgement itself: what the system currently believes ("away") surfaces together with its consequence; afterwards it takes recall or log-digging.
• The reality check: only at the moment of the behaviour can the user certify "it got this wrong" — seeing the lights off at night, immediately knowing they are home; the next day it is only "the lights maybe turned themselves off at some point".
• The semantics of the fix: an in-situ correction carries its context (amend this judgement, this class of judgements, or the sensor behind it); out of context, a settings-page correction reduces to an isolated toggle.

Behind this sits a robust empirical regularity: the quality of error reports decays steeply with the interval between event and report — details go first, then confidence, then the report itself. Putting the entry point at the scene compresses the cost of reporting an error to one tap; parking it in Settings raises the cost to "recall + navigate + reconstruct", and the gap between those two costs decides that most corrections never happen.

The same holds system-side: a correction in place arrives with the richest training signal. Current raw sensor readings, the judgement output, and the user's veto align into one high-quality sample; a delayed correction has lost the sensor scene and can patch only a lonely conclusion, teaching the system nothing.

Studying it

• Interactive machine learning and end-user debugging research repeatedly confirm that the immediacy of feedback drives both willingness and quality — in-place correction during use far outperforms after-the-fact batch labelling. The methods of that literature (feedback-cost measurement, timing contrasts) transfer directly to context judgements.
• Experimental paradigm: give the same judgement error two versions — in-place entry point versus settings-page entry point — and measure correction rate (what share of errors gets reported), correction accuracy (was the right thing changed), and the system's repeat rate for the same error. The third measure is the tell: no correction, no learning.
• Timing itself can be the variable: delay the entry point's appearance across 0 s / 30 s / 5 min / next day; the decay curve of correction rate against delay gives the product its timing budget.

One methodological caution: separate capability from habit in measurement. Correction rates are naturally low right after launch (users don't know the entry exists); evaluate on steady-state data, and measure the capability ceiling in controlled fault-injection scenarios — read the two numbers separately.

Where it stops holding

• In place does not mean interruptive. At the moment the judgement takes effect, the entry point must be present (in the notification, at the state change, tappable) without being modal; high-consequence corrections warrant an explicit prompt, low-consequence ones fold into an expandable region. Timing and interruption are separate problems — "fear of disturbing" cannot be used to veto timing.
• For judgement types never learned, in-place correction has no footing: with categories the user has never seen (a new sensor introducing a new dimension), the user doesn't know the grammar of "what it believed" — judgement viewability has to come first; correction follows.
• Batch errors (a systematically wrong class of judgements) don't fit piecemeal in-place correction — the in-place entry captures the single instance; pattern-level amendment goes through correction history → bulk apply. In place is the first link, not the whole chain.

Applying it

• Hang a correction entry point on every place a judgement-driven behaviour surfaces (notification, state change, automation run): one tap for "wrong", expanding to a choice of granularity (this once / this class / the underlying sensor).
• Show the explanation on the same screen as the correction: see "why it concluded this" before deciding what to correct — an entry point with a conclusion but no grounds invites blind tapping.
• Make the correction take effect immediately with a visible receipt: "fixed — no more away-judgements tonight". Behaviour snapping back to expectation right away is the only trustworthy confirmation that the correction landed.
• How to check: inject known judgement errors and measure time from error surfacing to completed correction, plus correction rate; run the same two measures on the settings-page path. The in-place path should win both, and the recurrence rate for that error class should drop after correction.

Related

• Same group: Z2.08.2 Corrections must update future judgements, not just the current one · Z2.08.3 Uncorrectable judgements lose user trust · Z2.08.4 Frequent corrections signal systematic bias in sensors or models
• Nearby: Z2.07.1 The system's current context judgements must be viewable by users · Z3.03.2 Correction entry points belong where the outcome occurred
• Search terms: just-in-time correction · end-user debugging · interactive machine learning · error reporting