Old rules gradually drift from reality
Aliases: rule decay · configuration rot
What it is
An automation rule fits life when written, then gradually drifts from reality — not breaking suddenly, but slowly ceasing to make sense: the condition still holds but the scenario is meaningless (a light kept for a roommate who moved out long ago), the action still runs but the need is gone (a cooling scene still chilling in winter), new rules piled atop old ones that were never cleaned up. The process is rule drift: the rule's text is unchanged; its correspondence with life has rotted.
Drift's nastiest property is that it is symptomless: rules still trigger, still execute, raise no errors — from the system's viewpoint, everything is healthy. Symptoms exist only as scattered moments of "that result makes no sense", and users usually digest them as one-off annoyances rather than recognising "a rule is due for retirement".
Why it happens
Three independent generative paths, usually running together:
Premise evaporation. The life premises a rule encodes (who is home, what schedules, what each room is for) are rewritten by life events — the source described in the previous entry. Premise gone, the rule's literal logic idles in place.
Accumulation without cleanup. When a new need appears, the user's natural move is to add a rule rather than edit the old one: a "high temperature → aircon" rule for summer; come winter, not wanting it, a "low temperature → off" rule gets added — two rules doing one job, and three quarters later nobody can say what the pair jointly does. Rule count grows monotonically while behaviour is decided by the union of all historical rules, yet the user's mental model holds only the recent additions — the model-reality gap widens linearly with time.
Semantic drift without notification. A device moved, a room repurposed, a family member's label changed — the entity the rule references still exists ("bedroom motion sensor" as an ID still resolves), but what it points to in the world has changed content. Every referential-integrity check passes; the semantic mapping snapped long ago.
The paths share one property: none of them ever raises an error. Drift therefore only accumulates, never clears — unless someone reviews. That is what distinguishes it from faults: faults have symptoms; drift has only inertia.
Studying it
- Configuration archaeology: with consent, export long-term households' rule bases, reconstruct each rule's creation time and firing history, and measure the share of "zombie rules" (long-dormant, or fired but always manually reverted) and its growth with years of use — direct quantification of configuration rot.
- Revert-behaviour analysis: code "manual inverse operation within X minutes of an automated action" as a de facto veto. Revert rate is a sensitive indicator of rule quality: users may not be able to say which rule misbehaves, but their hands do not lie.
- Longitudinal paired interviews: have the same household explain, in two interviews months apart, why a given rule exists; the share that cannot be answered, or answered differently the second time, measures the forgetting rate of rule semantics on the user side.
One methodological caution: zero firings do not imply drift — safety-linked rules (gas-alarm interlocks) are supposed to be dormant. Classifying "zombie" must combine rule type with revert records; culling purely by firing frequency would mis-kill protective rules.
Where it stops holding
- Drift is not confined to homes. Office desk presence sensing and public-space schedules drift too; in public settings rules have a responsible party, and drift presents as "a ticket was filed but nobody thinks it's theirs".
- Some drift is deliberate. Users keep a defunct rule as a template or keepsake (a retired seasonal scene saved for next year); it occupies a clear slot in the user's mental model and is not rot. The criterion is whether the user can explain why it is still there — not whether it fires.
- More rules does not mean more drift. Households with good naming and grouping habits keep dozens of rules comprehensible; the driver of drift is inexplicable accumulation, not count per se.
Applying it
- Show last-fired and last-reverted times on rules by default — turning "this rule has been idle / keeps getting reverted" from an archaeological dig into a glance.
- Trigger rule clean-ups by events, not calendars: on repeated reverts, season switches, or device moves, batch the related rules into one review group (keep / disable / delete), rather than waiting for the user to remember.
- On rule creation, run a similarity check: "you have a similar rule (…) — edit it or create new?" — diverting traffic at the source of the accumulation path and slowing the monotone growth.
- How to check: pull zombie-rule share and revert rate quarterly; after shipping the clean-up mechanism, watch whether share falls and what fraction of cleaned rules the user "could no longer explain" — that fraction is rot's true inventory.