Priority and arbitration must be explicit

What it is

When rules conflict, the system must have a mechanism deciding who wins — arbitration. The point is not whether one exists: every implementation decides somehow, and "last command overwrites earlier ones" (last-write-wins) is arbitration too, just one nobody knows about. The point is whether arbitration is explicit: the precedence declared, known to users, and enforced consistently.

Implicit arbitration's cost is structural problems masquerading as random faults: the same conflict resolved for rule A today and rule B tomorrow (depending on millisecond-level arrival order) leaves the user facing a device that "works sometimes" — unpredictable and unaccountable.

Why it happens

Without an arbitration policy, outcomes are decided by race timing: two rules holding at the same moment each dispatch a command, and the winner depends on network latency, evaluation-cycle phase, and cloud queue order — every resolution legal, every one potentially different. Racing hands the decision from design to physics, and physics has no semantics.

Explicit arbitration needs three layers:

• An ordering basis: a comparable priority scheme. The robust ones are type orders (manual command > explicit scene > automatic rule > routine schedule) and source orders (safety > comfort > energy). Type orders beat numeric priorities — users understand "manual overrides automatic", not "this rule is a 7 and that one a 5".
• An arbitration point: the single place where converging commands are adjudicated — at the device or hub — and it must sit causally before execution.
• Statable verdicts: the basis of each decision translatable into one sentence ("manual input outranks automation"). This is what separates arbitration from racing: a race's outcome cannot be stated, only accepted.

Why explicitness matters this much: the arbitration rule itself becomes part of the user's mental model. Knowing "manual always overrides automation", a user can build strategies on top (a manual tap before leaving suppresses the automatic sprinkler for an hour). With unknowable arbitration, no such second-order strategy can form.

Studying it

• Systematic work on arbitration policies: the smart-home and multi-agent literature has mature discussion of conflict-resolution strategies — priorities, temporal ordering, source weighting, and user adjudication, with their applicability conditions. Best stated cautiously: direct comparative evidence in domestic settings is limited.
• Concurrency-control tradition: last-write-wins and timestamp ordering come with mature analysis from distributed systems and serve as mechanism background — their failure modes there (lost updates, write skew) have direct domestic counterparts.
• Predictability experiments: give users a conflicting rule set and compare behaviour-prediction accuracy and trust scales between an explicitly declared precedence and implicit last-write-wins. The benefit of explicitness is directly measurable.

One methodological caution: experiments must include exception scenarios — moments when the user wants to break the default precedence — otherwise they measure only predictability, not negotiability, and negotiation is the domestic norm.

Where it stops holding

• A priority scheme carries its own complexity cost. Beyond three or four tiers, or requiring users to assign numeric priorities per rule, users stop understanding and fall back to trial and error — explicitness dies of its own complexity. Keep the default order small and stable; allow exceptions on demand.
• Some conflicts should be refused, not arbitrated. Two safety rules in opposition ("unlock doors on power failure" and "close doors on fire alarm" co-holding) must not be resolved by silently picking a winner — the correct action is an explicit error and a request for human adjudication. Arbitration suits comfort and convenience commands, not safety interlocks.
• Arbitration resolves command conflicts, not demand conflicts. "You turned the heating up and I'm too hot" is a question of control between people; the most elegant rule verdict does not decide whose preference counts — that belongs to negotiating control in shared spaces.

Applying it

• Declare and publish a default precedence, starting from "manual > explicit scene > automatic rule > routine schedule"; keep it to three or four tiers, phrase it in plain language, and cite it inside conflict warnings.
• Show the basis of each verdict where the conflict surfaces: "manual input took precedence over 'lights on at sunset'" — every arbitration is a free lesson.
• Allow per-rule exception overrides: a single rule may declare "outranks scenes", with exceptions listed explicitly; do not ship a global numeric-priority editor.
• Route safety-rule conflicts to refuse-and-error, never to silent arbitration.
• How to check: for injected simultaneous conflicts, verify each outcome against the declared order; then test users' restatement accuracy of the precedence — failure to restate means the wording is not plain enough yet.

Related

• Same group: Z5.02.1 Multiple rules can issue contradictory commands to the same device · Z5.02.3 Conflict outcomes must be traceable to specific rules
• Nearby: Z3.04 Implicit and explicit interaction coexisting · Z6.01 Control conflicts between people · Z5.01.2 Behaviour becomes unpredictable as rule count grows
• Search terms: arbitration · conflict resolution · priority · last-write-wins