Ontology Governance: How to Keep Change Moving After Sign-Off
Sort ontology changes by risk, give each type an owner and a review path, and record decisions so agents and teams use the current terms.
Route each change by its risk, and record the decision
- Sort changes into types: wording fixes, additions, relationship changes, and breaking changes need different reviews.
- Name one owner per domain who approves changes and answers questions about meaning.
- Deprecate instead of delete, and point old terms to their replacements.
- Record decisions as documents with links to the terms they affect. AKB can hold these records with revision history for teams and agents.
Sign-off ends the build project and starts maintenance. Terms get renamed, new products need new concepts, and two teams discover they meant different things by "active customer." Keep change moving by sorting changes by risk, giving each type an owner and review path, and recording every decision where people and agents can find it.
Why does change stall after sign-off?
The build team leaves, and every request goes to one committee. Small fixes wait as long as structural changes, so teams stop asking and create local copies of terms. Over time, reports and agents may use definitions that no longer match the approved model.
The fix is a lighter path for low-risk changes and a careful path for risky ones.
Which changes need which review?
| Change type | Example | Review | Version impact |
|---|---|---|---|
| Wording fix | Clarify the definition text of "Order" | Domain owner, if meaning and consumer behavior are unchanged | Patch |
| Addition | Add "Subscription Order" as a new term | Domain owner plus one affected consumer | Minor |
| Relationship change | Make "Refund" depend on "Payment" | Owners of both terms | Minor if backward compatible; major if breaking, with impact check |
| Breaking change | Split "Customer" into "Account" and "Contact" | Governance group, with migration plan | Major |
As a suggested team convention adapted from Semantic Versioning, use patch for wording-only fixes, minor for backward-compatible additions or relationship changes, and major for breaking changes. These labels are not an ontology standard or an automatic AKB rule; teams decide which label applies and publish the version with each release so consumers can tell whether they need to act.
Who owns what?
Give each domain one owner, such as finance for revenue terms and support for ticket categories. The owner can approve wording-only fixes when meaning and consumer behavior stay unchanged. Additions need the domain owner plus one affected consumer. Relationship changes should involve the owners of both terms.
Keep a small governance group for breaking changes and cross-domain disputes. Meet on a fixed schedule, and let everything else move through domain owners between meetings.
How do you retire a term safely?
Deleting a term can break dependent queries, dashboards, and prompts. Mark it deprecated, state the replacement, and set a proposed removal date. OWL 2 supports a deprecated annotation, and SKOS vocabularies can record the change in notes and mappings.
Before removal, review dependencies, coordinate any needed migration, and confirm with affected owners that dependent uses have been addressed. Schedule removal only after that review; use a major release when the change is breaking under your team's versioning convention.
Where should decisions live?
Every approved change needs a short record: what changed, why, who approved it, which version includes it, and which terms it affects. Teams and agents read this record when a definition looks wrong.
AKB, Dnotitia’s agent knowledge base, keeps decision documents and term definitions together in a governance vault. Use type: decision, status: active or superseded, and explicit relations such as depends_on or related_to to connect each decision to the terms it affects.
Document revision history and akb_diff show what changed. Agents use akb_search and akb_relations over MCP to retrieve the same records; domain owners maintain their approval status and version so agents can cite the applicable decision.
AKB stores and links these records; it does not run reasoning over OWL axioms. Keep formal ontology tools for that job, and use AKB to make the definitions and decisions available to people and agents.
How do you keep reviews from piling up?
- Route by type: a form or template that asks for the change type sends each request to the right reviewer.
- Automate reminders if useful: External automation can combine write events from a configured Redis stream with scheduled due-date checks to notify owners. The consumer and schedule are integrations your team supplies.
- Review the queue monthly: count open requests by type and age. A growing backlog of wording fixes means the light path is not light enough.
FAQ
Do we need a new ontology project for every change?
No. After sign-off, a domain owner can approve wording-only fixes when meaning and consumer behavior are unchanged. Additions need the domain owner plus one affected consumer; relationship changes go to both term owners. Reserve governance-group review for breaking changes.
How do agents know which definition is current?
Point them at one source of approved definitions and decision records, and include the version in their answers. With AKB, agents search the governance vault over MCP and read the record's status and history.
Learn More
See how AKB stores linked, versioned records for agents.
