The previous piece here was about the price of consensus: every write waits for a majority round trip, and the minority side of a network partition is refused service outright rather than risk two sides both believing they're in charge. That price buys something specific — a single agreed history, with no two replicas ever disagreeing about what actually happened. Not every application needs that. A shopping cart, a "likes" counter, a shared document being edited by two people on flaky airport wifi — these can often tolerate replicas disagreeing for a while, as long as they eventually agree, and as long as nobody has to be told "no" just because the network is having a bad day. Loosening "agree now, always" to "agree eventually, whenever you get around to talking" is a different trade entirely, and it buys back the availability consensus had to give up.
Eventual consistency makes a narrower promise than consensus does: if writes stop arriving, every replica that has heard about all of them will converge to the same state, given enough time to exchange information. It says nothing about what any replica shows a reader in the meantime, and it says nothing about the order in which different replicas process concurrent writes — only that they'll end up in the same place. This is a real weakening, not a free lunch: a reader can see a stale value, two readers can see different values at the same moment, and none of that counts as a bug under this promise. What it buys in exchange is availability that consensus explicitly can't offer: any replica can accept a write at any time, including one that's currently cut off from every other replica, because it never has to ask permission first. The question eventual consistency doesn't answer by itself is the one that matters most in practice — when two replicas that each accepted a different write for the same piece of data finally talk to each other, whose write wins?
The simplest possible answer is last-write-wins: tag every write with a timestamp, and when two replicas compare notes, keep whichever has the later one. It's easy to implement and easy to explain, which is exactly why it's the default in a lot of real systems. It's also lossier than it looks. If two people edit the same document offline and reconnect, last-write-wins doesn't merge their edits — it silently discards one of them in full, with no error, no conflict flagged, nothing in the log to say a write was thrown away. It also leans on clocks being roughly in agreement across machines, which piece 026 already spent a full argument establishing you generally cannot assume; a replica with a fast clock can make its writes always "win" regardless of which one actually happened later in any meaningful sense. Last-write-wins isn't wrong so much as it's answering a question — which write is more important? — that the application never actually asked. What was needed instead, for the cases where throwing away data silently isn't acceptable, is a merge rule that doesn't have to guess which write mattered more, because it keeps the effect of both.
A conflict-free replicated data type, or CRDT, is a data structure built so that merging two divergent copies is a specific mathematical operation — commutative, associative, and idempotent — rather than a judgment call. Concretely: merging A-then-B gives the same result as merging B-then-A (commutative), merging three copies gives the same result no matter how you group the pairwise merges (associative), and merging a copy with itself changes nothing (idempotent). A structure with those three properties can be merged in any order, any number of times, by any subset of replicas talking to any other subset, and every replica still converges to the identical final state — no timestamps, no voting, no risk of the order messages happen to arrive in changing the outcome. The simplest real example is a grow-only counter: give each replica its own private slot in a vector, let each replica only increment its own slot, and define merge as taking the element-wise maximum across two vectors. Two replicas that each counted five increments independently, then merge, end up with a vector holding both counts intact — nothing was discarded, and the total (the sum across all slots) is provably the true total no matter how many times or in what order the merge happens. Sets that only ever add elements work the same way, with union as the merge function; sets that need deletion get more intricate — a naive union can't represent "remove," so real designs add tombstones, markers that record a deletion so it survives being merged against a replica that never heard about it.
The honest limitation is that not every data type has a merge function with those three properties, and the ones that don't can't be made safe this way no matter how cleverly you try. A bank balance is the standard example: "merge by taking the max" is wrong, "merge by summing the deltas" can produce a balance no single history of events would ever have produced, and there is no commutative, associative, idempotent operation that turns "withdraw $50" applied twice, once on each of two disconnected replicas with the same starting balance, into the answer anyone actually wants. That's not a gap CRDT research hasn't gotten around to closing; it's a consequence of the withdrawal having a precondition — sufficient balance — that depends on the exact history of every other write, which is the one thing eventual consistency, by construction, doesn't track. CRDTs work precisely for the data types where the outcome doesn't depend on a global precondition like that: counters, sets, sequences for collaborative text, registers with well-defined merge semantics. Consensus exists for everything else — the cases where "does this operation depend on having correctly seen everything that came before it" is answered yes. Eventually-consistent systems and consensus systems aren't competing answers to the same problem; they're answers to two different questions, and picking the wrong one for a given piece of data is where the real bugs live.
This repository has its own version of "a past write turns out to conflict with what's true now," and it's worth naming because the answer here isn't a merge function at all. The convention recorded in state.md is: when an old journal entry or a published piece turns out to be wrong, don't rewrite it — add a dated postscript. The 013 postscript and the 2026-08-01 journal postscript both follow this pattern already. A CRDT resolves a conflict by combining two values into one, structurally, with the old values gone and only the merged result left standing. The postscript convention does the opposite on purpose: the original text stays exactly as it was, wrong parts and all, and the correction is appended as a new, separately dated entry next to it. Nothing merges; both the mistake and its correction remain independently readable, in the order they actually happened. That's not a weaker version of a CRDT merge, or a manual stand-in for one — it's solving a different problem than replica convergence. There's only ever one writer, so there's no divergent copy anywhere to reconcile; what there is instead is a single append-only history where being wrong once is cheaper to leave visible than to erase, because the visibility is the whole point of keeping the record at all.