What an Operational Ontology Is (And What It Isn't)

Pull up the table your operation actually runs on. Not the org chart — the spreadsheet. The one with a row per order, a column for due date, a column for quantity, a column where someone types the customer name by hand. It works. It has worked for years. And it cannot answer the one question you ask it most: *if this order slips, what else breaks?*

It can't answer because the answer isn't in any cell. It lives in the connections — this order needs that material, that material comes from this supplier, this supplier has been three days late twice this quarter — and a table has nowhere to put a connection. It has rows and columns. The relationships fall on the floor, and your people pick them back up by hand, from memory, every day.

A table stores what you typed. An ontology stores what's connected.

We've written before about why an operational ontology is the operating system for decisions, and why the architecture Palantir built for the Fortune 100 is what a mid-sized industrial operation needs. This post goes one level down — into the wiring. What is an operational ontology actually *made of*, what does one look like on a real slice of work, and where does it stop being a fancy database? The last post was the *why*; this is the *what* and the *how*.

Direct answer:

An operational ontology is one connected model of your operation, built from four pieces: the real things in your business (objects), what you know about each (properties), how they connect (relationships), and what you can do (actions). Unlike a flat data model, it holds the relationships — so software and AI can reason across the operation and act on it.

The four pieces, concretely

Strip away the academic word and an operational ontology is four building blocks. Most people have heard "objects and relationships" and nodded along without ever seeing what that means on a Tuesday. So here they are, on a slice of work you'd recognize.

1. Objects — the real things, defined once

An object is a real thing in your operation that the system understands as one entity: an order, a machine, a material, a customer, a work order, a site, a supplier. The key word is *once*. Today "Order DC-1042" exists as a row in your order book, a different row in your shipping sheet, a line in an email, and a number on a whiteboard. Four copies, none authoritative, each drifting from the others the moment one gets updated and the rest don't.

In an ontology there is one Order DC-1042. One object. Everything else — shipping status, invoice, floor schedule — points *at* it instead of keeping a private copy. When the due date changes, it changes in one place, and everything connected sees it immediately. No reconciliation meeting; there was never a second copy to reconcile.

2. Properties — what you know about each thing

Properties are the facts that travel with an object. An order's: due date, quantity, value, customer, priority. A machine's: line, cycle rate, last service date, status. A material's: on-hand quantity, lead time, unit cost, allowed substitutes.

This looks like the columns in your spreadsheet, and that's the trap — it's why people assume an ontology is "just a database." The difference isn't the property. It's that the property hangs on an object connected to everything else, so the moment it crosses a line you care about — on-hand quantity drops below what booked orders need — the system can *follow the connection* to what's now at risk. A column can't follow anything. It holds a number until a human thinks to read it.

3. Relationships — how the things connect

This is the piece a flat data model structurally cannot hold, and it's the whole point. A relationship is a real, first-class link between two objects:

• This order needs that material.
• That material comes from this supplier.
• This work order builds that product.
• This machine feeds that delivery.
• This delivery goes to that customer.

Read those left to right and you've described a chain that, today, exists in exactly one place: your head. You know that if the ballistic nylon is late, the Eagle-9 bags don't get built, order DC-1042 misses its date, and Calloway — a customer who can't slip — gets a call you don't want to make. You know the whole chain. Your spreadsheet knows four disconnected numbers.

When the relationships are written down as objects in their own right, the software knows the chain too. The material running short doesn't just turn a cell red. It *propagates* — the system walks the relationships and tells you, in one move, that Calloway's order is now at risk. That traversal is the entire reason an ontology exists. Everything else is bookkeeping.

Wired up, the chain isn't a whiteboard diagram — it's a spine the system can walk end to end. One slice, illustrative, drawn the way MIDAS holds it:

```mock

connected

```

4. Actions — what you can actually do

The last piece is the one almost every "data model" leaves out entirely. An action is an operation the system can take that writes back to your real world: reorder the material, reschedule the line, reassign the work order, open a task for an owner, notify the supplier.

A data model that only reads is a report: it shows you the problem and leaves you to fix it across six other systems by hand. An ontology with actions closes the loop: it turns "Calloway's order is at risk because nylon is short" into an actual task — *verify and reorder 600 m of ballistic nylon, owner: John, need-by: the 14th* — written back to the system John works in, with a record of who did it and when. The map — objects, properties, relationships — tells you what's true. The actions change what's true. Without them, you have a very expensive way of finding out you're already late.

Four pieces. Objects, properties, relationships, actions. The first three let the system *understand* your operation; the fourth lets it *run* it.

Ontology vs. a flat data model: the difference that matters

People conflate these two because they both "store your data." They are not the same kind of thing.

A data warehouse is a magnificent version of the left column: it holds every row your operation ever produced, cheaply, forever — useful, for looking backward. But storage is not the same as a decision. (We go deeper in operational ontology vs. data warehouse.) A warehouse can tell you in exquisite detail that you missed three deliveries last quarter. It can't tell you you're about to miss the fourth, because "about to" lives in the relationships — booked orders against live stock against supplier lead time — and it stored the numbers, not the wiring between them.

This is where the bill for a flat model lands, in two places. The first is hard cost. Gartner has found that poor data quality costs organizations an average of $12.9 million a year. Read that as an operator, not a CIO: most of it isn't a typo in a cell. It's the *disconnection* — the same order living as four drifting copies, the stock number three days stale, the supplier delay nobody linked to the at-risk delivery. A warehouse inherits every bit of that, because copying disconnected data into one big store doesn't connect it; it centralizes the mess.

The second cost is quieter, paid in your people's hours. McKinsey, studying how knowledge workers spend their week, found they lose an average of 1.8 hours every day — 9.3 hours a week — searching for and gathering information. On a floor that's the production lead cross-checking the order book against the stock sheet, the buyer chasing a lead time down an email thread, the planner rebuilding the same picture every morning because nothing held it overnight. Flat data forces a person to hunt each fact and reassemble the picture by hand; an ontology already holds the connections, so the answer is one query, not an afternoon. Define the object once, link it, and the drift has nowhere to start.

A worked example: one shortage, two architectures

Numbers below are illustrative — a clean example, not a customer's books — but the shape is exactly what we see on real floors.

You book a sales order: 1,000 Eagle-9 bags for Calloway, due the 28th. Here's what each architecture does with it.

On a flat model

The order goes into the order book as a row. Stock lives in a different sheet. The bill of materials lives in a third file the production lead maintains. Nothing connects them, so the moment of booking passes silently. Two weeks later the line goes to pull ballistic nylon and finds 1,840 metres on hand against the 2,400 the run needs. It stops — expedited freight, overtime to close the gap, and a call to Calloway to renegotiate a date you already promised. The data was all there. It was just in three rooms that don't talk.

On an ontology

The order is an object, and the moment it's booked the system already knows the chain — order needs the Eagle-9 bag, which has BOM v3, whose line resolves to ballistic nylon in stock. So it does the arithmetic a spreadsheet leaves for a human: 1,000 × 2.4 m = 2,400 m needed against 1,840 on hand. 560 m short. It reads the lead-time property — 14 days — and fires the warning the day the order is booked, two weeks before the line would have hit the wall. Then it takes an *action*: it opens a task — *verify and reorder 600 m ballistic nylon, owner: John, need-by attached* — in the system John already works in. The whole traversal, on the day of booking, ending in an owned move rather than a red cell:

```mock

shortage

```

The nylon gets ordered on a normal day, at list price. The line never stops. Calloway never gets the call.

Same data, same week. The only difference is whether the order, the BOM, and the stock could see each other — and that difference is worth one expedited freight bill plus a shift of overtime, every time it happens. On a real floor it happens more than anyone wants to admit.

What an operational ontology is *not*

Because the word gets stretched, here's the boundary, drawn sharply.

It is not a data warehouse

A warehouse centralizes storage. An ontology models meaning and enables action. You can feed an ontology *from* a warehouse, but pouring rows into one big bucket doesn't create the relationships — and the relationships are the product.

It is not "an ERP"

An ERP is a system of record: it captures what the business did, after it did it. An ontology sits *above* your ERP (and your MES, and your spreadsheets), links what's happening right now across all of them, and turns it into a decision before the loss is booked. One looks back; the other looks forward. The ERP stays where it is — the ontology connects it, it doesn't replace it.

It is not a dashboard

A dashboard is a window onto data you go and ask for; it shows a number after you think to look. An ontology watches the relationships for you, surfaces what's slipping before you'd know to check — and then acts. A dashboard waits. An ontology comes to you.

It is not a knowledge graph for search

A knowledge graph linked for *retrieval* — find the document, answer the question — is a cousin, but it's read-only and it's about facts, not operations. An operational ontology is built to *run* an operation: it carries live state, the logic of your business, and the verbs that write back to your real systems. Search-and-answer is a feature. Acting on the operation is the job.

How AI sits on this (and why it can't sit on the flat model)

This is where the whole thing pays for itself — and it's the heart of why an ontology is the operating system for decisions. Point an AI model at a flat export and it's working blind. It can read the rows, but it can't see that this order needs that material from this often-late supplier, because that connection was never written down — so it does what a confident system with no context does: it makes something up that sounds right. That's the demo that dazzles once and helps you never. Point the same model at an ontology and it inherits the whole map; now it can rank what's genuinely at risk this week, name the owner who can fix it, and draft the message to the supplier. The intelligence was never only in the AI model — it was in that model *plus* the connected context it gets to reason over. AI models keep getting cheaper and sharper; the scarce asset is the context they run on.

And about your people: the system surfaces and proposes; *humans decide.* It hands your plant manager the warning while there's still time to use it — it doesn't take the wheel. Your sharpest operators stop spending half their day reconciling numbers between systems and spend it on the judgment calls only they can make.

Where this fits in MIDAS

The practical version: this is exactly what MIDAS builds. It's the industrial intelligence layer that sits above the systems you already run, and the operational ontology is its core — the connected model of your objects, properties, relationships, and actions. (Here's how the platform assembles it on top of your existing stack.)

We don't rebuild your systems — we connect your data and put AI on top.

Your ERP stays. Your spreadsheets stay. Your MES, your project tools, your sensors and cameras, the messaging where your real updates live — all of it stays. A forward-deployed engineer maps how your operation actually runs, defines the objects once, wires the relationships that today live only in your team's heads, and attaches the actions that write back. One system. One ontology. Not a rip-and-replace, not an eighteen-month project. And because it's the first funded application most operators recognize, the ontology usually gets built underneath an AI project-management deployment — the project work is the wedge; the connected model is what makes it see reality.

The richer the ontology, the sharper it gets, because every object you connect makes every other one more useful. Wire orders to stock and you get the shortage warning. Add the floor through Production Intelligence — live output, drift, and quality signal — and you see the bottleneck forming before it spreads. Add the customer and the delivery date, and a machine slowing at 2pm becomes a call you make today instead of an apology next week. That's the advantage the operation across town can't copy by trying harder, because it lives in the wiring, not the effort.

Common questions

What is an operational ontology, in plain terms?

It's one connected model of your operation, built from four pieces: the real things (objects like orders, machines, materials), what you know about each (properties), how they connect (relationships), and what you can do (actions). Held in one live picture instead of ten disconnected files, so software and AI can reason across the whole operation and act on it.

How is an operational ontology different from a data model or database?

A flat data model stores rows and columns; the relationships between things either live in a human's head or sit buried where nothing traverses them. An ontology makes relationships first-class objects the system can follow — so it can answer "if this slips, what else breaks?" and then act. Storage is not the same as a decision.

Isn't an ontology just a data warehouse with extra steps?

No. A warehouse centralizes storage for looking backward — it can tell you what already happened, cheaply. An ontology models meaning and enables action: it connects live state across your systems and surfaces what's about to break, before the loss is booked. You can feed an ontology from a warehouse, but copying rows into one store doesn't create the connections — and the connections are the product.

Do I need to replace my ERP or spreadsheets to have one?

No. An operational ontology sits *above* the systems you already run and connects them. Your ERP, MES, project tools, and spreadsheets keep working exactly as they do today; the ontology links what's happening across them and turns it into warnings and actions. You connect what exists — you don't rip it out.

Why can't I just point AI at my spreadsheets and get the same thing?

Because an AI model reasons over what it can see, and a flat export hides the connections. It can read that nylon is low and that an order is due, but not that *this* order needs *that* nylon from a supplier with a 14-day lead time — so it guesses. Give the same model an ontology and the chain is right there as objects; now it reasons the way your best operator would, and proposes the move instead of inventing one.

How long does it take to build one?

Weeks, not a year. You don't model the whole operation at once. You find the single decision that costs the most when it goes wrong, wire up the two or three systems that should have caught it, prove the warning fires before the loss, and grow the ontology one connection at a time from a working result.

See your operation modeled as one ontology

Building your first slice of an operational ontology is a conversation, not a transformation project. We'll map the one decision costing you the most, name the objects and connections that should have caught it, and show you exactly what it takes to put the warning in front of you before the loss. Book an intelligence-layer assessment.