names that expire rather than lie
Leadership moves, and anything that hard-codes where leadership was becomes a fact somebody has to remember at the worst possible moment. A name that always resolves is not a reliable name; it is a name that can be confidently wrong, and the client asking has no way to tell the difference between a good answer and a stale one.
So the members announce their own role changes onto a message bus, and a record derived from those announcements is given a short lifetime. The record that stops being refreshed disappears. A client asking where leadership is gets either an answer recent enough to use, or no answer at all — and the absence is itself the signal to look again.
The failure that proves the design is the boring one: a record that kept pointing at a member which was no longer leading, because the refresh had stopped and the record had not yet expired. Nothing was corrupt. The answer was simply older than the question.
The cost of this posture is that you cannot put a name somewhere and forget it. The derivation has to be watched, and when a name is wrong, the question is always which announcement stopped arriving.
What this proves is that a fleet can treat names as computed, perishable things, and that a wrong name becomes a normal event with a known cause rather than a mystery someone diagnoses at midnight.
drawn from: naming and leadership commits
Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.