Invisible context judgements make behaviour changes seem causeless

What it is

While context inference stays backstage, the system's behaviour changes appear causeless to users: the assistant's recommendations rotated today, the automation fired early, notifications went quiet. The behaviour was driven by a change of judgement (from A to B); what the user sees is only "it changed for no reason".

Causelessness is not a neutral cognitive state. Confronted with unexplained changes in behaviour, people manufacture explanations, and the manufactured ones rarely flatter the system: it's broken, it's watching me, it has it in for me. Months of reliable operation can build trust that a few causeless changes drain — because in the story the user writes to fill the blank, the system plays the fault or the suspect, almost never the well-meaner.

Why it happens

Three stacked pathways:

• An attribution vacuum gets filled. When everyday causal expectation breaks, "no reason" is unacceptable; people construct one from available material. For ambient systems the material is terrible: no visible judgements, no visible sensors — just "how it behaved lately" and "what I've heard smart devices do". The assembled story bends naturally toward malfunction and surveillance.
• Change and cause are separated in time. The context changed at t₀ (a guest arrived, a routine shifted, the season changed the sensor signature); the behaviour surfaced at t₁, inference latency in between. The user observes at t₁ and cannot trace back to t₀, even though the system "had its reasons".
• Irreproducibility deepens the magic. The same action does this today and that tomorrow (because context differs), so no stable stimulus-response model forms; the conclusion is "this thing has moods" — and a moody system is neither predictable nor trustworthy, the standard prelude to users giving up on learning it.

The third pathway deserves emphasis: behaviour varying with context is the function of context awareness, not a defect. What makes it look like random jitter is the invisibility of the judgement, not the existence of the change.

Studying it

• Attribution theory supplies the frame: explanations for unexpected behaviour are constructed along stability, controllability, and locus dimensions; under missing information, locus skews systematically outward and hostile — the mechanism behind "it's doing this to me".
• Explainability research provides direct evidence: Lim, Dey and Avrahami's CHI 2009 experiment compared versions with and without why / why-not explanations; the explained versions improved users' understanding and acceptance, with the largest gains for the did-not-trigger case — precisely the moment of strongest causelessness.
• Measurement paradigm: inject legitimate, reasoned judgement changes in deployment and observe explanation-seeking behaviour — support requests, attributions made, time to abandonment — against a group with a visible judgement view. Dependent variables: attribution accuracy, support volume, trust-scale trajectory.

One methodological caution: the researcher's "legitimate reason" and the user's accepted reason can differ. Why it was designed this way must itself be explainable ("because your arrival times shifted last week"); explaining the mechanism without the design intent removes only half the causelessness.

Where it stops holding

• Not every change needs explaining. Routine high-frequency fluctuation (small temperature trims) explained every time becomes noise bombardment and gets ignored faster; what needs explaining is the change of pattern — moments where the category, timing, or scope of behaviour jumps. Distinguish by magnitude and persistence, not frequency.
• Explanation does not rescue a bad judgement. When the judgement itself is wrong, the explanation merely exposes the error sooner — good (it becomes correctable), but no substitute for accuracy.
• Baselines differ across users. Technically fluent users assemble more accurate stories and absorb causelessness better; for users unfamiliar with smart devices, one causeless change settles the verdict. Evaluate by user stratum — tolerance measured on the former must not set the design bar for the latter.

Applying it

• At every pattern change, attach one light line of attribution: "the lights came on early today because you got home an hour before usual" — one sentence, naming the concrete context difference, no technical digression.
• The non-event needs an entry too: an expected automation failing to fire is the strongest causelessness moment; in the judgement view, mark which condition went unmet.
• Attribution copy must be traceable: tap the line and see the full judgement at that moment. One sentence dissolves the causelessness; the full record survives the follow-up question.
• How to check: track support requests and "turn this off" actions within 24 hours of a pattern change; count separately for changes with and without attribution lines. A persistently lower rate on the attributed side is the effect.

Related

• Same group: Z2.07.1 The system's current context judgements must be viewable by users · Z2.07.3 Explanations must name the concrete signals behind a judgement · Z2.07.4 Overly fine explanations expose more sensor detail than necessary
• Nearby: Z3.03 Failure of intent inference · Z7.01 Making system behaviour explainable
• Search terms: unexplained behaviour · why-not explanations · attribution · trust in automation