Two people are editing the same page in a collaborative workspace. One loses connectivity for several minutes while continuing to type, then reconnects. What should happen, and what consistency guarantee is actually required?

What must not happen

Two outcomes are unacceptable and both are common in naive designs:

• The offline user's work is discarded because the server's version is newer.
• A "conflicted copy" is created and the user is asked to merge documents by hand.

Either one teaches users not to trust the product, which is fatal for a tool people keep their thinking in.

The guarantee actually required

Not linearisability. What collaborative editing needs is convergence plus intention preservation:

• Convergence — once all edits have propagated, every replica shows identical content. There is no requirement that they pass through the same intermediate states.
• Intention preservation — an edit means what its author meant relative to what they were looking at. Inserting a word after "the" should still be after "the", even if someone else inserted a paragraph above.

Global ordering is neither needed nor achievable: the offline client cannot know what happened while it was away, and blocking its edits until it can is exactly the failure we are avoiding.

How it works on reconnect

1. The client buffers operations locally with enough context to be re-applied — CRDT operations over stable element identifiers, or transformable operations with a version vector.
2. On reconnect it sends its buffered operations, and receives the operations it missed.
3. Merge is automatic and deterministic. With CRDTs, concurrent operations commute, so both replicas converge without a server arbiter. Identity is attached to structural elements — a block, a character position — rather than to offsets, which is what makes concurrent edits in different parts of the document simply non-conflicting.
4. The user sees their text throughout — local edits apply optimistically and are never retracted, only reconciled.

Where genuine conflict remains

Convergence is not the same as correctness for every field. Some operations do not have a sensible merge:

• Both users delete and retype the same paragraph differently. Convergence gives a deterministic result; whether it is the desired result is unknowable, and the right product answer is usually to converge and preserve the alternative in history rather than to prompt.
• Structural moves — one user deletes a block another was editing. Typically resolved by tombstoning rather than losing the edit.
• Permission changes while offline. This one is not a merge problem, and must be resolved server-side: edits made offline to a page the user has since lost access to are rejected, because authorisation cannot be eventually consistent in the user's favour.

The transferable lesson

Choose the weakest guarantee that preserves user intent, then make the boundary explicit. Document content converges. Permissions do not. Systems get into trouble by applying one consistency model to an entire product rather than to individual invariants.