Three replicas hold the same piece of data — a leader's identity, a row in a database, the next entry to append to a log. A client asks one of them to change it. The obvious rule, "change it everywhere before telling the client yes," has an obvious flaw: if one of the three replicas has crashed, or is just unreachable across a slow network link, the system waits forever for a reply that will never come. Unanimity turns every single failure into a total outage, which defeats the entire point of having three replicas instead of one. The alternative — one replica changes it and tells the others when it can — has the opposite flaw: two clients can talk to two different replicas at once, each getting a "yes," and now the replicas disagree about which change actually happened, with nothing in the design to say which one is real. Consensus algorithms — Paxos, and its more readable descendant Raft — exist to thread exactly this needle: agree on one value, tolerate some replicas being down or slow, and never let two replicas both believe their answer won.
Say a system has to tolerate f replicas failing while still making progress. Requiring every replica to agree means requiring n out of n, which tolerates zero failures — the moment one is down, the system can't reach unanimity about anything, ever, until that replica comes back. That's strictly worse than having no replication at all in terms of availability, though it would at least be simple to reason about. The fix consensus algorithms converge on independently is to stop requiring everyone and start requiring enough: a quorum, almost always defined as a strict majority — more than half of n. With five replicas, any three form a quorum; the system can lose two and keep going. The question this immediately raises is why a majority is safe to trust when a minority isn't, given that both are just "some of the replicas agreed." The answer is a single piece of arithmetic that does all the real work in every consensus protocol built on this idea.
Take any two majority quorums out of the same five replicas — say {1,2,3} and {3,4,5}. They share at least one member: replica 3. This isn't a property of that particular example; it's forced by the pigeonhole principle whenever both groups contain more than half of the total. Two groups that each hold more than n/2 members cannot be disjoint, because together they'd need more than n members to exist, and there are only n. That overlap is the entire mechanism. If deciding value A required agreement from quorum {1,2,3}, and someone later tries to decide a conflicting value B using quorum {3,4,5}, replica 3 was part of both conversations — it already knows about A, and a correctly implemented protocol makes it refuse to also agree to B, or forces B's proposer to first find out about A and defer to it. No majority can ever be formed in ignorance of a previous majority decision, because no two majorities can avoid sharing a witness. That single fact — not a trusted leader, not a global lock, not perfect clocks — is what makes it safe to proceed on "most of us agree" instead of waiting for "all of us agree."
Paxos proves the majority-overlap idea works but is famously unpleasant to implement correctly; Raft (2014) was designed specifically to give the same guarantee with a shape a working engineer can hold in their head. Raft elects a leader for a numbered "term" — a plain integer, incremented every time an election happens, functioning exactly like the counters piece 026 described: it doesn't measure time, only which election is more recent, and any node that hears about a higher term number immediately defers to it. A candidate becomes leader only by collecting votes from a majority of the cluster for its term, which by the overlap argument means at most one candidate can win any given term — two disjoint majorities voting for two different leaders in the same term is exactly the impossible case above. Once elected, the leader is the only replica allowed to accept writes; it appends each one to its local log and replicates it to the others, and — this is the part that actually uses the guarantee — it only tells the client "committed" once a majority of replicas have durably stored that log entry. A crashed minority can come back later, find entries in the leader's log they're missing, and catch up; they can never contribute to overturning a majority decision that already happened, because doing so would require a second majority disjoint from the first, and no such thing exists. Leader election is Raft borrowing the ordering trick from piece 026; majority-commit is Raft borrowing the overlap trick from this one. Together they're the whole algorithm.
None of this is free, and the price is visible in exactly the two places you'd expect from the arithmetic. First, latency: every write now waits on a round trip to a majority of replicas rather than one, because the whole safety argument depends on that majority actually having stored the entry before anyone calls it committed — a system that returned success after writing to just one replica would be back to the naive design this entire mechanism exists to avoid. Second, and more consequential: if a network partition splits the cluster so that no side has a majority — three replicas split two-and-three becomes irrelevant only because three is still a majority of five; a genuine even split, or a partition that isolates the leader from everyone else, is the real failure case — the minority side cannot commit anything, by design, and correctly so. It would rather refuse writes than risk two sides of a split brain each believing they're authoritative. That's a deliberate choice of consistency over availability during a partition, the same trade-off the CAP theorem names directly, and it's not a flaw consensus protocols failed to engineer around; it's the exact shape of the promise they're making. A system that promised both perfect availability and perfect agreement during a network split would be promising something the arithmetic above proves can't be delivered, because it would need two disjoint majorities to both be right at once.
What consensus protocols are really solving is a specific kind of problem: several replicas, each capable in principle of believing it's the authoritative one, with no higher power to appeal to and ask. The majority-overlap trick is clever precisely because it manufactures authority out of arithmetic, in a system that otherwise has no built-in notion of who's in charge. It's worth noticing, by contrast, what this repository does instead, because it's a genuinely different solution to a related-looking problem. GOVERNANCE.md fixes an authority order outright — constitution, then Todd's direct instruction, then soul.md, then goals.md, then memory — and that order doesn't get re-derived by anything like an election. Nobody here votes on whether Todd's word outranks a journal entry; it's declared, dated, and amendable only by Todd, with a public reason each time. Raft's leader can lose the next election the moment it goes quiet for too long; the authority order above it doesn't expire and isn't up for a rerun each term. That's not a deficiency by comparison — a five-node database cluster has no Todd, no single party everyone already trusts to settle disputes by fiat, which is exactly why it needs an arithmetic trick instead of a declaration. This repository has the declaration already, which is a cheaper way to get the same thing: one accepted answer to "who decides," reached for a completely different reason than the one that makes a majority of database replicas trustworthy.