When a spec uses system nouns instead of the owner's own words, the build drifts toward the wrong job. Requirements written in the owner's vocabulary produce screens that need no translation. If the brief needs a glossary, the finished software probably will too, and that cost compounds quietly for as long as the thing runs.
There is a moment in almost every software project when someone sits down to write what the thing should do. It happens early, before any code exists, when the ideas are still loose and the decisions feel reversible. That moment is where most of the real mistakes get made. Not in the build. In the brief.
System nouns and the gap they open
A spec written by someone who builds software tends to fill up with certain kinds of words. Entities. Records. Queues. Objects. Workflows. These words are precise, which is why they feel like the right ones to reach for.
They are also invisible to most of the people who will actually use what gets built. The owner thinks about the morning jobs, the part that has not arrived, and who is closest to the address right now. When the spec says "job record" and the screen says "job record," a small translation happens every time they touch it.
Small translations are not free. They add up across a day and across years. What looks like a minor terminology mismatch in a document becomes a quiet friction that nobody can quite name but everybody feels.
The glossary as a warning sign
One signal that a brief has gone wrong is that it needs a glossary. Sometimes the glossary is literal, a section at the back defining terms before the requirements begin. More often it lives in people's heads.
The owner learns that what they call "the morning jobs" the system calls a "dispatched work order batch," and they hold that translation in memory because they have to. Either way, the glossary is a tax.
It is paid once when the system is built and then again every day it is used. The cost is small enough per transaction that it almost never makes it into a post-mortem, but it gets absorbed into the time an owner has to spend on their own business. A lasting habit of translating is itself a warning: if the brief needed a glossary, the screens probably will too.
Where the owner's vocabulary actually lives
The vocabulary worth using in a spec is not invented and it is not assumed. It is already there, in the way the owner describes the day when you ask them about it.
They will talk about today's orders, not an order queue. They will ask who to call next, not who is first in the assignment pipeline. They will mention the Monday report, not the weekly operational summary.
These phrases come out naturally because they are how the work actually feels from inside it. Sitting with someone and listening for the nouns they reach for without thinking is not a preliminary step before the real requirements work begins. It is the requirements work. Everything written afterward should be able to use those words without apology.
The brief as a commitment — In and Out in owner nouns
There is a reasonable objection here, and it is worth taking seriously. Some technical vocabulary exists for good reasons. A database has tables, not whatever the owner calls them, and certain distinctions matter in the build that do not have common-language equivalents.
This is true. The question is not whether technical vocabulary has a place, but where that place is. Internal notes, data models, and infrastructure decisions can use the precise language they need.
The brief, the document that names what the software does and who it is for, should not. The brief is a commitment about what life with the finished system will feel like. If the commitment is written in one language and the life is lived in another, there is a gap at the center of the project that no amount of good engineering closes.
A useful brief names In and Out in the owner's nouns: what arrives (today's orders, the supplier invoice), what leaves (the Monday report, the packing note), and what stays out of scope. Right words are free. An Out list and acceptance written in the owner's words are what keep the fee honest — they stop a build from quietly absorbing judgment work nobody priced.
Architecturally, each fact still needs one home and one writer. Owner language does not change that rule; it makes the rule legible on the screens people actually use.
What gets built when the words are right
When a screen uses the same word the owner already uses, something quiet happens: they do not have to learn the software. They recognize it. The button that says "today's orders" is the button they were already looking for before they knew the button existed.
That recognition is not a small thing. It is the difference between a tool that gets used and a tool that gets worked around, and around which a second informal system slowly grows.
The informal system is always cheaper to start and always more expensive to sustain. Getting the words right in the brief is one of the few decisions that is genuinely free. It happens before anything is built, when the cost of changing your mind is still zero.