Users must be able to find out what triggered an action

What it is

For every automated action in an intelligent environment, users must be able to look up its cause: which rule, which matched condition, what the sensor values were. "Why did the light turn itself off" should never be an open case.

This is the most frequently needed species of intelligibility — trigger attribution. Unlike the probabilistic "why did you think I wanted this" of inference-based systems, rule-based attribution has a deterministic machine answer: the action was fired by a rule, the rule by a matched condition, the condition by satisfied sensor values — all three precisely recordable. The problem is never that the answer doesn't exist; it is that by default the answer exists only for the instant of execution, and nobody kept it.

Why it happens

Rule systems hold a structural advantage for attribution: the causal chain is deterministic and finite. Sensor value → condition match → rule firing → action execution — four steps, no hidden inference layer. Attribution therefore needs no explanation algorithm: no generative model, no post-hoc rationalisation, only persisting what the execution engine already knew (which conditions it just evaluated, which held).

But by default it persists nothing. The engine's data flow is evaluate-and-discard: condition matches are booleans within an evaluation cycle, dropped once used; retaining them for attribution is extra write load with no functional payoff — until the moment a user asks "why". The engineering's "useless data" and the user's "only lead" are the same bytes; that is the root cause of trigger records requiring explicit demand rather than appearing on their own.

The attribution answer has three components, none optional: rule identity (which rule), condition match (which of its conditions, against what value), and moment context (what other signals were present — to rule out "actually I touched it myself"). An attribution with only the rule identity cannot answer "but why did it fire this time"; with all three, the user closes the loop from phenomenon to cause.

Studying it

• Single-event trace tests: show users an action that occurred in their own home (or replay a deployed log segment) and measure time, steps, and success rate of recovering the trigger chain. This is the direct paradigm that turns "attribution usability" into a metric; smart-home audit and traceability studies (stated generically) rely on it.
• The intelligibility research line: in Lim and Dey's work on explanation needs in context-aware applications, "why" is among the most frequently asked question types — trigger attribution is the why question made concrete for rule systems. Its experimental paradigm (comparing prediction accuracy and trust calibration with and without attribution support) transfers directly.
• Retention-policy comparisons: contrast full retention / action-only / no retention on post-hoc attribution success and storage cost, giving an evidence base for retention granularity.

One methodological caution: separate "found it" from "understood it" when measuring attribution success — an interface that surfaces a rule ID achieves the former; a user who reads "hallway sensor detected motion at 21:04" achieves the latter. The two fail differently (missing records vs. missing wording), so they must be scored separately.

Where it stops holding

• Deterministic attribution holds only for rule systems. Learned automations (behaviours induced from habits) have no rule to look up; attribution degrades to "which signals it was based on" — correlation-style explanation that belongs to context-inference explainability. The two demand different user expectations: the first promises an exact answer, the second only an evidence list.
• Attribution cannot be rebuilt after the fact. Whatever was not recorded at the instant of execution cannot be queried back by any interface — attribution capability is a function of recording, not of the query UI. Settle "whether to record" before polishing "how to query".
• Not every action deserves equal treatment. Attribution demand for frequent low-stakes actions (routine lights) is thin — record on demand; for actions touching safety, other people, or property it is a hard requirement. A uniform retention policy either wastes storage or loses the decisive evidence.

Applying it

• Persist one trigger record per executed action: rule identity, matched conditions and values, timestamp, key contextual signals of the moment. Record what the engine evaluated — nothing extra inferred.
• Put the attribution entry where the action becomes visible: one step from the notification, device page, or scene where the user notices "the light turned itself off" — not only in some global log.
• Retention must cover at least the typical discovery delay — from occurrence to the user noticing and asking is usually measured in days; a log that clears weekly is no log.
• How to check: sample the last two weeks of historical actions and measure attribution success rate and time; then track the rate of misattribution (automated action read as device failure, or the reverse) before and after the attribution surface ships — it should drop measurably.

Related

• Same group: Z5.03.2 Without logs, diagnosis is impossible · Z5.03.3 Automation history is the foundation of debugging
• Nearby: Z2.07 Making context inference explainable and visible · Z7.01 Making system behaviour explainable · Z5.02.3 Conflict outcomes must be traceable to specific rules
• Search terms: trigger attribution · audit log · smart home debugging · why explanations