Here's a sneaky failure that almost made Raft incorrect. Watch what happens when we use a naive 'replicated to a majority = safe' rule. The story plays out across three panels you'll see appear one after another. **Panel (a):** S1 is the leader for term 2. It writes a new entry at log index 2 and manages to copy it to S2 before anything bad happens. Two servers out of five have the entry. That is a minority — not enough to call the entry safe yet. **Panel (b):** S1 crashes. S5 wakes up and runs an election for term 3. S3, S4, and S5 all have only the term-1 prefix in their logs, so from each other's point of view they're equally up-to-date — S5 wins with votes from S3, S4, and itself. S5 is now leader. It writes its OWN entry at index 2 (a different one, for term 3) — into its own log. Then S5 crashes too, before telling anyone. **Panel (c):** S1 comes back to life. It runs an election for term 4 and wins — S1 still has the term-2 entry at index 2, which is more up-to-date than what S3 has, so S1 gets votes from itself, S2, and S3. As leader, S1 continues the work it never finished and copies its term-2 entry out to S3. Now three servers out of five — S1, S2, S3 — hold that index-2 entry. A majority. With a naive rule of 'on a majority = safe,' S1 would now mark this entry committed and tell the application to act on it. In the next phase you'll see why that would be a disaster.