Scoping a Small Shared-Vocabulary Pilot
Define a defensible first business vocabulary pilot across cross-team interfaces, using a term selection worksheet, clear acceptance criteria, and versioned markdown storage to prevent project stall.
A shared vocabulary project becomes difficult when it tries to settle every department's terminology at once. A smaller pilot asks a more practical question: can two teams describe one workflow consistently enough to reduce mistakes at their handoff? This guide provides a worksheet, a sample dispute, and acceptance checks for that first increment.
Key takeaways
- Start with one handoff: Choose a recurring decision where two teams misunderstand the same terms.
- Keep definitions accountable: Record the term, its source, its owner, and an example of how it should be used.
- Test usefulness before expanding: Check whether people and agents can distinguish the meanings in real questions.
- Separate storage from reasoning: Versioned records and explicit relations can support a vocabulary pilot without providing a formal ontology reasoner.
Choose a boundary with an observable problem
Pick one workflow, such as sales handing an account to implementation or engineering classifying a support incident. Identify examples where the same word produced a different action. A disagreement about an “active customer” is useful if it changes an onboarding task; a list of fashionable data terms is less useful without a decision attached.
Write down the teams involved, the decisions in scope, and the systems that currently define the terms. Agree on a review owner in each team. Keep unrelated terminology in a backlog so the pilot does not turn into a company-wide governance redesign.
A lightweight model can preserve local definitions. The W3C SKOS Primer describes concepts with identifiers, labels, notes, and relations, including mappings between vocabularies. That is a useful reference when you need interoperable terminology. A first worksheet does not have to implement RDF or claim SKOS compliance to benefit from clearly separating a concept from its labels.
Use a worksheet that exposes disagreements
The following is an illustrative pilot worksheet, not a mandatory standard, an AKB schema, or a formal SKOS implementation.
| Field | What to record | Review question |
|---|---|---|
| Stable concept ID | A persistent key for the concept within the pilot | Will a renamed label or alias still map unambiguously to this exact concept? |
| Preferred label and aliases | Common wording, acronyms, and spelling variants; note language or domain if relevant | Could one label or alias refer to distinct concepts in different contexts? |
| Definition and scope | What the concept includes and excludes | Can both teams apply this scope consistently to the same positive/negative examples? |
| Source | Source ID, system/policy record, source revision, and effective date | Which source revision governs if underlying documents or policies conflict? |
| Owner | The person or team responsible for changes and approval | Who can resolve an open dispute or authorize a concept change? |
| Related terms | Explicit connections and relation types (e.g. associative vs. mapping) | Is this relation an exact equivalence or merely a useful domain association? |
| Status and revision | Proposed, agreed, or deprecated; version identifier and policy mapping | Which definition revision is active today, and what handles historical deprecations? |
For each candidate concept, collect one positive example and one counterexample. This often reveals ambiguity faster than expanding the textual definition. When a concept undergoes a major semantic change, split, or merge, do not simply rename labels under the existing ID; apply an explicit versioning and mapping policy that creates distinct concept IDs or versioned records as needed.
Work through one conflicting term
Consider this illustrative case: Sales calls an account “active” after a contract is signed, Operations considers an account “active” only after service activation, and Finance requires explicit authorization before billing. Contract signature, service activation, and billing readiness are distinct business conditions with different governing sources.
Keep distinct, scoped concepts such as sales-active-account and service-active-account. Record the source ID, source revision, and owner for each. Link them as related concepts to describe the transition lifecycle, but do not mark them as equivalent unless both teams formally establish that their operational conditions coincide. A label match or a general relation link alone must not authorize billing or infer that onboarding is complete; systems and agents must identify the governing source authority and ask for missing contextual evidence when preconditions are unverified.
The SKOS Reference distinguishes associative relations from mapping properties like exact matches. Even when adopting formal representations, treat exact mappings with care, as an exact vocabulary mapping does not guarantee complete equivalence across all business rules and downstream permissions.
Give definitions a controlled update path
Use a small sequence: propose a change, review its meaning, accept it, and test the affected questions again. A change record should include its reason, source ID/revision, reviewer, and prior definition. If a term or concept is deprecated, retain a way to explain older records and direct new workflows to its replacement.
Establish explicit access and approval boundaries during review. Vocabulary entries, alias definitions, and synthesized concepts must not broaden the audience of restricted source evidence; review access permissions for synthesized outputs and summaries just as carefully as for underlying source links. Note also that version history alone is not automatically a full approval and access audit log, as administrative updates or storage changes may exist outside governance sign-offs. Historical definitions remain available only under an explicit retention and backups policy, and access to historical evidence still requires current authorization.
Storage can support this process without making semantic decisions. Dnotitia's Agent Knowledge Base (AKB) provides versioned knowledge and agent access through MCP, with documents, structured records, explicit relations, and retrieval. A team can use these building blocks for vocabulary records and their source context. Choosing definitions, approving mappings, and enforcing a review process remain responsibilities of the team and its configured workflow. AKB should not be described as automatically resolving enterprise terminology or providing a formal ontology reasoner.
When several agents or people can edit records, test concurrent changes and the supported revision checks. Also test what happens when a source is withdrawn or access is revoked.
Decide whether the pilot is ready to expand
Set acceptance criteria before running the evaluation. The following illustrative evidence table outlines proposed test scenarios for evaluating pilot readiness. These are proposed test cases for the evaluation framework, not measured benchmark results from a completed deployment.
| Scenario / Test question | Expected concept / action | Required evidence | Observed result | Reviewer |
|---|---|---|---|---|
| Ambiguous alias query ("Is account active?") | Prompts the user to clarify whether sales or service status is meant | Prompt for scope clarification and candidate concept IDs | To be recorded | Suggested role: Operations Lead |
| Dual definition resolution ("Has service been activated?") | Resolves to service-active-account | Cites service-active-account definition (<source ID> / <source revision>) plus account-status evidence | To be recorded | Suggested role: Implementation Manager |
| Deprecated definition lookup ("Legacy active rule") | Uses effective historical version for past records; points new queries to active concept | Effective version date and deprecation notice mapping | To be recorded | Suggested role: Data Governance Reviewer |
| Restricted source reference ("Special terms") | Abstains from disclosing restricted source content to unauthorized roles | Access check verification; redacts or restricts source output | To be recorded | Suggested role: Security / Compliance Lead |
| Unresolved dispute ("Unmapped custom term") | Escalates to designated review owner or abstains rather than guessing | Audit log entry with escalation trigger and missing source flag | To be recorded | Suggested role: Pilot Owner |
Evaluate performance across two separate test sets: a frozen regression set of known past handoff queries and a small held-out set of fresh paraphrases and edge cases. To avoid misleading accuracy claims based solely on tuned examples, report evaluation outcomes with explicit denominators, separating correct answers, ambiguous responses, missing sources, and unresolved disputes.
In addition to semantic accuracy, track practical business and maintenance measures relevant to the handoff, such as time spent resolving cross-team interface disputes and curation maintenance hours per term. Avoid publishing invented numeric target percentages or arbitrary ROI claims without baseline operational data.
Expand only when the pilot demonstrates measurable improvement on the target handoff with a manageable maintenance effort. Add the next adjacent workflow rather than attempting to import an enterprise catalog all at once.
Frequently asked questions
Do we need a formal ontology to start?
No. A bounded glossary with identifiers, sources, examples, and accountable owners can be a useful first step. More formal modeling becomes relevant when the use case requires machine-checkable semantics or inference beyond stored relations.
Should we force every department to use the same label?
Not necessarily. Keep local labels when they help the teams work, and document how their concepts relate. A shared word should not conceal different meanings.
Can AI approve new definitions automatically?
An agent can help find candidates or propose changes. Whether it may approve them is a governance decision. During a pilot, review consequential definitions and mappings before downstream workflows rely on them.
Explore AKB
Review the documented knowledge records, relations, and agent tools.
