Two things are true about the words in a system, and they’re usually held separately. The first is that a name draws a boundary — it cuts one shape out of an undifferentiated mess and declares it a thing, which means the vocabulary you work in determines which designs are even available to propose. The second is that a name doesn’t stay where it was coined; it propagates outward through APIs and docs and support scripts until changing it requires the agreement of people who never knew they were party to the decision.

Held separately, each looks like a manageable annoyance. Held together, they describe something more specific: a naming choice has the cost profile of a schema decision and the review profile of a comment.

That mismatch is the whole problem. Everyone knows a schema change is serious. Adding a column is easy, changing the meaning of an existing one is a migration with a rollout plan, and nobody merges either without someone looking at it, because we’ve all internalized that data outlives code. The same instinct doesn’t fire for words. A field name, a class name, the term picked for a concept in the design doc — these get read as presentation. Is it clear? Is it consistent with the rest? Fine, ship it. The review is about legibility, because naming has been filed under documentation, which is a thing you’re supposed to do well but which doesn’t structurally constrain anything.

Except it does, in exactly the two ways above. The word constrains what the next person can think, and it constrains what anyone can afford to change later. Those aren’t documentation properties. Those are infrastructure properties — the same ones that make schemas and public interfaces get treated carefully. The difference is that a schema announces its own seriousness by being a schema, and a word arrives disguised as a label.

You can see the disguise most clearly in how the two get revisited. A schema decision that turns out wrong produces a migration ticket. A naming decision that turns out wrong produces a shared joke — everyone on the team can tell you that status doesn’t really mean status, that sync is actually async, that the thing called a queue is a stack. The knowledge is universal and the fix never happens, because a joke isn’t a ticket. The team has absorbed the cost into their working memory and each new person absorbs it again on arrival, which is what “it’s fine, you get used to it” actually means.

None of this argues for agonizing over every variable. Most names are local, cheap, and genuinely a matter of taste, and treating them as monuments would grind everything to a halt. It argues for one narrower thing: recognizing which names are the infrastructure kind. A word that names a domain concept, that will appear in a schema or an API or a conversation with a customer, that other things will be defined in terms of — that word is a structural commitment. It deserves the ten minutes of scrutiny you’d give a table definition, at the one moment when ten minutes is all it costs. After that the price only goes up, and it goes up in a currency that isn’t engineering time.