I3.04.1conflict surfacingdesign

Conflicts must surface; the system must not silently pick a winner

Aliases: hidden conflict · auto-pick · expose the fork

What it is

The same data has been changed on two sides into shapes that cannot coexist. The system has to name that a conflict and put it in front of a person, rather than quietly keep one copy. Conflict surfacing lifts the disagreement out of the sync pipe and makes it an interface event. Auto-picking (by timestamp, by device, by “looks newer”) is not resolution; it takes the choice off the authors and pretends no choice occurred.

This leaf does not care how fine the merge grain is, and does not require that both originals sit side by side at resolve time. It only tests: at the moment of conflict, does a person know a conflict happened.

Why it happens

Sync’s default story is “it will become one copy”. People leave on that story: retitle on the phone, rewrite the body on the laptop, expecting a single piece. When both sides changed the same meaning, the story breaks. If the break is not named, the interface still presents one complete document, and the model keeps treating it as “the copy both sides accepted”. The author of the discarded side returns, finds their sentence gone, and blames themselves for not saving — not an unshown verdict.

Auto-pick is tempting because it lets the pipe keep “there is always one value”. The pipe is happy; the author’s causation is cut: words they wrote vanished with no failure event. Surfacing a conflict is a deliberate stall of the pipe in that cell, replacing the false single value with a pending state. Pending is uncomfortable. It is also true.

Where it stops holding

Truly orthogonal edits (one person the title, the other the cover image) can merge automatically without shouting conflict — that is keeping both, not picking one. A machine-certain replay of the same character-level patch (the same op hitting twice from an offline queue) should dedupe, not conflict. A security policy may block before surfacing (a stolen session’s write), but the block still leaves a trace that a write was not accepted; it must not drop in silence. Forks in a read-only replica, a backup replay, an audit log face operators, not the document’s authors; the channel need not be a banner in the editor. Character-level collisions under live shared cursors that popped a dialog every second would be dismissed; those collisions want a finer merge, not auto-pick pretending there was no collision.

Applying it

  • When two writes cannot coexist, enter an explicit conflict state: documents, records, messages must look pending, not like one clean version.
  • Do not drop the other side on a timestamp or “this device wins” with no notice.
  • A conflict state must interrupt the next publish or submit that depends on this data, until a person has seen the fork.
  • How to check: change the same sentence on two devices, then sync. If the result is one sentence plus one vanished, and no UI that a conflict occurred, it fails. Bring the author of the vanished sentence to the screen and ask “where did your line go” — if they can only guess “probably didn’t save”, that was auto-pick.

Related

  • Same group: I3.04.2 Resolving a conflict must keep both versions available · I3.04.3 Last-write-wins silently discards the other edit
  • Nearby: I3.11 Sync conflict merge · I3.10 Offline and local-first
  • Search terms: conflict surfacing · sync conflict · automatic resolution

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I3.04.1