Stale-context automation makes outdated decisions

What it is

Automations take context judgements as input; once the judgement expires, the automation becomes an agent executing stale instructions: the person has left, but the system still runs the full "home mode" — lights on, doors unlocked, quiet hours active. The error is not in the automation logic (the rule is fine) nor in execution (the actions ran precisely) but in the input — it corresponds to past reality.

The insidious part: every component looks healthy in isolation — the sensor isn't broken (they were home then), the rule isn't wrong (home should behave this way), execution didn't fail (every action ran). Chained together, they serve an empty room. The "dumb behaviour" users see decomposes into entirely innocent parts.

Why it happens

The amplification of stale decisions comes from three properties of automation:

• Automation executes continuously. Manual operations happen only while someone is present — no person, no mispress. Automation has no such natural gate: through the hours a judgement is expired, it diligently executes actions under an obsolete premise, and the error integrates over time.
• The weight of context input is non-negotiable. Once a rule conditions on "home", that condition governs an entire bundle (not one lamp but lighting, locks, speakers, alerts); a single stale point is fanned out through the interlocking structure into a string of stale consequences — context is consumed as a package, and so is its expiry.
• The error settles in the physical world. A UI bug refreshes away; a stale decision settles on the doorstep (the door unlocked all night), the meter (air conditioning running eight hours for an empty house), safety (the arming that never engaged). Irreversibility of settlement raises the real price of an identical logic error.

There is also a directional regularity: stale decisions are almost always forgiven when conservative, punished when the opposite — treating the present as absent (false arming, lights off) merely annoys; treating the absent as present (unlocked door, no arming) is a security incident. Which side an expired judgement defaults to determines the cost structure of its errors.

Where it stops holding

• Not every stale decision is visible. Indifferent actions like lighting an empty room may never surface to the user — the cost is energy, off the books. When sizing stale decisions, energy data and user reports are independent sources, the latter severely under-counting the former.
• Low-consequence automations tolerate staleness. A humidifier riding "home" ten minutes stale just runs ten extra minutes — imposing strict freshness gates on every automation punishes everyday convenience with safety-critical standards. Freshness requirements tier by consequence.
• "Behaviour correct" is not "premise correct". Acceptance tests usually verify "did the right actions fire", never "was the premise still fresh when it fired" — a fully green test suite can sit atop automations running on expired premises indefinitely. That blind spot is for test design to close deliberately.

Applying it

• Have high-consequence automations declare their freshness premise explicitly: the trigger is not "home" but "home (judgement age ≤ ceiling)"; beyond the ceiling, route to the no-fire branch instead of pressing on.
• Log and aggregate stale-decision events: every "executed with over-age judgement" (the judgement, its age, the actions taken) recorded; stale-execution rates grouped per automation rank the rules whose freshness chains need repair first.
• Give expired premises a conservative default: the state an automation falls back to when its judgement expires should be chosen by error-cost asymmetry — better to run "away mode" with someone home (lights off, they turn them on) than "home mode" with everyone gone (door unlocked).
• How to check: run two audits together — on the log side, stale-execution rate and longest staleness; in drills, manufacture "expired judgement + high-consequence automation pending" scenarios and verify the system refuses to fire and lands in the conservative default. Both passing cages the stale decision.

Related

• Same group: Z2.09.1 Context judgements expire and must stop being trusted past their validity · Z2.09.2 When the environment changes fast, context spoils faster than judgements refresh · Z2.09.4 Systems must actively mark context expired rather than carrying it forever
• Nearby: Z3.02 Boundaries of automatic execution · Z4.09 Faults, dropouts, and degradation
• Search terms: stale context · automation failure · fail-safe defaults · condition freshness