An ontology, the formal model of your business and its rules, is what lets AI follow your rules instead of guessing at them. (If the term is new, start with Ontologies and Semantic Layers, Explained Without the Jargon.) Two questions follow quickly once one is in place: how do we keep it accurate as the business changes? and how do we know it's paying for itself? This article answers both in plain terms.

What is ontology drift?

Your business doesn't stand still. Regulations are updated, approval limits change, new products and suppliers arrive, teams are reorganised, and a field in the ERP quietly starts being used for something new.

Ontology drift is the gap that opens up when the business changes but its model doesn't. The rules your AI enforces slowly stop matching the rules your business actually runs on.

It's the same thing that happens to any rulebook nobody maintains, with one difference: an AI applies its rules consistently, every time. That consistency is the point. But it also means an out-of-date rule is applied consistently too.

What drift looks like in practice

Drift rarely announces itself. It shows up as small frustrations:

  • Valid work gets blocked. A supplier was re-approved last month, but the model still treats them as unapproved, so orders stall.
  • Invalid work gets through. A new regulation added a requirement the model doesn't know about yet.
  • Overrides creep up. People start clicking "approve anyway" because "the system is always wrong about this one".
  • Data stops fitting. New product types or codes appear that the model has no place for.

The last two matter most. When people routinely work around the system, trust erodes, and the value of the whole investment drains away quietly.

How unmanaged drift erodes trust: the business changes, the model goes out of date, wrong decisions lead to overrides, and trust and value fall

How to keep drift under control

The good news is that drift is easy to manage once you expect it. Four habits do most of the work:

  1. Give every area of rules an owner. Procurement rules belong to procurement, safety rules to HSE. The owner approves changes, just as they would for a written policy.
  2. Treat changes like policy changes. The model is version-controlled: every change is recorded, reviewed and can be rolled back. You always know which version of a rule made a decision.
  3. Watch the warning signs. Track how often outputs are blocked, how often people override them, and how much incoming data doesn't fit the model. A rising number points straight at the rule that needs attention.
  4. Review on a calendar. Tie reviews to events you already know about: regulatory updates, contract renewals, annual policy reviews.

Here's the part that makes this cheaper than it sounds: a rule only needs updating once. Change it in the ontology and every AI system that uses it follows the new version immediately, with no retraining and no rewriting prompts in a dozen places.

Managing drift as a loop: monitor blocks, overrides and unmatched data; the rule owner reviews; update the rule once; every Digital Expert follows the new version

Is it worth it? A simple way to think about ROI

Return on investment for rule-based AI comes from a handful of sources. You don't need a complex model to estimate it, just honest numbers for the process you start with:

  • Time saved on manual checking. How many hours a month does your team spend checking orders, documents or reports against the rules?
  • Errors avoided. What does one compliance breach, wrong order or rework cycle cost you, and how many happen a year today?
  • Faster decisions. How long do approvals wait, and what does that delay cost?
  • Cheaper audits. How long does it take to assemble evidence when an auditor asks? With a decision record kept automatically, much of that work disappears.

An illustrative calculation (made-up numbers; use your own): a team checks 2,000 purchase orders a month at about 6 minutes each, which is 200 hours a month. If a Digital Expert handles the routine checks and people only review the exceptions, most of those hours go back to higher-value work. Add even one avoided compliance incident a year, and the business case usually becomes clear quickly.

The part most ROI estimates miss: reuse

The first project carries the cost of building the model. The second doesn't start from zero: a new Digital Expert in another process reuses the suppliers, contracts, approval chains and rules that already exist. Each new use case costs less and inherits the same governance, so value compounds instead of resetting with every project.

One shared ontology reused by several Digital Experts: procurement compliance, regulatory reporting and maintenance approvals

Drift and ROI are linked. Unmanaged drift erodes the return; managed drift protects it.

Where to start

Measure before you build. Pick one process, write down today's numbers (hours spent, error rates, approval times) and use them as your baseline. That's exactly how the Archisus engagement is structured: the two-week Business DNA Audit maps the rules and ranks pilot use cases by estimated ROI, and a 4–6 week pilot then measures the before and after on real data. You can see the numbers before committing to more.

Key takeaways

  • Ontology drift is the gap between how your business works and the rules your AI enforces.
  • Watch for rising overrides, blocked valid work and data that doesn't fit: they point to the rules that need updating.
  • Give each rule area an owner, version every change and review on a calendar; a rule changed once updates every AI that uses it.
  • ROI comes from time saved, errors avoided, faster decisions and cheaper audits, and it grows as each new use case reuses the same model.