Implicit inferences that cannot offer a correction path should not change user-perceptible UI behavior

What it is

If people cannot see and object to an inference, it must not change UI they can perceive: theme, volume, notification policy, lock keys, outwardly visible state. The inference may sit in an internal buffer, a log, or a low-confidence score, waiting on an explicit channel. Implicitness without a correction path may do imperceptible prep (preload a cache). It may not write the experience.

Why it happens

A perceptible change is a write on the user’s world. Once written, missing an objection freezes error into fact; after the discovery window closes it cannot be recovered. Internal prep (next track in memory, lamp driver warmed) does not occupy that write, and failure stays invisible. The cut is “can a person notice with senses or social consequence.” A background model update that shows up as a different home the next time the app opens is already a delayed perceptible write, and likewise needs correction or should not be done. The rule treats correction capability as a license to change experience, not as a patch afterward.

Studying it

List every observable change in the product driven by an implicit inference and check whether a same-screen objection existed at that moment. Factors: correction present or not, whether the change was designed to be “subtle.” Outcomes: survival time of uncorrected errors, fraction who notice but cannot object. “Subtle” is not an exemption: if it can be noticed, it is not exempt. A control that uses the same inference only for preload tests whether task benefit remains while perceptible error disappears.

Where it stops holding

Legally required alarms that cannot be turned off may change perceptible UI with limited correction, but they must be carved out of convenience implicitness and disclosed on their own. Preload that becomes perceptible through a content flash or a network toast has crossed the line. On multi-person UI, “someone else can see it” is perceptible; do not ask only the wearer. Fully imperceptible analytics (aggregates, offline training) are outside this rule; the moment results return to a personal UI, they are inside.

Applying it

• Before shipping, table implicit inferences as internal prep versus perceptible change; the latter must have correction or the change is cut.
• Inferences that cannot get same-screen correction degrade to a log or a suggestion inbox and do not alter the current experience.
• Changes that appear later (tomorrow’s home) must carry correction at the moment they appear; invisibility at inference time is not an exemption.
• Verify by walking the product with every correction entry disabled: every remaining automatic change that can still be seen is an illegal write.

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.3 A correction should carry to later similar inferences, or users will keep fixing the same error
• Adjacent: C9.05 Implicit Interaction · C9.12 Implicit Interaction and System Initiative
• Search: perceptible UI change · correction as license · preload versus commit