--- title: "Two departments mean different things by customer, and every system inherits the argument" url: "https://predictes.com/services/ontology-design-and-engineering" description: "Designing and building the shared model of your business: entities, relationships and rules, agreed by the people who use them and implemented so systems can reason over it." --- # 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](https://predictes.com/contact) ## 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 - [ ### Most retrieval failures are definition failures When search returns something technically related and practically wrong, the usual response is to tune the retriever. The usual cause is elsewhere. ](https://predictes.com/blog/most-retrieval-failures-are-definition-failures) ## Other services - [ ### AI Strategy Which decisions are worth changing, what each would cost, and what would measurably be different. Including the ones where the answer is not AI. Read article](https://predictes.com/services/ai-strategy) - [ ### AI Transformation The part after the strategy: sequencing against real capacity, changing how work is done, and making adoption somebody's job rather than a hope. Read article](https://predictes.com/services/ai-transformation) - [ ### AI Agents Engineering Agents that do work rather than answer questions — with bounds, tools, approval gates and a decision log that survives the first incident. Read article](https://predictes.com/services/ai-agents-engineering)