After a takeover the system must not silently resume its previous behaviour

What it is

After a user halts or takes over, the system must not resume the suspended behaviour on its own — behavioural rebound (auto-resumption). The moment a user stops something, they have made a decision: "not now". For the system to re-execute that decision without telling anyone is to declare the user's takeover a mere interruption.

Rebound is the single most trust-destroying event in the takeover experience, because it lands at the moment the user has already confirmed their victory: the device stopped, the interface says stopped, the user has turned away — and the light comes back on, the heating kicks back in. The question escalates from "how do I stop this" to "who actually decides here", and the apparent answer is "not me".

Why it happens

Rebound is rarely malice; it is the common product of three engineering oversights:

• Timer-driven restart: the halt cancelled only this execution, while the next scheduled tick arrives as planned — "pause" implemented as "delay".
• State-machine reset: takeover runs through the exception-handling path; once the exception is handled, control returns to the main loop, which never learned a takeover happened.
• Cloud re-push: the local takeover changed local state, the cloud still holds the old state, and the next sync pushes the old behaviour back — a leading source of "the light turned itself back on" reports.

The second offence is silence: even where resumption has a defensible reason (safety monitoring must return to duty), the user cannot distinguish "it broke again" from "it did this on purpose". The attribution gap damages as much as the rebound itself — and users assume the worse reading.

Behavioural consequence: users learn that takeover is not final, so they either give up taking over (tolerate wrong behaviour) or escalate to physical means (unplug, unsubscribe, cover the sensor) — either way, the software control channel has been judged ineffective.

Studying it

• Re-engagement research in aviation and automated driving: pilots' surprise at automatic re-engagement is classic material in the automation-surprises literature; when and how the system re-engages after a takeover is an established design variable in its own right, not a footnote to takeover.
• Smart-home state-synchronisation failures: "the device moved again by itself" reports from local-versus-cloud state divergence recur across support channels and field studies (a common domain finding, described generically).
• Method: rebound detection — extract the event rate of "system restarts the same action within T minutes of a user halt" from logs, classified by cause (timer / state machine / sync); expectation surveys — what should the system do after a takeover, via questionnaires and interviews.

Where it stops holding

• Some resumption is legitimate: safety monitoring (smoke-alarm silence re-arming), or clearly declared cycles ("resumes automatically after two hours" with the user informed). Legitimacy has two tests: the resumption semantics match what the user agreed to, and the resumption is visible when it happens. Miss either and it is still rebound.
• Users usually want the middle ground: "not today" is neither "off forever" nor "just this once" — resumption policy needs that granularity (pause until tomorrow, suppress within this scene); offered only all-or-nothing, users are forced into the heavier option.
• Separate designed resumption from sync defects: one is policy (deliberate resumption logic), the other a bug (synchronisation race). To the user they are the same injury; the fixes are entirely different — classify the logged events into the two before touching anything.

Applying it

• Make takeover semantics explicit: at the halt, state its scope — "stop this once", "pause until morning", "disable this automation" — three options offered, none guessed.
• Any automatic resumption must be agreed in advance and announced when it happens — both conditions, together.
• Audit the state machine: the takeover path must genuinely change the machine's state, not loop back to the original; make the user's most recent explicit operation the authoritative source in cloud–local sync.
• How to check: after takeovers, observe across sync cycles, cloud reconnections, and timer expiries (minutes to hours); the event rate of the system restarting the same action must be zero — except resumptions the user explicitly agreed to.

Related

• Same group: Z3.06.1 Users must be able to stop an automation action while it runs · Z3.06.3 The edit entry point belongs where the outcome appears · Z3.06.4 Takeovers should be recorded to improve future judgements
• Nearby: Z3.04.2 Explicit actions should override automatic behaviour · Z4.02 State de-synchronisation
• Search terms: auto-resumption · behavioural rebound · state synchronisation · takeover