Use exactly one term per concept across the product

What it is

Concept-level terminology control identifies the product concept first, then assigns a preferred term, prohibited terms, and controlled synonyms for a defined language and scope. The preferred term is the default name. A prohibited term is misleading, obsolete, or risky. A controlled synonym is allowed only in a documented channel, audience, or space constraint. The aim is stable recognition of objects, actions, and states—not a universal claim that every concept must have one literal surface form in every language and sentence.

Why it happens

When one concept is called “project,” “space,” and “workspace” without explanation, users may learn three objects; search, support, and task transfer then break. One term applied to different concepts likewise carries an old interpretation into the wrong context. A concept identifier separates semantic identity from surface form: inflection, an approved short label, a full name, and a searchable legacy name can point to one concept under explicit conditions. Conversely, two permission levels or deletion outcomes should not be merged merely because their labels look similar. Stable mapping reduces re-inference, but the benefit comes from defensible concept distinctions rather than mechanical replacement.

Studying it

Sample candidate terms from task flows, UI strings, help searches, and support records. Annotate each occurrence with concept, object type, action consequence, channel, and context; product and domain specialists then distinguish accidental synonym drift from necessary variation. Test the mapping through concept sorting, screenshot naming, and “what will this term do?” tasks. Analyze user search phrases and support paraphrases to see whether the preferred term is recognizable. Compare concept confusion, failed searches, and errors before and after control instead of treating perfect string identity as the sole outcome.

Where it stops holding

Natural language creates surface variation through number, case, gender, word order, and syntax; one concept may also need a full name, approved abbreviation, or accessible description. Mandated text, platform conventions, quotations, and user-generated content are not freely rewritten by a product termbase, though product-authored bridges should connect them to the canonical concept. Brand metaphors may support a message but must not silently replace a feature name. A termbase records concepts and term rules; translation memory (TM) stores historical source–target segments; a style guide governs voice, grammar, and formatting. The latter two do not define product concepts.

Applying it

• Give each core concept an ID, definition, preferred term, prohibited terms, allowed variants, included and excluded contexts, positive and negative examples, owner, state, and version; do not maintain only a “standard word” column.
• In review, ask “which concept is this?” and “does this term rule apply to this channel and context?” before running terminology lint.
• Block a prohibited-term hit by default. Require a controlled synonym to satisfy its registered context; route an unknown concept or context to human review rather than auto-replacing it.
• For high-risk actions, record object, permission, reversibility, and consequence separately, and verify that one broad verb has not collapsed distinct risk concepts.

Related

• Same group: T1.04.2 The glossary must cover interface, docs, and support · T1.04.3 Term changes require global replacement and migration notes
• Adjacent: S1.07.3 Terminology must first be consistent in the source language · S4.05.3 Termbases and style guides provide acceptance criteria
• Search terms: concept-term mapping · preferred term · controlled synonym