Ontology
An ontology writes how your company decides into the system
The factory counts stock in quantities; accounting records it in money. It is the same material, yet inside the two systems the two are strangers. An ontology is the work of tying them together as one and the same, so that when someone asks why material costs rose, the system can answer.
An ontology is not an IT department’s project. It is management putting “this is how we decide” on record in the system.
Why the perfect system went unused
Plenty of companies build a system that captures every item, order and sale — and still stall at “why is revenue falling?”. The design started from data fields, not from the questions of the floor.
Start from data fields
- Items — all captured
- Orders — all captured
- Sales — all captured
- Equipment history · shifts · weather — not in the design
“Why is revenue falling?”
The system stops here
Start from the floor’s questions
“Why do defects rise at month-end on this line?”
Line supervisor“Why does yield drop in the rainy season?”
Quality managerThe system starts pointing at the real problem
This is why a DARVIS build starts with interviews on the floor before it connects any data.
An ontology designed without the people who know the floor best is the first one to be abandoned.
Common misreadings, and the redefinitions
| The common view | The redefinition |
|---|---|
| A technology for integrating data | A structure that fixes how an organisation thinks |
| A technology for collecting more | A technology for deciding first |
| A document, a deliverable | The result of an agreement |
| A store of knowledge | A digital twin of reality |
| A data model | The constitution for the AI agents to come |
Don’t build the dam — connect the relationships first
Start with company-wide data integration and it usually stalls. The book’s recommended starting points are five relationships, and most companies begin at ①.
①Customer → behaviour → revenue
Marketing gets judged on contribution to revenue rather than volume of activity. Sales reporting shifts from describing results to analysing how conversion works.
②Event → cost
Accounting records the outcome but doesn’t explain the cause. Separate immediate from deferred cost, and direct from opportunity cost, and cost management moves from after-the-fact reporting to judgement made in advance.
③Decision → assumption → outcome
The most important relationship, and the one that most often disappears. Store why a decision was made as an object, and the system becomes the organisation’s memory.
④Risk → probability → loss
One department sees risk as likelihood, another as cost. Structure it as probability and impact and risk management becomes arithmetic rather than instinct.
⑤Current state → trend → future outcome
Where time-series data meets the ontology — equipment condition and failure probability, stock level and the odds of missing a delivery date.
An intelligent company is not the one with the most data — it is the one that fixed its most important relationship first.
Which side is your company on — a 14-question self-check
Across seven areas, pick whichever sounds more like your company. The result appears right here, and we never ask for your contact details.
01Spotting a problem
02Spotting a problem
03Data and reporting
04Data and reporting
05Executive meetings
06Executive meetings
07Root-cause analysis
08Root-cause analysis
09AI and systems
10AI and systems
11Crisis response and organisational learning
12Crisis response and organisational learning
13How it feels as CEO
14How it feels as CEO
Five beliefs that keep you from starting
The fifth is the most dangerous — it is the one that delays starting the longest.
- “It’s an IT project”It’s a question of how the organisation thinks
- “We don’t have enough data”What’s missing is the connections
- “The ROI isn’t clear”Removing risk is the ROI
- “It’s too complex for the people doing the work”It is nothing more than structuring the words those people already use
- “It can wait”The gap compounds
The book answers the ROI objection like this: “The return on an ontology is proved not by what you earn, but by what you don’t lose.” The first number to move is investigation time — finding one cause used to take weeks; once the relationships are fixed, it is a query of minutes.
So where do you start — three rules for doing it
Fix one question at a time
What is the question your company asks over and over, every day?
Structure the judgement before the data
The numbers can be attached later.
Put the thing you argue about in meetings into the system first
The noisiest topic is the most valuable relationship.
This is what a fixed relationship looks like on screen
Everything above is the concept; below is what the concept becomes inside a tool. Click an entity and its attributes, its relations and the rules that read it as a condition all change together. The rules moving in the same place is what it means for an ontology to run as a system rather than sit in a document.
Click a node and only its direct relations stay lit — you can see how evidence, counter-evidence, rules and review hang off a single assertion.
Pinch to zoom, drag to move.
An example model for a fictional manufacturer. In a real build, both the entities and the rules follow from the question your company asks every day.
Curation and validation
Sources are mapped to the core, and the loss is verified
Terms that ERP, MES and documents each call something different are brought onto one core. Every mapping keeps its method, loss rate and approval state, and nothing enters the model without passing the gates.
What to read first, and what to do next
That is the concept. What to prepare and in what order, when you apply it to a real company, is set out in the kickoff guide. Leave a few details and it opens right away.
DARVIS is that relationship structure applied to cost and margin questions on a factory floor.See how the ontology gets built automatically →