Conflict outcomes must be traceable to specific rules

What it is

After arbitration runs, the user must be able to look up who contested, who won, and on what basis — a conflict-attribution record. What it records is one verdict: the competing command set, each command's originating rule, the arbitration basis, the winner, and the suppressed.

Without that record, a conflict is just "the light won't behave" — phenomenon visible, structure unknowable. Users cannot distinguish a broken device, a lagging network, or duelling rules, and default to the worst guess. Meanwhile the suppressed rule sits in silent failure: it fired, its action never executed, and its author knows nothing. The attribution record is the only channel that turns silent failure back into an observable event.

Note the scope: conflict attribution answers "who won this verdict". The general question "what triggered this action" — the non-contested kind — is trigger attribution, a separate card's territory. Conflict attribution exists only where adjudication happened.

Why it happens

The difficulty is that a verdict is a transient event that cannot be reconstructed afterwards. Adjudication depends on three things that exist only in that instant: the set of rules co-holding (their conditions and matched values), the actual arrival order of commands at the arbitration point, and the arbitrator's decision path. If any was not captured on the spot, only speculation remains — and speculation fails first exactly where users most need it: "which other rule also held at that moment".

This also explains why an ordinary action log does not suffice. A normal log records what executed; conflict attribution additionally needs what did not execute — the suppressed commands, the discarded candidates. Negative facts leave no trace on their own; the system must explicitly record the loser, an engineering investment that feels backwards: spending storage on things that did not happen.

A third layer: suppression needs running accounts, not single entries. Being overridden once is normal (arbitration working as declared); being overridden by the same rule all week signals a wrong precedence or overlapping conditions — the pattern diagnoses more than the instance.

Studying it

Research directly on domestic conflict attribution is scarce; usable bases:

• The audit-log and observability tradition: operations practice is unambiguous that decision events must record their inputs; distributed-tracing spans ("who called whom, what got cancelled") are a structured precedent for the record shape.
• User studies of misfired-assistant attribution (stated generically): analyses of "why wasn't my command executed" support tickets in voice-assistant products give first-hand shape to attribution needs.
• Attribution-usability experiments: stage a known conflict and give users different record granularities (winner only / winner + candidates / winner + candidates + basis), measuring time and error rate to identify "which rule was suppressed". The granularity-benefit curve directly informs design.

One methodological caution: define "attribution success" at the rule-pair level, not the device level — learning "the light misbehaves because two rules fight" is halfway; learning which two completes the task.

Where it stops holding

• Only explicit conflicts need conflict attribution. Same-moment verdicts cost recording only when they occur; staggered tug-of-wars (devices toggling) have no single verdict moment — their attribution runs on trigger-timeline comparison, the territory of automation history.
• Records carry a privacy cost. A conflict record embeds the time structure of household life (who was home, when things happened); storage and retention must treat it as household data — noted here, expanded under privacy in shared spaces.
• Attribution does not repair conflicts. It makes them visible so users can change rules or precedence; actual elimination relies on pre-checks and arbitration design. Treating logs as the fix just accumulates an unread history of conflicts.

Applying it

• Record conflict events as their own class, with fields at minimum: candidate command set, each command's rule of origin, arbitration basis, verdict, timestamp. Keep them separate from ordinary action logs, with a dedicated filter view.
• Surface suppression on the suppressed rule's own page: "last firing was overridden by 'lights on at sunset'" — silent failure shown where the rule's author will look, not buried in a global log.
• Decouple retention from ordinary logs: conflicts are rare and information-dense; they can outlive state logs by a wide margin.
• How to check: stage a two-rule conflict and count the steps and time from "noticing the symptom" to "identifying the two rules and the winner"; three steps qualifies, needing to dig through the global log does not.

Related

• Same group: Z5.02.1 Multiple rules can issue contradictory commands to the same device · Z5.02.2 Priority and arbitration must be explicit
• Nearby: Z5.03 Causal traceability · Z5.01.3 Rules must be viewable, pausable, and deletable · Z7.01 Making system behaviour explainable
• Search terms: conflict attribution · audit log · observability · smart home debugging