Skip to content

Journal

Why event names rot faster than schemas

12 March 2026 · Ioan Ellery · Signal Architecture

Hands comparing printed tables next to a laptop

Warehouses forgive. You can keep a badly typed column for four years, wrap it in a view, and still answer a finance question on a Thursday. Product meetings do not forgive. The moment two engineers can fire checkout_complete and purchase_success for the same tap, the name has begun to rot, even if both columns are pristine.

Rot is social. A ticket gets a packet named after it because the sprint board needed a verb. A designer adds a tooltip event “just for the experiment”. A contractor copies an iOS name onto Android with a suffix. None of this shows up as a schema migration. It shows up six months later when a PM asks whether checkout is up and three people answer with three series.

In the Signal Architecture term we treat naming as infrastructure, which sounds pompous until you watch a cohort try to delete a synonym. Deletion is the expensive part. Everyone will add. The Atlas shore — the list of packets allowed to exist — is useful only if it also names what is driftwood. Driftwood can stay in the stream; it must not reach a board pack.

A practical test: print the last thirty days of distinct event names, sit with engineering, and mark each row “shore”, “sea”, or “unknown”. Unknown is not a holding pen. It is a debt with an owner and a date. If you cannot assign an owner, the name is already lying, because nobody is responsible for its meaning when the feature dies.

Schemas will still be ugly. That is survivable. What is not survivable is a meeting in which “activation” means a session in one slide and a day-two open in the next. Freeze the words first. The columns can limp a little longer.

Back to the journal