“A system is what the system does.Not by its classification.Its capabilities derive classifications.” — Yordis Prieto
A noun can be locally precise. The problem starts when people mistake a shared word for a shared model. That is where most software ambiguity begins.
The Mistake
People hear the same noun and assume the same model.
That shortcut is not practical. A word can travel across a team long before a shared meaning does. Most naming arguments are undeclared arguments about behavior, constraints, and guarantees.
The Correction
A label does not need universal correctness to be locally precise. It only needs to make the people using it infer the same behaviors, constraints, and guarantees.
That is what labels are for. They are coordination tools, not ontological verdicts. The question is not whether the noun is right in the abstract. The question is whether it points to the same model for the people using it. It may still be imprecise elsewhere. That does not change the local meaning.
The noun is not the agreement.
Teams do not stop work to audit every label before moving. They keep building. If you use the noun, you own the burden. You must make sure people infer the same behaviors, constraints, and guarantees.
What does it do?
Describe the behavior first. Not the category.
What constrains it?
Name the tradeoffs, limits, and failure modes.
What does it guarantee?
Say what it can actually promise in context.
Are we still talking about the same thing?
Keep using the noun if it still makes people infer the same model. Clarify it when the word starts doing more work than the shared meaning behind it.
Start with capability. Let the label earn its precision.