A merge UI must show where each difference came from, not only the result

What it is

A merge UI that only throws a “suggested result” cannot be judged. Provenance of the difference has to be visible: which stretch came from which side, when, under which device or identity it was written. The result may be present, even prefilled; it cannot be the only visible object. A result without provenance is an anonymous collage. Accepting it is signing without contrast.

This leaf is a display duty. Whether fields can auto-merge, whether text should, decides which cells enter this UI; once they enter, provenance has to be told.

Why it happens

People resolve by attribution: “this sentence I wrote on the plane last week, that one a colleague changed today”. Attribution wants a triple: who, when, which side’s original. Give only the result and working memory has no contrast object; the decision degrades to “it reads smoothly, accept” — smoothness becomes the only criterion, and a fluent false synthesis looks most acceptable. Provenance externalises contrast: side by side or stacked, plus identity and time, comparison moves from recollection to perception.

Provenance also audits. Afterward, “why is the final this shape” must answer to a version on a side, not “whatever the algorithm emitted then”. If the UI treats the intermediate product as the only document, the audit chain as people see it breaks here. Even if an underlying log remains, no door to it is no provenance.

Where it stops holding

Fields that auto-merged, both patches entered the result, and carry no semantic risk may keep provenance only in history, not side-by-side on every open — but history must be reachable. Anonymous collaboration, a pseudonym, or privacy that hides identity may degrade “who” to “left / this device / the other machine”; time should still be there. Showing provenance itself can leak the other side’s labour during offline; sometimes that is a feature (see that a colleague wrote), sometimes a risk (a draft that should not be seen). Permission cuts at the provenance layer; hiding provenance is not the way to keep a secret. A huge diff (chapter versus chapter) side-by-side will blow a small screen; provenance can index by chapter first, then enter paragraph contrast, but must not therefore keep only one result.

Applying it

• Default the conflict UI to both originals at once, labelled with identity and relative time. If a suggested result exists, it sits after the contrast, it does not replace it.
• Each hunk traces to a version on a side; opening it shows that version’s context, not only a red line.
• After the result is accepted, provenance enters that merge’s history rather than being wiped off the object.
• How to check: a title conflict whose UI is only one prefilled title, with no “this was the phone / this was the computer”, fails provenance. Add identity and time, then ask someone who was not there to choose — they should be able to say whose words they are picking. After accept, open history: both originals should still be there. The same scene as a highlight-only diff of the final sentence, unlabelled by side, also fails.

Related

• Same group: I3.11.1 Field-level merge shrinks what humans have to resolve · I3.11.2 Free text generally cannot be merged by the system · I3.11.3 Finer merge grains win more automatic merges and cost more complexity
• Nearby: I3.04 Sync conflicts · I3.01 Visibility of system status
• Search terms: merge provenance · diff source · who wrote this