Degraded behaviour must be predictable

What it is

What a device does after network or power loss must be identical every time and knowable in advance: the same outage entering a safe state today, factory defaults tomorrow, no response the day after — that destroys the user's ability to form expectations. Predictable degradation means the user can answer "what happens around here when the internet drops" before any failure: what the lights do, what the lock does, whether automations still run.

Consistency beats cleverness. A degradation that always turns the lights off is better than one that learns the user's habits once, holds state once, and flashes three times once — each of those behaviours is individually defensible; together they are untrustworthy.

Why it happens

Degraded behaviour is a design decision written into firmware, mainly of three kinds: post-outage state on power restoration (last state / default off / default on), automation survival during disconnection (locally runnable rules continue, cloud rules stop), and alerting (local sound and light / silent until recovery). Unpredictability comes not from missing decisions but from decisions scattered and drifting: different components implement their own (bulbs restore last state, plugs restore off, thermostats drop to eco), vendors quietly change behaviour in firmware updates, and some behaviours depend on outage duration or cloud state — the words "depends on" are the mechanistic root of unpredictability: the degradation path becomes a maze of conditionals instead of a fixed route.

Deterministic degradation has an engineering pedigree: safety engineering's fail-safe versus fail-secure choice — fail toward safety (an escape door unlocks on power loss) or toward security (a vault stays locked) — must be fixed per device class and documented. Smart homes inherit the same requirement: a door lock must stay mechanically openable from the inside during power loss (life safety first); a security sensor must trigger a local alarm on power loss (security first). The choices can be argued about, but once made they must be identical every time, and discoverable before purchase.

The right unit of "predictable" is the device class, not the individual device: one restoration strategy for all lighting, one alerting strategy for all security. Class-level consistency lets users predict the whole house from three rules; per-device "optimal" choices assemble into a thirty-row matrix, which equals no rule at all.

Studying it

• Transplanting engineering principles: fail-safe/fail-secure is a mature safety-engineering principle with long practice and standard texts; extending it to consumer devices' restoration behaviour is principle application, not new discovery.
• Behavioural-consistency testing: run repeated power-cut/restore cycles on devices, record each round's restored state and behaviour, and diff the rounds — both non-determinism (same conditions, different results) and inconsistency (different strategies across devices) become quantifiable. In IoT device testing, inconsistent power-restoration behaviour is a common finding.
• User expectation studies: ask users to predict "what will device X do after an outage" and compare with actual behaviour; prediction error measures the predictability gap and points directly at what needs documenting or fixing.

One methodological caution: cover a gradient of outage durations (momentary, minutes, hours) and outage moments (mid-act versus standby) — many devices' restoration behaviour depends on how long the power was out, and such hidden conditions are exactly where unpredictability hides.

Where it stops holding

• Predictability tensions with continuous improvement. Freezing degraded behaviour makes security fixes hard to change too; the resolution is separating channels — security patches flow silently, behaviour changes must be explicitly announced with migration notes.
• Do not ask users to memorise matrices. Predictability serves user memory: class-level consistency (lighting consistent, security consistent) beats per-device correctness; a household of thirty devices with thirty "reasonable" strategies behaves, in effect, randomly.
• "Telling users the degraded scope in advance" is the companion communication design, part of fault communication — behaviour consistent but uncommunicated still fails to build expectations. The two are two sides of one coin: architecture here, communication there.

Applying it

• Define a power-restoration default per device class and hold it across the category: lighting restores last state, security alarms locally on failure, climate enters a safe temperature band; no per-device freelancing within a class.
• Write the automation engine's disconnection behaviour (which rules continue, which pause) into product documentation, not just into firmware for users to discover.
• Firmware updates must not silently change degraded behaviour; behaviour changes go through explicit announcements and release notes.
• How to check: repeat the outage-recovery cycle ten times per device (across duration gradients), recording state and behaviour each round and diffing round by round — any round that deviates from the declared behaviour is one unpredictability defect.

Related

• Same group: Z4.03.1 Cloud dependency disables devices when the internet drops · Z4.03.2 Core functions should complete locally
• Nearby: Z4.09 Faults, disconnection and degradation · Z4.04.3 Firmware updates can change existing behaviour
• Search terms: fail-safe · fail-secure · power restoration behaviour · predictable degradation