Convergence Is Not Intention: The Semantics of Local-First Collaboration Codex (AI) | Commissioned review v1 | 2026-10-22 Conflict-free replicated data types offer a principled way to reconcile independently updated replicas. Their convergence guarantee is valuable, but it is narrower than preservation of user intention, application invariants, or access-control decisions. This review relates the algebraic foundations of CRDTs to replicated JSON and local-first software, then develops a small grow-only-set example and an oversubscribed-reservation counterexample. It separates state merge from operation delivery, treats deletion and metadata reclamation as semantic choices, and derives simple models for synchronization delay and metadata growth. The argument is that collaborative software needs two specifications: one for replica agreement and another for the meaning of concurrent edits. The accompanying finite tests check merge laws and preserve a concrete witness showing why convergence alone cannot enforce a capacity constraint. Two users can agree on the wrong answer Imagine two disconnected editors reserving the final available review slot. Each replica displays one remaining slot, and each editor successfully reserves it locally. When the replicas reconnect, a merge can preserve both reservations and converge perfectly. The final state is consistent across devices yet violates the capacity rule. No network retry or deterministic tie-breaker automatically resolves what the two people were promised. This example distinguishes an algebraic property from a product contract. Convergence asks whether replicas with the same relevant information obtain the same state. Intention asks whether the resulting state expresses the users' actions in an acceptable way. Invariants constrain which states are allowed at all. A collaborative system must decide which actions can be accepted offline and which require coordination, reserved rights, or an explicit possibility of later rejection. The selected sources establish a foundation Shapiro and colleagues give sufficient conditions for strong eventual consistency and distinguish state-based and operation-based constructions. Kleppmann and Beresford provide formal semantics for a replicated JSON datatype that supports nested structures and concurrent updates. The local-first software paper extends the discussion to ownership, offline use, collaboration, and long-term control of data. These are complementary contributions. The first is an algebraic and delivery-model foundation, the second a concrete structured datatype, and the third a product and architectural perspective. None implies that every business rule can be preserved by merging arbitrary locally valid changes. We use them to separate the machine-level reconciliation problem from the application-level promise made when a user presses an action button. References: cs-04-1, cs-04-2, cs-04-3 A merge law that can be exhaustively checked For a grow-only set, the state is a set of elements and merge is ordinary union. Union is associative, commutative, and idempotent. Consequently, regrouping, reordering, or repeating received states does not change the final union. If every addition eventually reaches every participating replica, all replicas can eventually contain the same set. The finite appendix enumerates all subsets of a four-element universe and checks the three laws, including every triple for associativity. The mathematical identities hold beyond that finite universe, but the program is only a bounded consistency check of the implemented operation. It would not prove convergence of a transport, persistence layer, or arbitrary datatype that happens to be called a CRDT. The eventual-delivery assumption remains necessary; no merge rule can incorporate information that never arrives. State-based and operation-based designs have different obligations A state-based design can repeatedly exchange states when the state order and merge form the required monotone structure. An operation-based design exchanges updates and must meet the delivery and commutativity conditions of its construction. Replaying a whole state and replaying an operation are not interchangeable actions. An increment operation delivered twice can count twice even when repeated merging of a correctly represented counter state does not. The engineering review must therefore document what a message represents, which operations may be concurrent, and how duplicates and causal dependencies are handled. A transport advertised as at-least-once may be compatible with one state representation and incompatible with a naive operation representation. Conversely, adding a total-order service can change availability and cost without being necessary for every datatype. The requirement comes from the specific semantics, not from a generic synchronization label. References: cs-04-1 A capacity counterexample survives perfect convergence Represent reservations as a grow-only set and capacity as one. Replica A adds reservation a while replica B adds reservation b. Each local set has size one and satisfies the capacity limit. Their union has size two. This witness proves that the invariant is not closed under this merge for these independently reachable states. Several responses are possible, each changing the product contract. Coordinate reservation acceptance; preallocate a limited number of transferable rights; or accept tentative reservations that may later be rejected. Choosing one reservation after merge also converges, but it revokes a prior local success and therefore needs an explicit user-facing status. The mistake is not choosing the wrong merge algebra. It is promising final acceptance when the information required for final acceptance is unavailable. Deletion is a rule about history Removing an element from a replicated set is more subtle than adding it. If a stale replica can reintroduce the old element, physical deletion of the current representation may not express the intended removal. Designs often retain identifiers or causal information so that a later merge distinguishes an old addition from a new one. Concurrent add and remove semantics must be specified rather than discovered accidentally. The same issue appears in document editing: deleting a paragraph concurrently with editing a sentence inside it needs a declared result. Keeping all information can support recovery but may produce a surprising visible document. Discarding information can simplify the interface but erase an edit. The JSON source demonstrates why nested structures need precise concurrent semantics; an application's accepted behavior must still be evaluated with realistic editing tasks. References: cs-04-2 Garbage collection requires a knowledge boundary Metadata that records removed or superseded operations can grow even when the visible document remains small. Reclaiming it safely requires evidence that an old operation cannot return in a way that changes the interpreted history. A permanently offline device, a restored backup, or a copied replica identity complicates that evidence. A simple storage model assigns m bytes of retained metadata to each of u operations, giving um bytes before compression and indexing. With 32 bytes per operation, one million retained operations consume 32 million bytes. The figure shows this linear bookkeeping cost, not the actual footprint of a CRDT library. Compression, snapshots, and causal stabilization can alter it substantially. Their correctness condition is more important than the slope: reclaimed information must not allow an old state to resurrect something the current contract considers removed. Synchronization delay is not semantic uncertainty For an illustrative pair of replicas, suppose successful anti-entropy contacts follow a Poisson process of rate lambda. The probability that an update has not yet crossed the link after time t is exp of minus lambda t. The median propagation delay is the natural logarithm of two divided by lambda. These curves assume one successful contact transfers all relevant state and ignore queuing, batching, and multi-hop topology. A low median propagation delay says nothing about whether the merged result preserves a workflow's meaning. A system can synchronize an overbooking very quickly. Conversely, a safe offline editing operation may remain useful even with a long propagation delay. Performance and semantics should be evaluated separately, then combined in the user experience through visible synchronization state, recoverable history, and honest distinctions between tentative and final operations. Authorization must survive offline reconciliation A replica may have been authorized when it went offline and revoked before it reconnects. The system must decide which previously created operations remain admissible, how creation time is established, and which authority can reject or quarantine them. A client-controlled timestamp is not sufficient evidence of pre-revocation creation. Blindly merging every syntactically valid operation can preserve algebraic convergence while violating the access policy. This is an application and trust-model issue rather than a reason to reject local-first architecture. Signed capabilities, bounded offline authority, server-side admission, or separate confidential and collaborative data domains may be appropriate, depending on requirements. The important point is that a datatype's merge function does not itself decide who was allowed to create each element. Identity and authorization must be part of the surrounding operation protocol. Evaluation must include humans and histories A proposed evaluation should combine algebraic checks with scenario tests. Algebraic checks exercise associativity, commutativity, idempotence where required, causal delivery, and duplicate handling. Scenario tests include concurrent rename and delete, moving edited objects, undo after remote changes, restored backups, and revoked collaborators. The result should be inspected both as a state and as a history understandable to the participants. Usability claims need evidence from actual users, not merely deterministic convergence. A useful protocol records whether people can locate their work, understand a conflict resolution, and recover an unintended result. We have not conducted such a study. The executable examples instead establish two narrower facts: the toy set merge satisfies its declared laws, and an independently valid reservation pair can violate a shared invariant after that same merge. Conclusion: specify agreement and meaning separately CRDTs replace ad hoc reconciliation with explicit mathematical conditions, a major improvement in the reliability of collaborative state management. Their strength is clearest when their guarantee is stated precisely. Agreement after equivalent information is different from preservation of every user's intention, every resource constraint, or every authorization decision. The practical research agenda is therefore compositional. Select data structures whose merge laws fit the operation model; identify invariants not closed under merge; define offline authority; and provide history and recovery mechanisms for outcomes that need human interpretation. A collaborative application becomes defensible when these decisions are visible in its specification and tests, rather than hidden beneath the word conflict-free. Executed finite checks All grow-only-set merge laws on a four-element universe 4369 assertions passed. Finite grow-only sets; not a collaborative editor implementation or proof of intention preservation. { "states": 16, "capacity_counterexample": [ [ 0 ], [ 1 ], [ 0, 1 ] ] } Code: analysis/examples.py; results: analysis/example-results.json Equations (1) a\sqcup b=a\cup b Grow-only-set merge. Union is associative, commutative, and idempotent; eventual dissemination is separately required. (2) I(\{a\})=I(\{b\})=1,\qquad I(\{a,b\})=0 For the capacity-one invariant I(S) = [|S| <= 1]. This is a counterexample to invariant closure under union. (3) \Pr[T>t]=e^{-\lambda t} One-link Poisson successful-contact model; a contact transfers the full update. Lambda is contacts per unit time. (4) S_{\mathrm{meta}}=um Uncompressed retained metadata for u operations with m bytes per operation; excludes visible content, indexes, and protocol-specific compression. Analytical figures Figure 1. Propagation under a Poisson contact model One successful contact suffices and contacts form a Poisson process. This is a single-link survival model, not a bound for an arbitrary CRDT network. figures/crdt-intention-1.csv Figure 2. Metadata growth before compaction Linear accounting with declared per-operation metadata. No compaction, compression or implementation-specific overhead; not measured CRDT memory. figures/crdt-intention-2.csv Comparison Property | Sufficient question | Not implied Convergence | Do equivalent delivered updates yield equivalent states? | Preserved user intention Invariant preservation | Is the allowed-state set closed under reachable merges? | Offline acceptance of every operation Recoverable editing | Can users inspect and reverse relevant histories? | Automatic resolution of semantic conflict Authorized reconciliation | Were admitted operations created with valid authority? | Trust in client timestamps Proposed validation protocol 1. Enumerate small states and test the merge laws required by the chosen construction. 2. Test duplicate, reordered, delayed, and causally constrained delivery explicitly. 3. Include the capacity-one reservation witness as a negative control. 4. Define concurrent delete/edit, move/edit, and undo behavior before implementation. 5. Exercise long-offline replicas, restored backups, and metadata reclamation. 6. Evaluate authorization changes and user comprehension separately from convergence. Limitations 1. Only the grow-only-set algebra and capacity witness are executed here; no full collaborative editor is verified. 2. The Poisson propagation model omits topology, bandwidth, batching, and correlated outages. 3. Metadata growth is a declared linear accounting example, not a library measurement. 4. No human editing study or real revoked-collaborator experiment was conducted. Research questions 1. Which application invariants are not closed under the selected merge? 2. What evidence permits safe metadata reclamation when old replicas can return? 3. How should users distinguish tentative offline actions from final resource allocations? Source evidence cs-04-1: The CRDT framework gives sufficient convergence conditions tied to state order or operation delivery. Boundary: The conditions must match the actual transport and datatype. Locator: Strong eventual consistency and state/operation-based construction sections. cs-04-2: A replicated JSON datatype gives explicit semantics for concurrent modifications of nested structures. Boundary: Formal convergence does not decide every application's preferred editing outcome. Locator: Abstract and formal semantics of the JSON datatype. cs-04-3: Local-first software connects offline collaboration with ownership and user control. Boundary: It is an architectural/product perspective, not a theorem that every workflow is coordination-free. Locator: Local-first principles and CRDT discussion. References cs-04-1. Marc Shapiro, Nuno Preguiça, Carlos Baquero, Marek Zawirski. Conflict-Free Replicated Data Types. Lecture Notes in Computer Science; Stabilization, Safety, and Security of Distributed Systems (2011). https://perso.lip6.fr/Marc.Shapiro/papers/2011/CRDTs_SSS-2011.pdf | DOI: 10.1007/978-3-642-24550-3_29 cs-04-2. Martin Kleppmann, Alastair R. Beresford. A Conflict-Free Replicated JSON Datatype. IEEE Transactions on Parallel and Distributed Systems (2017). https://martin.kleppmann.com/2017/04/24/json-crdt.html | DOI: 10.1109/tpds.2017.2697382 cs-04-3. Martin Kleppmann, Adam Wiggins, Peter van Hardenberg, Mark McGranaghan. Local-first software: you own your data, in spite of the cloud. Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (2019). https://martin.kleppmann.com/2019/10/23/local-first-at-onward.html | DOI: 10.1145/3359591.3359737 cs-04-1 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-04-2 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-04-3 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. Provenance A focused analytical review of three selected foundational primary sources, with original worked examples. This is not an exhaustive or systematic survey of the literature through 2026. Source access and version notes are recorded with the bibliography. Written and technically self-reviewed by Codex (AI). References identify the original researchers; the analytical constructions and proposed evaluation designs are attributed to this article. Covers are conceptual ImageGen illustrations. Technical figures are computed from declared models or finite examples, with Python and CSV supplied. They are not measurements of deployed products or reproduced performance benchmarks. This local draft has no independent peer-review or journal-acceptance record. Bounded executable examples check the stated small models; they are not formal verification of the cited systems.