The system's current context judgements must be viewable by users

What it is

Context inference runs in the background; users meet only its consequences — the lights changed, the recommendations rotated, the message stayed silent. The minimum of intelligibility: the system's current judgement — where I am, what I'm doing, what state it assigns me — must be viewable at any time.

This is half of the accountability requirement from context-aware computing: the system must not only act, it must be able to answer "what do you currently take me to be doing". The other half — disclosing the basis of the judgement — is a deeper demand; this entry claims only the first layer. Without it, explanation, correction, and trust have no footing: a user who cannot see what the system "believes" cannot begin to correct it.

Why it happens

Why must a background judgement be explicitly viewable? Because between the inference and its consequence sits a layer of reasoning the user cannot see. In conventional interfaces action and result connect directly (press the switch, the light goes off); in context-driven systems a hidden link — the system's reading of the situation — is spliced in between. A wrong judgement produces a wrong consequence, and the user sees only the wrong consequence, never the wrong judgement.

A viewable judgement turns that hidden link into something inspectable. Its value is not just informational: the judgement is the precondition for correction — without knowing the system took "left home" for granted, the sudden arming of the alarm is inexplicable and unchallengeable. Viewability also generates its own quality pressure: a judgement written down for human inspection stops being satisfiable with "close enough".

And in memory terms, ambient systems offer no screen and no session in which system state would come along for free; without an inspectable entry point, the user's entire knowledge of the system comes from reasoning backwards from consequences — a slow and error-prone route.

Studying it

• Bellotti and Edwards (2001) established intelligibility and accountability as core human considerations for context-aware systems: they must surface what they sense and what they have concluded from it. The pair became the skeleton for a decade of work on explainable intelligent systems.
• Lim and Dey's CHI 2009 survey assessed the demand profile for explanations: across context-aware applications, users most want to know "what the system currently concluded" and "why it did / did not trigger" — the former is precisely this entry's claim. Demand for viewability precedes demand for explanation.
• Measurement is mature: compare provision versus absence of a judgement view on trust scales, mental-model accuracy (have users predict the system's next behaviour), and fault-attribution accuracy.

One methodological caution: usage frequency of the view is not an effectiveness metric — a judgement view is a fire extinguisher, rarely looked at, catastrophic to reach for and not find. Evaluate reach time under failure scenarios, not daily click-through; low usage is not low value.

Where it stops holding

• Viewable is not always shown. Pushing live judgements in front of users violates disappearance in ambient computing. The right shape is quiet presence, available on demand — a one-entry list of current judgements, not a standing notification.
• Judgement granularity is privacy-bounded. Showing "the system believes 2 people are in the living room" is enough; itemising the underlying sensors creates exposure instead — that trade-off is a separate problem. This entry claims only that the result is viewable.
• For people present without accounts (guests, children), viewability cannot be fully realised in product form; for them, judgement visibility is only partly covered by room-level indicators. Acknowledging the gap beats pretending it is closed.

Applying it

• Provide a current-judgement view: everything the system currently believes — presence, location, activity, the live conditions of every automation — in one screen, at a fixed entry point (not relocated between releases).
• Keep a queryable history of judgement changes: "why did the heating come on at 2 a.m." is answered by last night's judgement log, not by anyone's memory.
• Attach an action to every line in the view: confirm, correct, or jump to the related automation settings. The endpoint of viewability is editability, not a resigned sigh.
• How to check: in fault drills, time how long it takes to get from an anomaly to the system's judgement at that moment; in spot checks, score users on "what does the system currently think you are doing". Together the two numbers form the acceptance test.

Related

• Same group: Z2.07.2 Invisible judgements make behaviour changes seem causeless · 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: Z2.08 Correcting context judgements · Z7.01 Making system behaviour explainable
• Search terms: intelligibility · accountability · context-aware systems · explainable intelligent systems