How to Keep an Ontology Current as the Business Changes

An ontology is most accurate the day it ships. Everything after that is the business moving while the model stands still. Knowing how to keep an ontology current as the business changes is an operating problem, and it is the half of the work that almost nobody budgets for.

The decay itself is the one point on which nobody disagrees. Over the past year, vendors selling graph databases, lakehouses, data catalogs, semantic layers and cloud data platforms have each published some version of it, unprompted and in their own words. Models perpetually lag the domains they describe. By the time every term and rule is modelled, much of the model is already stale. A static ontology is the wrong implementation. Most organizations lack the staffing to maintain a formal model in perpetuity. One consultancy puts it best. Construction is a one-time event. Reconciliation is continuous.

So the problem is settled. What to do about it is not.

What has automation solved, and what has it not?

The strongest version of the opposing argument deserves stating properly, because it is a good argument and it is not going away. It runs like this. Maintenance was always the hard part. Deferred reward is why any hand-maintained model decays. Wherever a person is the one keeping a model current, that is where the decay starts. What has changed is that an agent can now do the upkeep. The payoff has arrived.

Grant all of it. The automation works, the products shipped, and detection genuinely is something machines do better than people. Pretending otherwise would be both wrong and easy to disprove.

Then ask the question it does not answer. On the day the definition of "active customer" shifted because the underlying query patterns shifted, who decided that, and where is it recorded?

Continuous automatic refresh is not a governance mechanism. It is the absence of one: a system designed to change a definition without anyone being asked. That is exactly right for a search index, where the cost of a slightly wrong answer is a slightly worse result. It is exactly wrong for a number that goes to a regulator, a board or a patient.

Change without a decision is not maintenance. It is drift with a scheduler.

Note what happens when a vendor frames its model as something other than a second system of record you have to maintain. If it is not a system of record, it cannot be the record of what was agreed. Those are the same sentence read twice.

One sequence is worth reporting without comment. In September 2026 a platform vendor published a definitional piece arguing that building a formal ontology from scratch is unnecessary. Requiring it would recreate the scalability problem the tooling exists to solve. Seven days later the same vendor published that some concepts are too important to leave to inference. When "completed trip" or "active customer" has to be exactly right, your own experts should define it once, somewhere every person and every agent can rely on.

That is not a gotcha and the second position is a reasonable one. It is the more interesting thing: the automation camp arrives at the human-authority answer on its own, under load.

What is worth conceding about ontology maintenance?

Ontologies do go stale. Not "can". Organizations invest heavily in creating them and almost nothing in operating them, and the operations half is where the value either survives or does not.

Changing one in production hurts. Queries fail. Dashboards return different numbers and nobody can say which run was right. The rational response to that pain is to freeze definitions, which is how a model becomes documentation.

The sync problem is real, and it is a fair hit on the architecture. If the agreed model lives in a store separate from the warehouse, nothing native connects it to a schema migration that happened upstream an hour ago. That gap is genuine and worth naming. Nobody should pretend otherwise. The answer is that automatic propagation of an upstream schema change into an agreed definition is a bug. It is not a feature. An owner and a review trail are what let you decide whether it should propagate at all, and that decision is the thing you wanted a model for.

The automation vendors hedge too, and at least one requires human review by design. Their own documentation says extraction publishes nothing on its own. Any rebuttal that paints them as fully autonomous is a misquote, and hands them an easy correction.

How do you keep an ontology current? Six steps

1. Separate the volatile from the stable. Nothing should be reviewed on a single cadence. Classify each part of the model by how fast it changes, and by what it costs to be wrong about it. Those are different axes. Neither of them is "which domain does this belong to." A product hierarchy that changes quarterly and a revenue-recognition rule that changes when the auditors say so do not belong on the same review schedule.

2. Instrument change detection at the source. Schema changes, new reference values, systems coming online, unfamiliar terms appearing in queries. This is the part automation does better than people, it is cheap, and there is no reason to do it by hand. Take the help.

3. Route every detected change to one of three outcomes: apply automatically, propose for review, or block. This is the step that matters. Deciding which classes of change are allowed to apply without a human is the actual governance act, and it is done once per class of change, never once per change. A new value in a controlled list may well apply itself. A change to what counts as an active customer does not. The same three-outcome decision appears in SHACL validation, and it is worth framing identically in both places so a team decides it once.

4. Give every contested definition a named owner. A person. A team cannot be asked why. The review trail behind that owner records four things: what changed, who approved it, what it replaced, and when. A trail missing any one of those will not settle the argument it exists to settle.

5. Set expiry. A definition with no review date is a definition nobody will revisit. This is the step no automated approach can take. The reason is structural. Expiry is a judgement about whether something still matters, and no such signal exists in the data. Nothing in your query logs says this definition has outlived its usefulness.

6. Track what downstream is still pinned to the old version. A definition change nobody downstream notices is the silent-failure case, and it is the one that surfaces as an argument in a board meeting six weeks later.

Which practices actually prevent drift?

The three-outcome decision in step 3 is where most of this lives, so it is worth being concrete about which changes belong in which lane.

Four practices behind that table

• Staleness is a governance problem. Refresh frequency is not the lever. Running detection more often does not help if nothing routes the result to a person who can decide.
• Measure the review trail. The model's size tells you nothing. A small model where every contested definition has an owner and a date beats a large one where none do.
• Inference detects. People commit. Machines propose, named humans dispose, and the disposal is recorded. That is what agreement means operationally. AI can propose definitions, relationships and rules. None of it becomes ground truth until the people accountable for it agree.
• Start from the arguments. A term that has caused two meetings this year is worth an hour of somebody's authority, and will do more than another pass of completeness. The same principle governs how to scope an ontology so it ships.

Open standards matter to all of this for a practical reason. A model expressed in RDF, OWL, SKOS and SHACL carries its constraints and its review trail in a form that outlives the tool it was authored in. The governance then survives a platform change. That is the difference between a governed asset and a well-maintained file. TopQuadrant's ontology platform exists to run that loop.

Which failures stay silent until they are expensive?

The dangerous failure is silent. Pipelines keep running successfully, so nothing alerts. The problem only surfaces when downstream systems start producing results somebody recognises as wrong. Schema drift breaks a pipeline loudly when downstream code is fragile, and quietly when it is permissive. The quiet case is worse. Consumers do not get an error. They get subtly wrong data and act on it.

Append-only stores never expire anything. A plain vector store has no notion of "this was true then, and is not now." Three related anti-patterns travel together. Append-only memory. No temporal validity. Updating without superseding, which leaves the new value and the old one both retrievable and both apparently valid. The adjacent problem is provenance, and it is just as structural. Major vector-store products provide no native way to verify where a stored embedding came from. A 2026 paper on embedding-store provenance sets out to close that gap by cryptographic means. Neither of these is something one vendor forgot to build.

Do not mistake this for an argument against automation. It is good, it works, and the sensible thing is to use it for everything it is good at. What automation changed is who does the work. What it did not change is who is accountable for the answer, and in an enterprise the problems that actually cost money are accountability problems.

An ontology that stays current is not one that updates itself. It is one where somebody is answerable for each definition in it, and where you can find out who, and when, and what they changed. That is what ontology management is for.

So what should I take away?

Automation can detect every change in my estate and draft the update. It cannot decide whether the definition should move. The work moved. The accountability did not.

So the question to ask of any tool here is narrow. Does it route a detected change to a named person, and does it keep the record of what they decided? TopQuadrant builds the loop around that answer, in standards that outlive whatever detected the change.