Collaborative Editing Protocol¶
Collaboration protocol — instantiates Concurrency Control
Lets several people edit one live document at once without silent overwrite by stamping every change against a revision and weaving non-conflicting edits together while surfacing real clashes as prompts.
A Collaborative Editing Protocol is the set of rules and affordances that let several people work on one shared document at the same time without any of them silently erasing another's work. Each change is tagged with the revision it was based on, so the system can tell whether two edits touched the same place; edits that do not overlap are merged automatically, and the ones that do are raised as visible prompts — a comment, a suggestion, a highlighted overlap — rather than resolved by whoever saved last. Its defining idea, and what separates it from a lock, is that it keeps the surface open to everyone at once and non-destructive: coordination happens through versioning, presence, and soft section ownership, not by making writers wait for a turn.
Example¶
Three lawyers are co-drafting a merger agreement in a shared editor. By convention each owns a schedule — one the reps-and-warranties, one the closing conditions, one the indemnification — and the tool shows all three cursors live. Two of them end up editing the indemnification cap in the same minute. Rather than let the later save overwrite the earlier one, the protocol stamps each edit against the revision it started from, sees that both touched the same clause, and raises the overlap as a suggestion thread showing both proposed numbers side by side. The lawyers talk it through in the margin and accept one.
Meanwhile, edits the three make in different schedules merge silently and instantly, because they never touched the same text. No one waited for a lock; no one's paragraph vanished. The document stayed a single live artifact the whole time, with a revision history that can replay who changed what. Had the same clash instead arrived as two already-committed branches to be reconciled after the fact, that would be a merge review — a downstream step, not this continuous, in-document protocol.
How it works¶
- Stamp every change with a base revision. Each edit records the version it was applied to, which is what makes a concurrent edit detectable and lets the system order changes.
- Weave non-overlapping edits automatically. Changes to disjoint parts of the document are integrated without friction, preserving everyone's work.
- Coordinate the interaction, not the timing. The protocol defines how co-editors work together — live presence and cursors, soft section ownership, suggestion mode, comments, or branch-and-merge — so people self-organize around the shared surface instead of queuing for it.
- Surface true overlaps as prompts. When two edits touch the same span, the clash is shown for a human to reconcile rather than silently collapsed.
The protocol's job ends at surfacing a genuine incompatibility; deciding which version wins is a separate reconciliation step.
Tuning parameters¶
- Change granularity — whether revisions are tracked per character, per line, or per section. Fine granularity merges more edits cleanly but tracks more metadata; coarse granularity is lighter but flags more false overlaps.
- Section-ownership firmness — from hard-locked sections only their owner may touch, to purely advisory "this is mostly mine." Firm ownership prevents overlap but re-creates serialization; advisory keeps flow at the cost of occasional clashes.
- Sync mode — real-time operational merging versus asynchronous branch-and-merge. Real-time feels seamless but merges aggressively; async gives deliberate control but delays integration.
- Edit vs. suggest — whether contributors write directly or propose changes an owner accepts. Suggestion mode protects a canonical version; direct editing is faster among trusted peers.
- Presence visibility — how much of others' activity (cursors, selections, live keystrokes) is shown. High visibility averts collisions socially but can distract.
When it helps, and when it misleads¶
Its strength is many authors on one coherent document with no lost edits and a full revision history — exactly the human-knowledge-work face of concurrency control. Non-conflicting work proceeds fully in parallel; only genuine overlaps demand attention. The engineering behind seamless real-time versions is operational transformation, the technique underneath Google Docs, and its lock-free cousin the CRDT.[n1]
The failure mode is that automatic merging preserves text, not meaning: two edits to the same sentence can both apply and produce a grammatically merged but nonsensical or self-contradictory result — the "both changes landed, the clause now says nothing" problem. The classic misuse is trusting the auto-merge to have preserved intent and shipping without a human reading the reconciled passage. Over-tight section locks are the opposite trap, quietly turning collaborative editing back into take-a-turn serialization. The guarding discipline is to keep section ownership advisory rather than rigid, and to route every semantic clash — not just textual overlap — to a human review step before it is accepted.
How it implements the components¶
Collaborative Editing Protocol fills the versioning-and-interaction pair a live-document protocol can own:
version_token— every change is stamped against the revision it was based on; that per-change version is what makes concurrent edits detectable and weave-able, and it is the backbone of the revision history.coordination_rule— the protocol itself: the rules and affordances (soft section ownership, presence, suggestion mode, comments, branch-and-merge) that govern how simultaneous editors interact with the shared document.
It does not decide which of two genuinely incompatible edits wins — that conflict_resolution_rule is Merge Conflict Review's, the nearest twin (this protocol keeps concurrent edits non-destructive and surfaces the clash; the review adjudicates it). And it does not draw a standing, team-wide grid of who may modify which surface — that ownership_boundary and work_partition are Ownership Assignment Matrix's; this protocol's ownership is intra-document and soft.
Related¶
- Instantiates: Concurrency Control — this protocol is the archetype's answer for simultaneous human editing of a shared artifact.
- Consumes: Merge Conflict Review — the semantic clashes this protocol surfaces are handed to a review step for resolution.
- Sibling mechanisms: Mutex or Lock · Semaphore or Permit System · Reservation Calendar · Ownership Assignment Matrix · Deadlock Timeout and Detection · Transaction Isolation · Optimistic Concurrency Check · Facilitated Turn-Taking
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: During live editing the mechanism stamps revisions, detects concurrency, automatically weaves non-overlapping changes, and surfaces true overlaps for reconciliation, so its operative form is runtime concurrency control.
Nearest alternative: Protocol, Workflow & Routine — Editors may follow coordination conventions, but automated revision comparison and merge behavior continuously control the shared document beyond a human workflow.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Collaborative-systems engineering established revision-stamped concurrent editing with operational transformation or CRDT convergence and visible semantic conflicts.
Related originating lineages:
- Human-Computer Interaction — Presence, suggestions, and conflict prompts supply the usable coordination surface.
Review resolution: Both reviewers agree on computer_science as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains human_computer_interaction only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
This protocol's version_token is used to integrate concurrent edits — it identifies which revision a change was based on so the change can be woven in. That is the opposite use from Optimistic Concurrency Check, whose version token rejects a stale write and bounces the loser to retry. Same artifact, opposite reflex: one weaves parallel work together, the other refuses the second write outright.
[n1] Operational transformation (OT) and CRDTs — OT, the algorithm behind real-time editors such as Google Docs, transforms each concurrent operation against the others so all replicas converge to the same document; a conflict-free replicated data type achieves convergence structurally, without a central server. Both preserve every edit's text automatically — which is exactly why semantic conflicts still need human review despite a clean automatic merge. ↩