A Shared Business Vocabulary Without a Full Ontology Project
How to establish an active business glossary and shared vocabulary across teams and AI agents using versioned, document-backed knowledge bases instead of high-overhead ontology engineering.
Key takeaways
- Start with a small set of real decisions and terms that affect them.
- Give each term a stable identifier, a clear scope, examples, an owner, evidence, and a review date.
- Keep genuinely different departmental meanings as separate scoped concepts; connect them only when reviewers agree on the relationship.
- Choose a format and tool that reviewers will maintain. A glossary, catalog, document store, or semantic model can coexist with the others.
- Provenance and revision history help people review changes; neither guarantees that a definition is correct or current.
Start with one business question that teams answer differently. A bounded vocabulary pilot can clarify the terms needed for that decision without requiring a company-wide ontology or a new platform. Treat the examples below as illustrative working material, not measured customer evidence.
Start with questions, not an enterprise model
Select one team workflow where a definition changes a report, eligibility decision, handoff, or customer-facing action. Write down the questions the pilot must answer. For example:
- Which definition should a Sales report use when it counts active customers?
- Which definition should Operations use to decide whether service is active?
- When a dashboard says “active customer,” which scope does it mean, and where is that scope recorded?
These are different questions, so they may need different concepts. A shared vocabulary is useful when it makes scope explicit—not when it forces one label to mean the same thing everywhere.
A practical term record
Use a record that makes a term understandable to a colleague who was not in the review meeting. Choose a stable ID that will not change just because its preferred label does.
| Field | What to record |
|---|---|
| Stable ID | A durable identifier, such as customer.active.sales.v1. |
| Preferred label and aliases | The label people should use, plus search terms or former labels. |
| Scoped definition | What the concept means, for which team, process, population, and decision. State exclusions. |
| Source and version | The policy, metric specification, contract, or other evidence used, with a version, date, or durable reference. |
| Owner | The person or role responsible for review and escalation. |
| Positive example and counterexample | One case included and one similar case excluded, with the reason. |
| Relationship and meaning | A named relationship to another concept, with a plain-language explanation. Do not imply equivalence unless reviewers approve it. |
| Status and review date | For example: proposed, approved, deprecated; include the next review date. |
Illustrative worked case: “active customer”
The following fictional example shows why scope belongs in the definition. It is not customer research or a claim about any organization.
ID: customer.active.sales.v1
Preferred label: Active customer — Sales
Aliases: Contracted customer; Sales active account
Scope and definition: For the Sales pipeline report, a customer is active when a contract has been signed and is in force during the reporting period. This concept answers the question “Is there a current commercial commitment?” It does not assert that service has been activated.
Source/version: Illustrative Sales metric specification, version 1.0
Owner: Sales Operations
Positive example: A customer with a signed, in-force contract is included, even if implementation has not started.
Counterexample: A prospect with an unsigned proposal is excluded.
Relationship: differs_in_scope_from customer.active.operations.v1 — both concepts use the phrase “active customer,” but answer different operational questions. This relationship does not mean equivalent to, broader than, or narrower than.
Status/review: Proposed; review with Sales and Operations before approval; next review date to be set by the pilot owner.
ID: customer.active.operations.v1
Preferred label: Active customer — Operations
Aliases: Service-active customer
Scope and definition: For the service-operations queue, a customer is active when the contracted service has been activated. This concept answers the question “Is service live?” It does not establish that a contract is currently in force unless that is checked separately.
Source/version: Illustrative service-activation procedure, version 1.0
Owner: Service Operations
Positive example: A customer whose contracted service has passed the activation step is included.
Counterexample: A customer with a signed contract whose service has not yet been activated is excluded.
Relationship: differs_in_scope_from customer.active.sales.v1 — not equivalent.
Status/review: Proposed; review with Sales and Operations before approval; next review date to be set by the pilot owner.
If a business question truly requires one combined concept, create a separately reviewed concept with explicit inclusion logic. Do not silently merge the two records or use an “exact match” relationship to hide the difference.
Run a bounded pilot and define acceptance
Choose a small set of terms and a limited set of uses—for example, a report, an operational queue, and an agent or search experience if one is in scope. Agree on the pilot questions before choosing a repository or writing definitions.
Ask the people who use the term and the people accountable for its source to review each record. Accept a term only when reviewers can answer “yes” to these checks:
- Is its intended team, process, and decision clear?
- Can reviewers distinguish it from nearby concepts using the example and counterexample?
- Is the source identifiable and current enough for this decision?
- Is the owner named, and is there a review date or trigger?
- Are relationships described in plain language and no stronger than the evidence supports?
- Can the intended consumer find the right scoped definition without guessing?
Record unresolved differences as open questions or separate concepts. Do not make “one definition for the whole company” an acceptance criterion unless the business owners explicitly decide that a common definition is needed.
Keep changes reviewable
A lightweight change process can be simple and still accountable:
- A user proposes a new term or change and names the affected decision, source, and reason.
- The term owner checks scope, examples, relationships, source version, and downstream uses with the relevant reviewers.
- The owner records the decision, status, revision history, and effective date. If meanings diverge, preserve separate scoped records and document the relationship.
- The owner tells affected users what changed and checks the term again on its review date or when its source changes.
A link to a source helps a reviewer investigate; it does not prove that the definition is correct, keep the source synchronized, or prevent drift. Verify that reviewers and consumers have appropriate access. Do not assume that permissions on linked source material automatically carry over to the glossary, or that every search index removes changed or deleted material immediately.
Choose capabilities to evaluate, not a winning category
A glossary does not have to live in Markdown or Git. Teams may use a user interface, a shared document space, a governance catalog, a repository, or more than one of these. Compare the capabilities needed for this pilot and the work required to keep them reliable.
| Option | Useful when | Capabilities to verify | Maintenance to plan for |
|---|---|---|---|
| Maintained glossary or knowledge store | A small group needs readable definitions, examples, ownership, and review history. | Stable identifiers; scoped definitions; aliases; source references; search; change history; access controls; review reminders. | Assign owners, review changes, update source references, and make approved definitions discoverable in the places people work. |
| Governance catalog | Terms must be managed alongside governed data assets or steward workflows. | Term-to-asset links; approval and ownership features; import/export; search and API or agent access; permissions; audit history. | Configure the workflow and metadata, maintain asset links, and confirm that the interface and operating model suit reviewers. |
| Formal semantic model | The use case needs machine-interpretable relationships and reasoning under explicitly chosen formal semantics. | Required inference tasks; supported OWL profile and reasoner; consistency checks; data mappings; interoperability; validation needs. | Budget for modeling, tooling, expertise, testing, and ongoing governance; measure the actual effort rather than assuming performance or low friction. |
These options are not mutually exclusive. A team might maintain human-readable term records in a catalog while using a separate semantic model for a specific integration. Evaluate actual workflows, access controls, revision behavior, search, integration, and operating effort in the intended deployment rather than inferring them from a product category.
Where OWL, SHACL, and SKOS fit
OWL 2 represents knowledge with formally defined semantics. Reasoners can derive consequences and test consistency under those semantics. OWL cardinality axioms describe logical restrictions; they are not ordinary required-field checks for a record. In particular, OWL follows an open-world assumption: information not present may simply be unknown. Use a separate mechanism when the requirement is “this field must be supplied” or “this record must meet this operational checklist.”
SHACL is a separate language for validating RDF graphs against stated conditions. It may be useful when an RDF data graph needs those checks; it does not itself establish regulatory compliance, and a glossary does not need SHACL by default.
SKOS is a model for representing and sharing concept schemes, labels, notes, and relationships. It can support a controlled vocabulary; it is not interchangeable with OWL DL reasoning. Select a standard only when its capabilities address a defined pilot need. A regulated industry, by itself, does not establish that a formal ontology is required.
Storage and agent access are implementation choices
For an agent-facing pilot, verify that the system can return the correct scoped definition, source, status, and revision context—and that access controls, update permissions, and review responsibilities work as intended. A human interface may still be the right place to author and review terms. Git, Markdown, and the Model Context Protocol (MCP) are possible implementation choices, not prerequisites for a maintained vocabulary.
For a concrete, current implementation example, the AKB public README describes a PostgreSQL-native knowledge base with document revision history, structured tables, files, explicit URI relations, hybrid semantic and keyword retrieval, and MCP access. It also says that explicit legacy Bare Git deployments remain supported. The README distinguishes the core read/write store from optional plugins that add agent workflows. This product description does not establish business-vocabulary validation, automatic enterprise lineage, automatic source-permission inheritance, or a required architecture for every glossary. Check the current deployment documentation and test the capabilities relevant to your own pilot.
FAQ
Do we need one company-wide definition for every shared term?
No. Use one definition where teams make the same decision using the same scope. Where questions differ, preserve scoped concepts and document their relationship instead of forcing equivalence.
What should count as a successful pilot?
Agree on acceptance before starting: reviewers can distinguish each term from nearby concepts, trace its source and owner, resolve who approves changes, and find the correct scoped definition in the selected workflow. Track unresolved questions rather than treating them as failures to unify terminology.
Does OWL or a regulated environment mean we need a formal ontology?
Not automatically. Start from the required decisions and controls. Consider OWL when formally defined relationships and inference are needed; consider SHACL when validating RDF graphs against conditions is needed. Neither replaces a business decision about term scope or proves compliance on its own.
Does a source link guarantee a current, correct definition?
No. A source link and revision history help people review a definition, but an owner still needs to confirm the meaning, update it when sources change, and check that the intended users can access it.
Must a shared glossary use Markdown, Git, or MCP?
No. Choose the authoring and access methods that pilot reviewers can maintain. Evaluate interfaces, permissions, revision history, search, integrations, and support for agents where those capabilities are needed.
Start with a bounded vocabulary pilot
Choose one decision, document the terms behind it, and agree on owners and review criteria before selecting a platform.