A correction should carry to later similar inferences, or users will keep fixing the same error

What it is

After someone rejects “this is not stress,” if the next matching signal pattern is labeled stress again, the correction was only a one-shot undo. A correction must rewrite later similar inferences: a threshold, a template, or a rule. Otherwise the person is training the system and the system is not learning; labor repeats without bound.

Why it happens

A single undo changes world state (do-not-disturb off) and does not change the policy that produced it. Similar means the same signal kind, the same conclusion label, a nearby situation. Transfer can be: raise the gate for that class, add this feature snippet as a negative, disable that conclusion in this place. Without transfer, users learn “tap every time,” which costs more than having no correction, because discovery cost has already been paid. Over-transfer hurts too: pushing one “not stress” onto every arousal rise will suppress real load. Transfer therefore needs a scope: label × situation, not a global kill of the sensor.

Studying it

In a repeated-elicitation protocol, after the first correction measure whether later similar trials still fire. Factor: transfer scope (this once / this place / this label globally). Outcomes: count of repeated corrections, misses from over-transfer, whether users understand what changed. Contrast “Undo the UI only” with “Undo plus write into a personal model.” Whether it still holds the next day is calibration lifetime and should be reported separately.

Where it stops holding

Correction transfer on safety alarms is constrained by regulation; annoyance cannot be allowed to smash recall. On a multi-user device, one person’s correction must not silently become another’s model. If the user is correcting a one-off situation (“today it was the stairs”), migrating to “always ignore heart-rate rises” is the wrong scope. When scope cannot be expressed, let people choose “this once / not again” rather than write globally in silence.

Applying it

• After a correction, offer scope: undo only / not in this situation / stop using this label.
• Write the choice into a viewable rule list that can later be deleted, so personalization is not a black box.
• Put the definition of similar in the spec (same label plus same place or same signal kind) so it can be tested.
• Verify by creating three similar false inferences in a row; the user should need to correct only the first. If all three need a tap, transfer did not happen.

Related

• Same group: C9.13.1 Users should be able to see which signals the system currently used to draw which inference · C9.13.2 A correction control must appear with the inference result, not buried in settings · C9.13.4 Implicit inferences that cannot offer a correction path should not change user-perceptible UI behavior
• Adjacent: C9.10 Individual Calibration and Baseline Drift · C9.06 Cost of Sensor False Positives
• Search: correction transfer · personalization from undo · repeated false inference