How to Build an Enterprise Ontology in 6 Steps Without Modeling the Whole Company

The problemYou know you need an ontology, but every attempt ends in a giant diagram nobody uses.

The project kicked off with plenty of enthusiasm. Six months later, the data team has a diagram with hundreds of boxes covering an entire wall, and nobody on the business side has ever opened it. The AI agents still don't know what an active customer is. That is the most common way to fail when you try to build an enterprise ontology: you start by modeling everything instead of starting with what the business needs to know.

There is a method that avoids this mistake, and it isn't new. Academics have used it since the 1990s, and it works just as well in a company running an ERP, a CRM and AI agents.

The principle: start with questions, not tables

In 1995, Michael Grüninger and Mark Fox proposed starting ontology design with competency questions: the things the model must be able to answer. Years later, Natalya Noy and Deborah McGuinness at Stanford turned that idea into a practical guide that is still the standard reference ("Ontology Development 101", 2001).

The idea is simple and powerful. The questions define the scope: anything that doesn't help answer a question stays out. And the same questions become the test at the end: if one can't be answered, the model is missing something.

Step 1. Write down the competency questions

Get the owners of the process you want to tackle first in a room and ask them for the questions they struggle to answer today. Write them down exactly as they say them. Illustrative example for collections:

• Which customers have overdue invoices and open orders at the same time?
• Why is this customer's order on hold?
• Who can approve a credit exception, and up to what amount?
• Which customers are repeat late payers?

Prioritize. For a first version, a handful of well-chosen questions beats a hundred generic ones. Choose the ones that, once answered, save real work or prevent expensive mistakes.

Step 2. Extract the vocabulary and agree on definitions

Underline the nouns and verbs in each question: customer, invoice, overdue, order, open, approve, exception. That is your starting list of terms.

For each term, agree on a written definition and an owner. This is where the usual disagreements surface: is an invoice overdue the day after its due date, or only after a grace period? Settling that now is half the value of the project, even before a single agent exists.

Step 3. Model objects, relationships, rules and actions

Turn the vocabulary into a model. Nouns usually become objects or properties; verbs become relationships or actions. A simple template is enough for the first version:

Reuse before you invent. For generic concepts like people, organizations or addresses, public vocabularies such as schema.org already exist and will save you a lot of debate.

Step 4. Map each object to its systems

The ontology doesn't move data: it points to it. For every object and property, note which system it comes from and which key identifies it:

The shared key is the heart of the mapping. Without it, your CRM and your ERP keep talking about different customers. If your data has no reliable key, that is the first job, and we explain it in AI-ready data.

Step 5. Validate against the questions from Step 1

Take each competency question and answer it with a real query against the ontology connected to your data. Mark each one as passed or pending. The pending ones tell you exactly what is missing: an object, a relationship, a key or a rule.

Have the business review the answers, not just confirm that the query runs. An answer that is technically correct but built on the wrong definition is the most expensive mistake of all.

Step 6. Govern the model and let it grow

An ontology that never changes goes stale within months. At a minimum, it needs three things:

• Owners for each concept, who approve changes to its definition.
• Versioning, so you know what changed, when and why, and which agents depend on which version.
• A review cycle, where new business questions restart the method from Step 1.

This governance is part of data governance for AI, not a separate process.

Illustrative example: the first version in collections

Picture a distributor that wants a collections agent. This is an illustrative example, not a real client.

Week 1. Two sessions with Finance and Sales produce eight competency questions. Five make the cut. The first disagreement shows up right away: Sales considers an invoice overdue at 30 days; Finance, the day after its due date. The team adopts Finance's definition and adds a "days past due" property.

Weeks 2 and 3. The team models six objects, eight relationships, three rules and four actions. The mapping reveals that the CRM doesn't store the tax ID for every customer, so that gets fixed before moving on.

Week 4. Four of the five questions are answered with real queries. The fifth, "Which customers are repeat late payers?", needs payment history that isn't in the ERP today. It stays pending for the next version.

The result isn't a wall-sized diagram. It is a small model, signed off by the business, that an agent can already use.

Common mistakes when you build an enterprise ontology

• Modeling the whole company before delivering anything. Start with one process and grow question by question.
• Skipping definitions because "everyone knows what a customer is." That is exactly where the disagreements hide.
• Leaving out actions. Without actions and permissions, the ontology can't govern agents.
• Not testing with real questions. A model nobody validates against real queries is just a drawing.
• Trusting AI to generate the ontology on its own. Models can help propose terms and relationships, but definitions are business decisions that someone has to approve.

What to do on Monday

Book a one-hour session with the owners of one process and pull their competency questions out of it. Prioritize the five most valuable and extract their vocabulary. That gives you the scope of your first ontology, and you can see what your agents will use it for in ontology for AI agents.

At Addabra, we build enterprise ontologies with this method: we facilitate the sessions with your teams, build the model, map it to your systems and validate it with your own questions, then leave the ontology connected to your company brain and your agents. See how in our company brain development service.

ontologymethoddatacompany brain