After recovery, state must be confirmed, not assumed restored

What it is

Once a fault clears — the device reconnects, the network returns, the cloud comes back — the system must not default to "everything is as it was before the fault". It must surface the actual state for the user to verify, because what recovered was the connection, not state consistency: the physical world did not pause during the fault, and the world after recovery is a different world.

A frequently overlooked hardware fact: many smart devices do not remember their pre-outage state after losing power, and reboot into a factory-default level (usually "off"). This behaviour is the power-on state, and it means that after power returns, the device's state is decided by firmware design, not by what it was before the outage.

Why it happens

Three sources of mismatch make "assumed restored" a lie:

• Physical changes went unperceived. During the fault someone flipped the wall switch, pressed the device body, mechanically moved the door — none of it reached the system's records, so after reconnecting it treats a stale ledger as reality.
• Missed events cannot be replayed. Notifications, automations, and recordings that should have fired during degradation never did, and they will not replay after recovery; the interface shows no trace of "missed", so the user assumes a seamless rejoin.
• Partial recovery. Of ten offline devices, eight come back; the remaining two may never return. A blanket "all restored" message hides that set difference.

Stack the three and the result is: the user believes the system is back at the checkpoint, while actually facing a new, unknown, unverified state. When safety-relevant devices are involved — a lock displaying "locked" while its mechanical state was changed — the problem upgrades from annoyance to risk.

Where it stops holding

• Not every recovery needs a human confirmation step. Low-consequence, directly observable devices (a lamp) can resume silently. Three categories need verification: safety-relevant (locks, arming states), devices physically alterable during the fault, and devices that do not remember their state across power loss.
• Confirmation must not become harassment. A dialog after every router reboot trains users to click through it without reading; frequency control and safety tiering are two faces of one design.
• Non-memory power-on behaviour is a procurement problem, not an interaction problem. Swapping in a device with state memory (or configurable power-on behaviour) beats any interface confirmation; interaction remedies come after selection.

Applying it

• Add a state reconciliation step to the recovery flow: list what changed during the fault — which automations missed their triggers, which devices reverted to defaults, which devices never came back — for the user to see item by item, not to click through item by item.
• Safety devices re-state their current mode explicitly after recovery: "Front door: locked" is said out loud once, based on the device's freshly measured report, not on cache — and not left for the user to go looking for.
• At procurement and configuration time, record each device's power-on behaviour (memory / fixed level / configurable), and keep "defaults to off" devices out of safety chains.
• How to check: stage a compound drill — cut a device's power, physically alter its state during the outage, restore power — then compare every system-displayed state against physical reality; every "displays recovered, actually not" is a defect. Then measure the time from recovery until the user notices the first mismatch: that latency is the price of a missing reconciliation step.

Related

• Same group: Z4.09.1 A disconnected device must be flagged, not silently left showing its last state · Z4.09.2 Faults must be attributed across device, network, and cloud · Z4.09.3 The scope of degraded-mode capabilities must be communicated in advance
• Nearby: Z4.02 State desynchronisation · Z4.10.1 Voice, app, and physical control of one device need real-time state sync
• Search terms: state reconciliation · power-on state · resynchronisation · missed events