Automation history is the foundation of debugging

What it is

Single-event attribution answers "why this time", but debugging genuinely rests on accumulated history: how often this rule fired over the past thirty days, in which time bands, how many times it was suppressed, how behaviour shifted after the last parameter change — these cross-time patterns are the evidence for editing rules, tuning parameters, and judging "is this rule even useful".

The distinction between log and history is granularity and purpose: a log is a flow (one entry per event, serving replay and forensics); history is a ledger (aggregated by rule and by device, serving evaluation and adjustment). Without the ledger, a user's knowledge of each rule stops at "why I created it" — never reaching how it actually runs. The gap between intention and actual behaviour is the most pervasive and least visible problem in intelligent environments.

Why it happens

History supports debugging in four ways, each deeper than the last:

Pattern discovery. A single event shows nothing; thirty days of firing records show plenty: "fails every day after 23:00" points at signal coverage; "suppressed every Wednesday" points at a clash with a calendar rule. Patterns are a diagnostic dimension single-event attribution cannot supply.

Counterfactual baselines. Did the behaviour improve after the edit? Without history there is no control — after changing a parameter the user judges by vibe ("seems better?"), and vibe is nearly worthless for low-frequency rules (firing twice a week). History turns adjust-and-verify from divination into measurement.

Exposing idle and overloaded rules. A rule that never fired in three months (condition never satisfiable) and one firing forty times a day (condition too broad) both need attention, but only history can fish them out of hundreds of rules. Rule-base health is a uniquely historical viewpoint.

Parameter tuning. What threshold for the sensor? From what hour does "evening" start? Reasonable values come from actual data distributions — and distributions are only visible in history.

Why history doesn't exist by default: aggregation requires deliberate design — anyone can drop flow logs, but views aggregated per rule, per device, with time-window comparison are product features that appear only under explicit demand. Engineering inertia produces logs, not ledgers.

Studying it

• Longitudinal in-situ deployments (stated generically): studies of real domestic automation consistently report the create-and-abandon norm — rules built then forgotten, rarely reviewed or adjusted; the absence of history views is regularly listed among the causes. The most direct evidence base for the history need.
• Counterfactual evaluation: A/B-style rule-adjustment assessment (trigger and outcome statistics for N days before vs after a change) can borrow baseline-comparison design from software experimentation; the domestic difficulty is low event frequency and long cycles, so observation windows must be sized per rule by firing rate.
• Temporal visualisation research: human-factors work on timelines and heatmaps for cross-day pattern discovery is well established and serves as reference for history-view design.

One methodological caution: evaluate history views on debugging tasks as the dependent variable (find the useless rule / spot the conflict pattern / judge whether an adjustment worked), not on "users like looking at it" — preference and diagnostic efficacy diverge, and the former overrates dashboards.

Where it stops holding

• History is a basis for adjusting rules, not permission to adjust them automatically. A system may suggest changes from history ("this rule hasn't fired in three months — delete?"), but adoption must be the user's decision — auto-editing rules destroys the predictability that rule systems exist to provide. That is the slide from rule-based toward inference-based automation, two regimes with entirely different intelligibility promises.
• History pays off less for low-frequency rules. A rule firing twice a week needs months to accumulate a readable pattern; for such rules single-event attribution ("why this time") beats pattern history ("how it runs in general"). History views should stratify by firing frequency rather than showing everyone the same thirty days.
• History concentrates privacy. Aggregated views are more readable than flow logs — which means exporting one hands over a structured summary of household life. Aggregated exports and sharing must be treated at the highest sensitivity tier.

Applying it

• Offer by-rule and by-device entries: a rule's page shows its own firing history (frequency, time-band distribution, suppression counts, before/after comparison since the last edit); a device's page shows the unified timeline of all rules acting on it.
• Enter a comparison window automatically after each rule edit: mark the change moment and display the following N days beside the preceding ones — the edit's effect at a glance.
• Build in health screening: proactively flag never-fired, high-frequency, and frequently-suppressed rules as a standing entry for rule-base maintenance.
• How to check: hand users a rule base seeded with known problems (idle rules, conflict suppression, over-broad parameters) and compare time-to-find and miss rates with and without history views; then test the comparison window alone — after one parameter change, can users correctly judge "better / worse / unchanged" from the before/after display?

Related

• Same group: Z5.03.1 Users must be able to find out what triggered an action · Z5.03.2 Without logs, diagnosis is impossible
• Nearby: Z5.01.2 Behaviour becomes unpredictable as rule count grows · Z5.01.3 Rules must be viewable, pausable, and deletable · Z7.02 From usability problems to collapse of trust
• Search terms: automation history · rule maintenance · counterfactual evaluation · smart home analytics