Choosing Semantic Artifacts

You've already met the semantic maturity spectrum in passing: glossary, controlled vocabulary, taxonomy, thesaurus, ontology. This unit slows down on it, because choosing the wrong artifact is one of the most common ways a young architecture practice burns credibility. Teams either under-build (a glossary nobody uses to resolve a dispute) or over-build (a formal ontology commissioned to settle an argument about two words). The skill is matching the artifact to the alignment problem you actually have, then diagnosing the problem precisely enough to know which one that is.

In this lesson, you will learn to:

• Distinguish glossaries, controlled vocabularies, taxonomies, thesauri, and ontologies
• Diagnose homonym, synonym, and granularity conflicts in shared terminology
• Recognize the preferred term, accepted synonyms, and accountable owner needed to make a terminology decision durable

Each artifact on the spectrum adds expressive scope to the one before it, and each addition costs effort to build and maintain. A glossary pairs terms with agreed definitions. That is all it does: it records what people mean, without saying which term anyone should use. A controlled vocabulary goes further by designating approved terms to be used consistently, so that "live user" and "active customer" stop circulating side by side in the same reporting pack.

Beyond that, the artifacts add structure. A taxonomy arranges terms in a hierarchy, letting you say that one concept sits under another. A thesaurus adds broader, narrower, and related links, so terms can be navigated in multiple directions rather than a single tree. An ontology goes furthest: formal classes, relationships, and rules expressive enough to support inference, meaning a system can derive claims that were never stated directly.

The practical rule is to choose the least complex artifact that resolves the problem in front of you. If three teams disagree about what a word means, a glossary makes the disagreement visible but does not end it. If they use four different words for the same idea, a controlled vocabulary does end it. Reaching for an ontology at that point is not rigor; it is an expensive way to avoid a decision.

Before you can pick an artifact, you need to name what kind of conflict you have. Three types account for most disputes you'll encounter early in your career.

A homonym conflict is one word carrying different ideas: analytics calls a customer "active" if they used the product, while membership operations calls a customer "active" if their subscription is not suspended. Same word, genuinely different populations. A synonym conflict is the reverse: different words carry the same idea. For example, "active customer" and "live user" may be defined identically by two teams who have never compared notes.

A granularity mismatch is the same idea measured at different levels of detail: "opened the app at least once" versus "opened the app on four or more days." Nobody is wrong; they are describing behavior at different resolutions.

Classifying the conflict matters because the remedy differs. Synonym conflicts are cheap to fix: pick a preferred term and record the others as accepted synonyms. Homonym conflicts are expensive, because someone must choose, and both parties are publishing numbers built on their own reading. Granularity mismatches usually need term differentiation rather than arbitration: "active" and "frequently active" can both survive if the distinction is written down.

• Natalie: These two definitions are the same thing. We're arguing over nothing.
• Ryan: They're not, though. Yours counts every hour logged against a client code. Mine counts only the hours the contract lets us invoice.
• Natalie: Fine, but we both call it a "billable hour."
• Ryan: That's the problem. One term, two populations. If we were just using different words for one idea I'd let you win the naming argument and move on.
• Natalie: So this isn't a wording fix.
• Ryan: No. Somebody has to decide which meaning the published figure carries, and that person has to have the authority to make it stick.

Notice how naming the conflict type immediately changed what the conversation was about: not whose word is nicer, but who gets to decide.

Diagnosis tells you what kind of conflict you have; convergence is what the next meeting must actually decide. A controlled vocabulary becomes a governed artifact rather than a word list when it carries three things. The first is a designated preferred term for each concept: the one word teams are expected to use in published work. The second is a set of accepted synonyms mapped to that preferred term, so legacy wording is retired deliberately instead of quietly persisting.

The third is a named accountable owner with authority to change an entry, so the vocabulary can absorb a business change without dissolving into a fresh argument. That element is the one beginners most often skip, and it is the one that determines whether the artifact survives. When you facilitate convergence, drive toward all three outputs explicitly: which term wins, which words map onto it, and who signs off on changes. Anything left unassigned will be re-litigated the next time two dashboards disagree.

Your judgment call as an architect is to resist over-engineering: the most consequential conflict in a room is usually a homonym in a number leadership already reads, and the least complex artifact that resolves it is usually a controlled vocabulary with a named owner. Next you'll check that distinction quickly, then write a diagnostic pre-read that classifies real conflicts by type before anyone proposes a fix, which is the sequence that keeps a disputed term from hardening into positions.