Explicit actions should override automatic behaviour

What it is

When an automation and a user's explicit action collide, the explicit action wins — the override precedence rule. Automation's value covers the ordinary run of things; explicit action's value covers the exceptions; at the moment an exception arrives, the system yields — no argument, no delay.

"Override" here is about the immediate layer: this once, the user is obeyed. It does not promise to change the rule itself — manually switching a light on once does not repeal the "lights off at 23:00" schedule; whether and how overrides get learned is a separate piece of knowledge in this group. This one settles a single question: when they conflict, who wins.

Why it happens

Why should explicit actions win by default? Signal freshness. An automation's judgement rests on historical patterns and contextual proxy signals — indirect evidence filtered through delay and noise. An explicit action is a direct expression of intent: this person, this moment, this wish. Its freshness outclasses any inference. For the system to press stale evidence over new evidence is to declare that history knows the user's present wish better than the user does.

The principle has a mature formulation in mixed-initiative interface research: Horvitz's 1999 principles include that a system uncertain about the current task should signal its uncertainty and hand the decision back to the user, and that a user's explicit action should be able to terminate the system's action in progress.

The most common violation is the rebound: the override takes effect, and two seconds later the automation drags the state back (timer fires, cloud re-pushes). To the user this is not a precedence dispute — it is override failure, as if the action never happened.

Studying it

• Mixed-initiative interfaces: Horvitz's design principles are the classic reference, establishing the baseline of "explicit action interrupts; under uncertainty, escalate and hand back".
• Takeover research in automated driving: explicit actions (braking, steering) immediately disengaging the automation is settled practice; a large literature quantifies takeover time and quality, with a consensus that transfers directly to ambient automation — the explicit control channel must always be live and always outrank.
• Smart thermostat practice: manual adjustments taking effect immediately and not being overwritten by the schedule within the period is standard design for learning thermostats, and field studies record it as users' baseline expectation.

Where it stops holding

• Safety interlocks must not be overridable. Automatic gas shutoffs, child locks, curfew windows exist precisely to defeat momentary human impulse. What can be overridden is preference-class automation (lighting, temperature, reminders), not safety-class constraints; merging the two under one switch breaks something either way.
• State must realign after the override. The override produces a new current state, and the system continues from that state — it must not haul the device back to "what the automation thinks is right". Immediate rebound is this principle's most common failed implementation.
• The rule arbitrates human-versus-automatic only, not human-versus-human. In multi-user settings one person's override suppressing another person's explicit action is an interpersonal conflict with its own body of knowledge; precedence does not settle it as a side effect.

Applying it

• Write the precedence into the arbitration logic explicitly: explicit action > automation trigger source — guaranteed by rule, not by timing luck.
• Make overrides take effect immediately with visible feedback: the device responds on the spot and state updates on the spot, so no "did it register? press it twice more".
• Do not let overrides pass silently: tell the user the automation was suspended (even as an after-the-fact log entry), otherwise "the automation did it" and "my override succeeded" are indistinguishable.
• How to check: inject explicit actions concurrently with automation triggers under stress testing, enumerating the timing edges — mid-execution, completed, queued, syncing — and confirm the explicit action wins every race without rebound.

Related

• Same group: Z3.04.1 Implicit paths cannot replace explicit control · Z3.04.3 Overrides should be learned by the system
• Nearby: Z3.06.1 Users must be able to stop an automation action while it runs · Z3.06.2 After a takeover the system must not silently resume its previous behaviour
• Search terms: manual override · mixed-initiative · override precedence · takeover