Overly fine explanations expose more sensor detail than necessary

What it is

Explanations must be concrete — but concreteness has a ceiling: past it, the explanation hands out more sensor detail than the judgement ever needed. Explaining "you were judged asleep" down to "the bedroom microphone detected snoring" simultaneously informs everyone within earshot that there is a microphone in the bedroom, that it captures sound, and that it can recognise snoring — three facts unnecessary for understanding the judgement and very useful for mapping the surveillance.

Explainability and privacy trade directly along the granularity dimension, which runs roughly four tiers: function ("sleep monitoring is running"), signal class ("based on sound and motion signals"), device ("the bedroom microphone, by the bed"), and raw data ("last night's snoring, 23:14–6:32, recorded"). Finer means more falsifiable and more correctable — and more exposed.

Why it happens

Why does exposure grow non-linearly with granularity? Because a fine-grained explanation leaks not just this judgement's grounds but the system's hand:

• Device-tier explanations expose the sensing layout. The words "bedside microphone" hand over device type, placement, and sensitivity in one stroke — the listener completes, without any probing, a map that would otherwise require reconnaissance. For temporary presences — guests, nannies, repair technicians — a single explanation is an inventory.
• Raw-data explanations expose retention. Being able to replay "the snoring at 23:14" shows the system stored the audio — a severity class above "monitoring": monitoring is present tense, retention indefinite future tense. Users read "being recorded" as far graver than "being sensed", and an explanation that blurts out the former doubles the trust damage.
• Granularity, once given, cannot be withdrawn. No interface offers "unhear this explanation" — someone who has seen the device tier cannot return to knowing only the function tier. Every granularity choice is an irreversible disclosure decision; the rule is "least that suffices", every time.

The opposing force is equally real: insufficient granularity makes the explanation unfalsifiable (against the concrete-signal requirement), leaving corrections nowhere to start. So this is a genuine two-sided constraint, not "coarser is safer" — at function tier the explanation exists in name only.

Studying it

• Privacy's communication privacy management theory supplies the analytic tool: disclosure rules vary with relationship (owner / guest) and situation (routine / fault) — a granularity policy is precisely such a boundary rule set, and its methods (audience-by-tier acceptance measurement) transfer.
• Explainability-system evaluation carries over: pair one judgement with explanations at several granularities, group by audience, and measure three things — falsifiability (can users catch errors against reality), correction hit rate, and privacy discomfort. The three curves run differently against granularity; their crossings locate the sensible tier per audience.
• A broader empirical anchor: smart-home studies repeatedly find users unaware of what devices capture — the other half of the granularity question is where the default tier sits and who gets a path to deepen it.

One methodological caution: audiences must include non-account-holders. Most studies test only owners; for a guest or a child, "there is a sensor here" is itself the news, and the same sentence does categorically more damage. Treat audience as an independent variable, not a controlled one.

Where it stops holding

• Fault time is the exception. Debugging genuinely needs device- and even data-tier detail — whitelist a "fault mode": expand after identity verification, while everyday explanations stay at signal-class tier. Risk and diagnostic need invert here; one ruler will not serve both.
• Least-that-suffices depends on the action. For "what is the system thinking", function tier suffices; for "correct this misjudgement", signal class is needed; only "fix the sensor" requires device tier. Let granularity follow the action the user is trying to perform, not a global setting.
• Attribution explanations from learned models skew fine by default. Feature attribution tends to list every contributing feature (stationary devices, location, hour, Wi-Fi state …) — half a sensor inventory. Select and merge features deliberately; full dumps are not acceptable by default.

Applying it

• Default explanations stop at signal-class tier ("based on overnight sound and motion signals"); reaching device tier takes one explicit step (long-press / expand), offered only in fault-debugging contexts.
• Raw data never enters explanations — playback capability lives behind its own authorisation flow (owner verification), separate from the explanation entry.
• Run every explanation string through an audience check: if a guest heard this, if it were screenshotted and forwarded — what leaks? Device model, placement, retention policy appearing in explanation copy requires review sign-off.
• How to check: a red-team audit — feed the product's entire explanation corpus as input and see how complete a sensing-layout map can be assembled. Completion beyond signal-class tier fails; include the screenshot-out-of-context scenario (information carried once the explanation travels).

Related

• Same group: Z2.07.1 The system's current context judgements must be viewable by users · Z2.07.2 Invisible context judgements make behaviour changes seem causeless · Z2.07.3 Explanations must name the concrete signals behind a judgement
• Nearby: Z6.05 Sensors and cameras in the home · Z6.08 Physical indicators of capture state
• Search terms: explanation granularity · privacy trade-off · communication privacy management · smart home privacy