[Paper] Semantic Conflict Model for Collaborative Data Structures

Source: arXiv - 2602.19231v1

Overview

The paper Semantic Conflict Model for Collaborative Data Structures by Georgii Semenov and Vitaly Aksenov tackles a long‑standing pain point in real‑time collaboration tools: when multiple users edit the same piece of data offline, the system must merge those changes later. Existing CRDTs guarantee that replicas eventually converge, but they hide the conflict‑resolution logic from developers and users. This work proposes a new conflict model that makes conflicts explicit, lets each client resolve them locally, and does so without any central server.

Key Contributions

• Semantic conflict detection – defines conflicts based on operation dependencies rather than raw timestamps or IDs.
• Three‑way merge over a replicated journal – introduces a lightweight “journal” that records every operation; conflicting ops are rebased onto a reconciling op using a three‑way merge, similar to Git.
• Local‑first reconciliation – each replica can resolve its own conflicts without contacting a coordinator, preserving offline‑first guarantees.
• Concrete register designs – provides a formal specification of the classic Last‑Writer‑Wins (LWW) register and a richer “multi‑register” that supports semi‑automatic conflict resolution.
• Prototype implementation & evaluation – demonstrates the model on a simple collaborative register library, measuring merge latency and bandwidth overhead.

Methodology

1. Operation‑based model – every user action is expressed as an immutable operation (e.g., set(key, value)). Operations carry a semantic dependency graph that records which earlier ops they rely on.
2. Conflict definition – two operations conflict when they are concurrent (no causal path) and they target the same logical entity with incompatible semantics (e.g., two different writes to the same register).
3. Replicated journal – each replica maintains an append‑only log of all received operations. The journal is the single source of truth for conflict detection.
4. Three‑way merge – when a conflict is detected, the system picks a reconciling operation (often the one the user explicitly accepts) and rebases the other concurrent ops onto it using a three‑way diff/merge algorithm (base = common ancestor, ours = reconciling op, theirs = conflicting op).
5. Local resolution workflow – the UI can surface the conflict to the user, suggest an automatic merge, or let the user manually edit the result. Once resolved, the merged operation is appended to the journal and propagated to peers.
6. Evaluation – the authors built a small library for collaborative registers, ran experiments with 10‑node simulated networks, and measured the time to detect and resolve conflicts under varying network latencies.

Results & Findings

In short, the prototype shows that making conflicts explicit does not sacrifice performance or convergence guarantees, while giving developers far more control.

Practical Implications

• Offline‑first apps – Mobile note‑taking, whiteboard, or code‑review tools can let users resolve merge conflicts on the device itself, reducing round‑trips to a backend.
• Custom business rules – Enterprises can embed domain‑specific reconciliation policies (e.g., “prefer the higher‑priced quote”) directly in the merge step, something hard to express with generic CRDTs.
• Better UX for collaboration – UI designers can surface a clear “conflict” view with the exact operations that collided, enabling semi‑automatic suggestions (similar to GitHub’s pull‑request diff UI).
• Interoperability – Because the model works on top of any operation‑based data type, existing CRDT libraries can be retro‑fitted with a semantic journal to gain explicit conflict handling without rewriting the core data structure.
• Reduced server load – No central arbitrator is needed; the system scales horizontally as each client does its own conflict resolution.

Limitations & Future Work

• Journal growth – The replicated log can become large in long‑running projects; the authors suggest periodic compaction but haven’t implemented a full garbage‑collection strategy.
• Complex data types – The paper focuses on simple registers; extending the model to nested structures (lists, maps, trees) may require richer dependency tracking.
• User study – While the prototype shows technical feasibility, the paper does not evaluate how real users interact with the conflict UI; future work could explore usability and error rates.
• Security & access control – The model assumes all operations are trusted; integrating fine‑grained permissions into the journal is an open challenge.

Overall, the Semantic Conflict Model opens a promising path toward more transparent, developer‑friendly collaboration systems that retain the robustness of CRDTs while empowering local, context‑aware conflict resolution.

Authors

• Georgii Semenov
• Vitaly Aksenov

Paper Information

• arXiv ID: 2602.19231v1
• Categories: cs.DC
• Published: February 22, 2026
• PDF: Download PDF