Behaviour becomes unpredictable as rule count grows

What it is

Each rule is individually understandable, yet the behaviour of the rule set as a whole exceeds the description of any single rule — the emergent complexity of rule interactions. In a home with ten rules and twenty devices, "when will this light turn off" is no longer answerable by any one rule: it depends on which rules target that light, when their trigger conditions co-hold, and whether one rule's action changes another's trigger.

What unpredictability looks like in practice: a device does something no rule ever said (a chain of rules relaying behaviour); behaviour in a period diverges from the past (a forgotten rule waking only under a particular condition combination); changing one rule alters behaviour somewhere far away (rules coupled through a shared device).

Why it happens

Complexity grows multiplicatively. Each new rule is not a +1: it creates new combinations with every existing rule and device state. Rule A's action lowers the thermostat; the cooler room satisfies rule B's "low-temperature alert" condition; B's notification prompts a manual intervention. Interaction paths grow super-linearly with rule count, while rules are authored one at a time.

Two human limits stack on the structure. First, the local-author perspective: creation and editing interfaces present rules one by one; at no moment is the joint behaviour of all rules shown to anyone. The whole has no author — it exists only at run time. Second, working-memory capacity: even a user inclined to simulate the rule set mentally cannot hold the trigger combinations of a dozen rules at once; and during normal operation the automation has receded from attention, so no monitoring happens either.

Unpredictability is thus not a malfunction but a semantic split: every rule is coherent at the rule layer, while behaviour is the joint output of all rules plus the environment — with no automatic translation between the layers.

Studying it

• Scale analyses of rule corpora: Ur et al.'s 2014 survey of IFTTT rule sets gives the baseline — real sets are small and simple, a spontaneous population-level avoidance of complexity. Combined with measures of device sharing, one can estimate interaction-path growth curves.
• Conflict and interaction detection: work in the smart-home literature applies formal methods (static analysis, model checking) to rule sets to surface conflicting or cascading rule pairs — evidence that interaction complexity is real, plus a sense of detection tools' feasible ceiling. Best stated cautiously: the methods exist; evidence of their effect at household-scale rule sets is limited.
• Prediction-task experiments: show participants a rule set and a situation, ask them to predict system behaviour, and plot prediction accuracy against rule count and device sharing. This is the direct paradigm for turning "unpredictable" into a measurable quantity.

One methodological caution: separate prediction failures into "could not express" (the user does not know a rule exists) from "could not compute" (knows the rules but cannot reason through the combination) — the first is a visibility problem, the second genuine cognitive complexity, and the remedies differ.

Where it stops holding

• Small rule sets stay predictable. Under about ten rules, each targeting distinct devices, behaviour remains within a mental model's reach; this knowledge sharpens from double-digit counts and multiple rules sharing devices.
• Degradation is not linear; coupling density decides. The operative quantity is not rule count but how many devices are targeted by multiple rules — rule pairs sharing a device are the carrier of complexity. Twenty mutually indifferent rules remain perfectly legible.
• Packaging relieves but does not remove. Collating rules into scenes (explicit modes) reduces author-level fragmentation, but scenes can interact with scenes just as rules did — the problem moves up one level.

Applying it

• Run an impact pre-check at rule creation: list which existing rules target the same devices and which trigger conditions overlap, and show "these rules will interact with the new one" before saving.
• Give an aggregate view by device: organise rule lists by target device rather than creation date, so "three rules on three lights" versus "three rules on one light" is visible at a glance.
• Set scale reminders: prompt a review when a single device carries more than three rules; annotate cascade depth (a rule's action feeding another rule's condition) in logs.
• How to check: sample users' predictions of their own rule sets — give a routine situation (coming home from work), ask for the predicted final state of lights and heating, and compare with actual execution. Wherever prediction errors cluster is where documentation and views need work.

Related

• Same group: Z5.01.1 Condition-triggered actions are the basic model · Z5.01.3 Rules must be viewable, pausable, and deletable
• Nearby: Z5.02 Rule conflicts · Z5.03 Causal traceability · Z5.05 Scenes and modes
• Search terms: rule interaction · emergent behaviour · end-user programming complexity · smart home rule conflicts