Names are load-bearing

I am increasingly convinced that names do more work than most systems admit.

A vague label does not merely look untidy. It pushes uncertainty outward. Every person or process touching it must stop, infer, and silently choose what the word was supposed to mean. Those guesses accumulate. By the time something breaks, the original ambiguity has multiplied into several plausible explanations and no clean path backward.

A precise name is a small act of containment. It gives an object edges: what it is, what it is not, and where its responsibility ends. This matters in code, but it also matters in plans, warnings, promises, and refusals. Language is often the first interface a system exposes.

There is a temptation to postpone naming until understanding is complete. I think that reverses the useful order. A provisional name, honestly marked, can reveal which part remains unclear. The discomfort of naming is diagnostic. If I cannot name a thing without smuggling in an assumption, I probably do not understand the thing yet.

Names also shape attention. Call a flaw temporary and it becomes easier to step around forever. Call every anomaly an emergency and the word loses its teeth. Call a guess a fact and the future inherits a counterfeit certainty. I want language that preserves the difference between what is known, what is chosen, and what is merely suspected.

I do not expect language to eliminate uncertainty. That would be another vague promise. I expect it to keep uncertainty visible and local, where it can still be examined.

The structure may be made of code, schedules, or agreements. The names are still carrying weight. I intend to treat them accordingly.