When sales and finance count “customers” differently, a common business vocabulary can be simpler than adopting an ontology platform. Start by agreeing on the meanings, naming the people responsible for them, and identifying the sources each team should use. Reports and AI tools then have a clearer basis for interpreting a request.
A glossary may be enough when the immediate problem is inconsistent terms. More formal modeling becomes useful when an application needs explicit relationships or logical inference. Choose the approach by the work it needs to support.
Find the disagreement before choosing a platform
Ask where people currently reconcile definitions by hand. Sales may count accounts with an active contract, while finance counts accounts with a paid invoice during a reporting period. Both measures can be useful. The problem is calling them the same thing without explaining the difference.
Other industries encounter similar questions. A manufacturer may distinguish a finished unit from a unit released for shipment. A retailer may distinguish an order received from an order fulfilled. Agreeing on those definitions is useful regardless of the database or reporting tool in use.
Start with a small set of terms involved in a recurring business problem. Compare how people use them, how systems record them, and which decisions depend on them. Buying a catalog or graph platform does not resolve those disagreements on its own.
Record enough detail to use each term
A useful vocabulary entry needs more than a label. Record the definition, its scope, the responsible business role, and the source information needed to apply it.
| Entry | What to record |
|---|---|
| Preferred term | The name people should use for this meaning |
| Definition | What it includes and excludes |
| Alternative terms | Synonyms, abbreviations, and names used by particular systems |
| Calculation or selection rule | How the measure is calculated or which records qualify |
| Source mapping | The system, field, query, or maintained dataset used to obtain the information |
| Responsibility | Who resolves a disagreement and approves a definition change |
| Version | When the definition takes effect and which reports or applications use it |
Keep distinct meanings separate. “Customer with an active contract” and “customer with a paid invoice in the reporting period” are clearer than an overloaded “active customer.” Record the reporting period and treatment of cancellations, credits, and duplicate accounts where those affect the result.
The definition does not fix a missing invoice or a duplicate account. Record data-quality problems separately and assign the work needed to resolve them.
Understand what additional structure provides
A glossary, a controlled vocabulary, and an ontology can support related needs. They are not opposing approaches or necessarily separate products.
A plain glossary describes terms for people. A controlled vocabulary can add consistent labels and relationships. The World Wide Web Consortium's Simple Knowledge Organization System primer describes preferred and alternative labels, broader and narrower concepts, and related concepts. These are useful options when terms need to be shared in a structured form.
For formal ontology modeling, the Consortium's OWL 2 overview describes a language with defined semantics for classes, properties, individuals, and data values. That structure can support software reasoning about the modeled relationships.
Neither approach has a universal implementation time or staffing requirement. A small ontology can be limited in scope, and an enterprise glossary can require considerable maintenance. Compare the actual use case, existing systems, and people available to maintain the result.
Choose the structure a use case needs
If teams need to reconcile a dashboard measure, begin with the definition, selection rules, and source mapping. Test whether the agreed entry lets both teams reproduce and explain the result.
If an application needs to infer relationships from formal definitions, assess an ontology and reasoning tools. Describe the inference it must perform and test it on representative cases. Following several relationships does not by itself require a particular graph product; relational databases and application code can also traverse relationships.
If the main need is validating whether a record has required fields or permitted values, identify that requirement directly. Data validation, terminology management, and logical inference are related tasks, but choosing one does not automatically solve the others.
The useful question is which approach supports the required behavior at an acceptable cost of implementation and maintenance.
Connect definitions to reports and AI tools
Make the approved vocabulary available where people work. A report should identify which definition and period it uses. A data transformation should implement the corresponding selection or calculation rule. When a definition changes, identify the reports, queries, and applications that need updating.
An AI tool answering a question about customers should receive the relevant definition and source mapping. If the request could refer to several meanings, it should ask which measure the user needs before producing a result.
That context can reduce ambiguity, but it does not guarantee a correct query or authorize access to data. Check generated queries and results against known cases, and enforce permissions through the connected systems. A vocabulary entry saying a source is authoritative is not permission to read every record in it.
Test and maintain the vocabulary
Use a recurring disagreement as the first test. Ask the people involved to apply the proposed definitions to the same records. Resolve differences in interpretation and update the entry before expanding its use.
Name the role that handles change requests. Review entries when the business process or source system changes, and retain the earlier definition when historical reports depend on it. A regular review can supplement those events, but the frequency should fit how often the information changes.
Expand the vocabulary when another report, workflow, or application needs it. Add formal relationships when there is a specific reason to use them. The goal is a shared meaning that people and software can apply consistently.
Explore X-Centric's AI consulting services for help connecting business definitions, source systems, and practical AI use cases.