A warehouse stores rows.
An ontology knows things.
Nine systems each held a true fragment of the same company and none of them could see each other. An ontology is not a nicer schema - it is a typed model of the real world where objects carry links you can traverse, where a PDF clause and a maintenance note become queryable relationships, and where the answer to a question writes back to the system that has to act on it. This report shows the mechanics, not the marketing.
Scattered truth
One supplier. Eight systems. Eight different primary keys, none of which agree - and two of the richest sources aren't tables at all, they're documents nobody can query.
Every system is internally correct. The failure is in the space between them - nobody owns the relationships, so the relationships don't exist. An ontology's job is to make those relationships first-class, typed, and permanent.
Objects & links
Seventeen object types, twenty-four typed links. A warehouse would call these foreign keys and make you write the join. Here the link is the model: named, directional, cardinality-aware, and traversable from either end. Click any object - orange properties are ones derived from unstructured sources.
Enterprise ontology · 17 object types, 24 typed links
Click or tab to an object to trace its linksSite is the hub: 6 of the 24 links touch it. Orange properties in the panel below are derived from unstructured sources. Synthetic demo data; object counts are illustrative.
Every object is one real-world thing, assembled from every system that knows about it.
Data table
| Object | Link | Linked object | Cardinality |
|---|
| Object type | Domain | Instances | Links |
|---|
Unstructured → links
This is the part people mean when they say an ontology is different. A contract PDF, an incident narrative, a call report - prose that no query could reach. Extraction pulls entities, resolution matches them to objects that already exist, and what lands is not text: it is links. Pick a document and run it.
The Gensuite incident narrative and the SAP work-order note are written by different people, in different systems, in different languages of practice. Both mention pump P-4471. Once both resolve to the same Equipment object, "seal weep observed on rounds" and "third seal failure this year" become one story about one pump - and that story was previously unreachable by any query in the company.
Entity resolution
Extraction is easy. Deciding that two records are the same thing in the world is the hard part, and it is evidence, not magic. Toggle the signals to see the confidence recompute and the decision flip.
All six records collapse into one Supplier object. Every contract, PO, invoice, and incident attached to any of them now hangs off a single node.
Traversal
With links in place, questions stop being projects. Each path below crosses systems that have never spoken to each other - and two of them traverse links that only exist because a document was read.
-
Actions & the twin
An ontology that can only be read is a very expensive report. Actions write back - permissioned, validated, audited, and recorded as objects themselves, so the decision becomes part of the model. And once the model is complete enough, you can ask it what happens next.
Action plan
Ontology programmes fail by starting with the model instead of a question. Pick one decision that hurts, build only the objects it needs, then let the graph accrete.
Impact vs effort · six plays, each scored 1 to 5
Synthetic scoring for illustration. I = impact, E = effort.
Data table
| Play | Quarter | Impact | Effort |
|---|
O1 → O2 → O3 → O4 → O5 → O6
- RPT-001D365 Data StrategyRaw objects to revenue moves · Synthetic demo data
- RPT-002EHS Metrics CommandLeading signal over lagging autopsy · Synthetic demo data
- RPT-003Value-Chain TwinOntology, links and unstructured data · Synthetic demo data
- RPT-004Verifiable AnswersArchitecture for AI you can sign off · Synthetic demo data
- RPT-005EHS BenchmarksReal OSHA data, and what it gets wrong · Real public OSHA data