An ontology needs a decision-maker more than a modeller

An ontology project has two parts. The first can be contracted out: interviews with departments, modelling, implementation, mapping the existing systems. The second cannot be handed to anyone outside: deciding what a “customer”, an “order” or an “active contract” means in this company when two departments have different answers and both are justified.

When a project like this drags on, technical difficulty is rarely the reason. More often a dispute has landed with somebody who has no authority to settle it, and it has been circulating between meetings for weeks.

Why the modeller cannot do it

Every definition has an interest behind it. Sales counts a customer from contract signature, finance from the first invoice, service from the first ticket. Each version is correct in its context, and each department has results that depend on it.

An average serves nobody. A compromise definition that no department uses is the worst possible outcome: a model consistent with everybody and useful to nobody.

The technical team has no mandate. It can prepare the options and describe their consequences. If it chooses on its own, though, one of the departments will treat the model as an IT invention and carry on counting its own way — and the model becomes one more convention alongside the rest.

What settling it looks like

Often it does not mean choosing a single definition. Recording both, naming them distinctly and mapping between them is a legitimate and common outcome. The decision needed is narrower: which version each system and each report means.

Infographic

How a contested definition gets settled

1. 01Surface the disputeInterview departments separately, then lay the definitions side by side.
2. 02Name both versionsTwo definitions get distinct names instead of one averaged one.
3. 03Assign to systemsThe decision-maker settles which version each system and report means.
4. 04Name an ownerSomebody is accountable for the definition and takes change requests.
5. 05Test on real dataReal records run through the model show whether the decision holds.

What happens when nobody decides

The project rarely stops altogether. It usually carries on, only worse, and nobody notices the moment it stopped solving the problem it was started for.

The model adopts one department’s definition. Whichever was most available to the technical team, or argued loudest. The other departments find out at the first report that does not match theirs.

The spreadsheets come back. The department whose definition lost without a decision keeps its own figures alongside the system. A year later there are two sources of truth, and only one of them cost a project budget.

AI systems inherit the dispute. Retrieval and agents run on a model that quietly assumes one definition. The answers are consistent and convincing — and wrong for half the people asking.

What it costs in your time

Less than you fear, and more than you usually plan for.

Interviews. An hour or two with each department, separately. A joint workshop produces an agreement nobody intends to follow; the disputes come out in one-to-one conversations.

Decisions. The agreed parts of the model take an afternoon. The disputes that genuinely matter are usually a handful, not dozens. Each needs a short meeting at which the options and their consequences are already on the table.

Governance after the project. Each definition gets an owner who receives change requests. Without that, the model is accurate for one quarter and then drifts away from reality again.

Who should decide

Not necessarily the most senior person in the company. Somebody with authority over both departments in the dispute, or a written mandate to decide on their behalf — and who understands that “it depends” is a decision to postpone the project.

A good decision-maker does not need to understand modelling. They need to understand consequences: what changes in the sales reports if a customer is counted from the first invoice, and who loses by it. The project team prepares those consequences; the decision is theirs.

Signs you have chosen the wrong person: decisions are reopened at the next meeting, every dispute ends with a request for “one more round of consultation”, and departments stop attending because nothing is ever settled anyway.

If nobody in the company has that authority, it is worth saying so at the start. The model can then be described but not agreed, and it is better to know that before signing a contract than after.

One conversation before you start

Before you sign an ontology project, name the person who will settle disputes, and ask them whether they agree to do it and how much time they can give it. That conversation predicts the outcome better than any technical assessment.

In ontology design and engineering that question comes before the first departmental interview — because the conflicts are the work, and without somebody to settle them all that is left is a careful description of them.