Two departments mean different things by customer, and every system inherits the argument

An ontology is the least glamorous and most load-bearing thing in an AI programme. Without one, retrieval finds the wrong documents, agents make plausible decisions about the wrong entity, and every report needs a footnote explaining which definition it used. With one, a machine can reason over your business instead of pattern-matching over your text.

  • Agreed definitions. What a customer, an order, a site, a case actually is — settled between the departments that disagreed, and written down.
  • A machine-usable model. Entities, relationships, constraints and identity rules implemented rather than drawn, so systems can query and reason over it.
  • Better retrieval and better agents. Both improve immediately, because both were failing on ambiguity rather than on capability.
  • Reconciled reporting. Numbers that agree across systems because they derive from one model rather than five conventions.
Talk to us about this

What is delivered

  • Core domain model

    The twenty to fifty concepts your business actually runs on, defined precisely, with the disagreements surfaced and resolved rather than averaged.

  • Identity and resolution rules

    How the same real thing is recognised across systems. Usually the hardest and most valuable part, and the reason duplicate customers exist.

  • Relationships and constraints

    What connects to what, what is mandatory, what is impossible. Constraints are what let a machine notice something is wrong instead of proceeding confidently.

  • Implementation

    In the store that fits — relational, graph or a semantic layer over what you have — with the model expressed in a standard form rather than trapped in one product.

  • Mapping from existing systems

    How each source system maps onto the model, including where it cannot and what is lost. The honest gaps matter more than the clean mappings.

  • Governance

    Who owns each definition, how a change is proposed, and how it propagates. Without this the model is accurate for one quarter.

How it runs

  1. 01

    Find the disagreements

    Interview the departments separately and compare. The conflicts are the work; the agreed parts take an afternoon.

  2. 02

    Model narrowly

    The concepts one or two real use cases need, not the whole enterprise. Ontology projects fail by being comprehensive.

  3. 03

    Implement and load

    Real data through the model, which is where the definitions get tested and where the comfortable abstractions break.

  4. 04

    Use it for something

    Point retrieval, an agent or a report at it within weeks. A model nothing consumes is a document, and it decays.

A good fit when

  • Retrieval or agents keep returning things that are technically related and practically wrong.
  • Two systems disagree about the same number and nobody can settle it.
  • You are consolidating systems, or building anything that has to reason across them.
  • Duplicate or ambiguous master data is a recurring operational cost.

Not the right service when

  • You have one system and one definition of everything. Then this is overhead.
  • You want a complete enterprise ontology up front. That project has a well-documented failure mode and we would rather not sell it to you.
  • Nobody senior can settle a definitional dispute. Without that authority the model cannot be agreed, only described.

Frequently asked questions

Is this the same as a data model?
Related but not the same. A data model describes how data is stored; an ontology describes what things are and how they relate, independently of storage. The distinction matters because reasoning happens over meaning and queries happen over tables.
Do we need a graph database?
Often not. Plenty of ontologies are well served by a relational store with a semantic layer over it. The model should be expressed in a portable standard form; the storage is an engineering decision that follows from your volumes and your team.
How long does it take?
A useful core model for one or two use cases is typically four to eight weeks including implementation. A comprehensive enterprise ontology takes years and usually never finishes, which is why we scope narrowly and deliberately.
What if the departments will not agree?
Then the model records that there are two definitions, names them distinctly and maps between them. That is a legitimate and common outcome, and it is far better than an average nobody uses. What it does need is someone senior enough to decide which one each system means.
How does this help retrieval and agents?
Both fail mostly on ambiguity rather than capability. Given a resolved entity and its relationships, retrieval can filter to what is genuinely relevant and an agent can check a constraint before acting. It is the cheapest quality improvement available in most AI systems.

Keep reading

Other services