Corrections must update future judgements, not just the current one

What it is

When users correct a context judgement, their expectation is almost never "get this one right": someone saying "I wasn't asleep" means stop concluding this in this situation — the correction carries a rule, not an event. A system that only overwrites the current output while the judging mechanism stands untouched reproduces the same error tomorrow; the user's experience is "telling it was pointless".

Correction therefore has two semantic layers: the current-instance fix (overwriting this output) and the future update (changing the mechanism that produced it — rule, threshold, or model). The minimum is the current-instance fix; what redeems the promise of correction is the future update: when the same context recurs, the judgement has already changed.

Why it happens

Why does fix-only-once necessarily fail? Because a context judgement is the repeated output of a mechanism: the same sensor readings, the same hour, the same rule will re-derive the same wrong conclusion tomorrow. Overwriting the snapshot leaves the mechanism in place — the error is not fixed but paused, replaying at the next trigger.

Full correction requires the system to generalise the single veto into unseen future contexts — and that is the hard part. One "wrong" carries minimal information (a single negated point); to infer what in the mechanism should change, the system must guess the scope of generalisation: this hour range? this room? this sensor combination? Too narrow, tomorrow errs again; too broad, correct judgements break. Both failure directions of the generalisation guess have costs — this is the real technical core of correction design.

A third mechanism sits on the user side: when corrections go unredeemed, users escalate the cost of their own effort — first correcting, then complaining, finally routing around (switching off the misjudging feature). Each step reduces the feedback the system receives, until it goes deaf. The feedback channel's survival depends on the plain expectation that feedback works.

Studying it

• Interactive machine learning studies feedback semantics systematically: how a single negative sample shapes subsequent prediction depends on learning rate, generalisation boundary, and the framing of the feedback. That literature's finding — user feedback carries one correction with multiple readings — transfers directly.
• Preference learning and online learning supply the algorithmic frame for "update from corrections": corrections enter the loop as labelled samples; the evaluation metrics are the drop in same-class error rate after update and the rise in new errors (overgeneralisation) — the two curves must be read together; reporting only the first encourages recklessly aggressive learning.
• Evaluation paradigm: inject a fixed sequence of same-class judgement errors in deployment and compare "current-instance overwrite only" against "with future update" at the second and third occurrence; also track repeat-correction rate — after how many corrections of the same error the user gives up, a behavioural measure of whether the correction promise was redeemed.

One methodological caution: evaluate "future update" over a long enough window — the benefit of learned updates surfaces weeks later, and short A/B tests systematically understate it; overgeneralisation damage is equally lagged, so too short a window sees neither side.

Where it stops holding

• Not every correction should generalise. Sometimes the user wants exactly one exception ("letting me sleep on the sofa today" changes nothing about sleep judgements) — which is why the entry point must separate "this once" from "from now on" and let the user choose, rather than guessing for them; a wrongly generalised correction damages trust more than no generalisation.
• Rule-based judgements have limited update paths. An if-then judgement has no tunable model; correction can only amend conditions or add exceptions — update granularity is discrete, often jumping between "too narrow" and "too broad", far less smooth than learned updates. State the limitation honestly rather than pretending to have learned.
• Corrections on shared devices contaminate co-residents. Two partners on different schedules: one's "stop judging it this way" degrades the other's accuracy — corrections in shared context must route through per-person models, or correction becomes zero-sum.

Applying it

• Have the correction entry point ask one question about scope: just this once / all similar cases / also review the sensor settings. Three explicit tiers, never defaulting to the widest on the user's behalf.
• After each correction lands, give a verifiable receipt: "updated — phone-stationary after 10 p.m. no longer counts as asleep" — stating the generalisation scope out loud gives the user the chance to catch "you generalised too far" on the spot.
• Maintain a correction history: which corrections are active, to what scope, how often triggered since — the user's review entry and the data source for systematic-bias analysis alike.
• How to check: track "average corrections per user per error class" — passing means the same person's same error stops after one correction; monitor the post-correction new-error rate (the overgeneralisation metric) alongside. Together the two form the acceptance test for "future update".

Related

• Same group: Z2.08.1 Correction entry points must appear the moment the judgement takes effect · Z2.08.3 Uncorrectable judgements lose user trust · Z2.08.4 Frequent corrections signal systematic bias in sensors or models
• Nearby: Z3.04 Implicit and explicit interaction coexisting · Z3.07 Automation and habits shaping each other
• Search terms: corrective feedback · interactive machine learning · preference learning · overgeneralisation