Rehearsals must cover boundary conditions, not just the happy path

What it is

A rehearsal that runs once in the "standard scene" — afternoon, someone home, all devices online — validates the happy path: the rule's smoothest execution line. But rules almost never fail on the happy path; they fail at boundary conditions: a jitter of one or two crossings around the threshold, two rules firing simultaneously, a device going offline at execution time, the day-rollover and do-not-disturb edges, guests in the house. A rehearsal's value is capped by the boundaries it covers, not by whether the happy path runs green.

This is software testing's oldest finding restaged for home automation: the cases users think of are rarely the cases that break; errors live in combinations and corners. The difference is that software has professional testers to think of boundaries for the developer, while in home automation the "developer" is the user — nobody thinks for them, so the product must automate the enumeration.

Why it happens

Why do boundaries, not the happy path, carry the failures? Because the happy path is the picture in the user's head when creating the rule — "I arrive, it's dark, light on" — the rule is written to that picture and mentally simulated against that same picture; the two share a source, so a passing mental simulation provides no new information. Boundary conditions are by nature the pictures the user does not have: input and state combinations unimagined at writing time.

The high-frequency boundaries, each with its own failure mechanism:

• Threshold boundaries — signal chatter around the decision value decides fire or not; the happy path never approaches the threshold, so never tests it.
• Concurrency boundaries — two rules commanding the same device in the same instant; each correct alone, mutually overwriting together. On the happy path rules stay staggered; collisions happen only at coincident firings.
• Availability boundaries — the target device offline, the engine cut off, the cloud timing out at execution; a rehearsal assuming everything online assumes a world that does not exist.
• Time boundaries — day rollover, daylight-saving switches, do-not-disturb start and end, timezone offsets; missing these points by a second lands in another day, and the happy path spends all day far from them.
• Social boundaries — guests present, a child's schedule changed, a family member's manual intervention; the sensing assumption ("this household is just the two of us") fails the moment a guest arrives.

The shared structure: low frequency × unbounded consequence. Any single boundary is too rare to warrant daily vigilance, yet its consequence is unconstrained by happy-path experience — the root of automation's "reliable until it suddenly isn't".

Where it stops holding

• Boundary coverage cannot be exhaustive. The combination space is the product of device count and condition count; enumerating everything is a state explosion. The right target is the consequence-ranked head: all known boundaries of irreversible actions first, then downward.
• Product-side enumeration cannot replace user-side scenarios. The platform knows generic boundaries (rollover, offline), not this home's (long-stay guests, night shifts); automatic enumeration plus user-supplied cases ("run it again on weekend schedules") is the complete coverage.
• Some boundaries appear only over long spans. Seasonal light shifts, holiday schedule drift — no single rehearsal's time window holds them; those belong to long-term observation modes, not rehearsals. Asking rehearsal to catch seasonality gives it a task it cannot do.
• Interpreting boundary results has a threshold of its own. "When the blind is offline: skip, or queue?" — the user needs to know what queuing means; showing behaviour without explaining consequence degrades boundary rehearsal into a fresh source of confusion.

Applying it

• Build a boundary scenario checklist into rehearsal, auto-executed in consequence order: jitter once on each side of the threshold, simultaneous firing with co-located rules, target device offline, landing inside do-not-disturb — reporting "what would happen" per item, not merely pass/fail.
• Fold conflict detection into rehearsal: on save, scan existing rules sharing devices or conditions and list "who wins on simultaneous fire" directly in the results — the concurrency boundary enumerated by the system, not imagined by the user.
• Make the offline report distinguish disposal policies, prominently: "when the blind is offline: skip and continue the rest / hold the whole rule for retry / abort" — three policies, three very different outcomes; the default must be visible.
• Provide a user-authored scenario entry: "run it again on weekend schedules", "suppose we have guests" — handing the boundaries product enumeration cannot reach to the person who knows them.
• How to check: compare the rehearsal's boundary checklist against real incident logs — are the failure types seen live all ones rehearsal once covered? Uncovered types are the checklist's next line. Another reading: the post-rehearsal rule-edit rate bucketed by boundary type — low-edit types are either well covered or ineffectively displayed; home interviews tell which.

Related

• Same group: Z5.07.1 Rules need a rehearsal before going live, without touching real devices · Z5.07.2 Rehearsals must show the specific actions that would fire · Z5.07.3 Without a test environment, side effects surface only in live runs
• Nearby: Z5.02 Rule conflicts · Z5.06 Time windows and debouncing
• Search terms: edge case · boundary condition · rule conflicts · failure modes