Operational Ontology: The Pattern Behind Palantir Foundry's Ontology

I spent a few weeks hands-on with Palantir Foundry, because every explanation of its Ontology I could find was frustratingly vague. "An enterprise semantic layer." "A digital twin of the organization." None of these are wrong, but I read a lot of them and still couldn't tell you what the thing actually was. Concepts everywhere, substance nowhere.

So I went through three of the official learning courses — the end-to-end intro, ontology building, and application building — and the fog lifted. Foundry's Ontology can be described entirely in vocabulary software engineers already own. What's new isn't the concept. It's the order of the steps: ordinary business-application development, run in reverse.

And buried in that reversal is a distinct architectural pattern that deserves a name of its own — operational ontology — because the word "ontology" alone has stopped carrying the information that matters. I've anchored the definition to four testable properties and a minimal TypeScript reference implementation, public at github.com/gura105/operational-ontology. If you'd rather read code than prose, that repo is this article in executable form. What follows is the walkthrough: what I found hands-on in Foundry, and where the pattern's boundary actually is.

Foundry decomposes into three parts

Foundry is a platform that pulls an enterprise's scattered data into one place and lets you build the applications that run the business on top of it. It's a sprawling product, but feature by feature it reduces to three parts:

1. Data pipelines — ingest data from the existing systems scattered across the company, transform it, integrate it (Data Connection, Pipeline Builder, Code Repositories).
2. The Ontology — model the integrated data in terms of what it means to the business (Ontology Manager).
3. Applications — build the screens where people see and operate on those modeled things (Workshop, a low-code builder, plus SDKs).

Collect the data, give it meaning, use it. No surprises in the decomposition itself. The interesting part is the sequence — and you only see why it's interesting when you put it next to the sequence we normally follow.

The order we normally build in

Ordinary business-app development goes roughly: gather requirements → analyze the workflows → model the domain → design the physical data layer → build the app.

The domain modeling step is where the business world gets transcribed into software structure. For an e-commerce order system, the cast is Order, Customer, Inventory — entities. Entities have relationships: an order belongs to exactly one customer. And they have operations: cancel an order, allocate inventory. Operations carry business rules: a shipped order cannot be cancelled; inventory never goes negative. That whole picture — entities, relationships, operations, rules — is the domain model.

Only after the model settles do we design the physical data layer that stores it. And in most projects, the data starts from zero: the tables are born empty and fill up as the business runs. Understanding first, physical data later. One more property of this order: the app you get serves one domain. Order management is an order-management app.

Foundry runs the same steps backwards

Foundry starts from a different reality: the enterprise already has systems. Procurement, production, inventory, sales, support — every stage of the value chain has its own ERP module, SaaS tool, or spreadsheet, each one the accumulated result of somebody running the "one domain, one app" playbook years ago. The data already exists. It's just scattered.

Scattered isn't automatically bad — each department's work runs fine inside its own system. What breaks is any question that crosses systems: how does this procurement delay hit production? Does inventory actually match the sales plan? Answering means joining data across systems, which in practice means a human doing it in Excel, which means the company's view of itself is slow and unreliable.

Foundry's answer inverts the normal sequence:

First, the physical data. Pipelines pull from the scattered systems and reconcile the schemas into integrated tables. The intro course's scenario is a miniature of exactly this: an office-supply company has acquired a competitor, IT integration is a year away, and you're left holding two order systems with different schemas plus a customer spreadsheet. You clean the two order feeds, join the customers, and produce one unified order table.

Then, the model on top. The Ontology's building blocks are objects, links, and actions — and hands-on, they map one-to-one onto vocabulary you already know:

• object = entity (Order, Customer)
• link = relationship between entities
• action = command — an operation with business rules attached
• the Ontology as a whole = the domain model

Two acquired order systems, one Order object type — because whatever the IT landscape looks like, the business world contains one concept called an order. Building the Ontology is domain modeling. Same craft, same judgment — you model the real-world business, not the source tables (Palantir's own design guidance is explicit about this). What changed is the starting point: the model is built after, and on top of, physical data that other systems already own.

Finally, the applications. In Workshop you don't touch tables or SQL; you place objects on screens, traverse links, and wire actions to buttons. Apps are built against the domain model, not against the database. And because the model is shared company-wide, you don't redesign a data model per app — you build any number of value-chain-crossing apps on the same one.

So the sequence requirements → model → physical → app becomes physical → model → app. I've been calling this reverse domain modeling. (The reversal itself isn't exotic — anyone who has rebuilt an app on top of a legacy database has done physical-first modeling, and database reverse engineering is an old research field. What's distinctive is doing it at enterprise scale, with writes, as a product.)

The part that makes it operational: writes

At this point you should object: "integrate scattered data and give the whole company one view" already has an answer, and it's a data warehouse and BI.

Correct — for reading. The DWH world has its own mature modeling discipline (dimensional modeling, star schemas) optimized for scanning and aggregating, and the BI world has "semantic layers" that pin down one company-wide definition of revenue or inventory turns. If all you do is read, that stack is the answer, and it's a good one.

But that world is one-way. Data flows from source systems into the warehouse; humans look at dashboards. Say a dashboard surfaces what looks like a mistaken order. What can you do right there? Notice it. That's all. To cancel it you close the BI tool, log into the order system, and find the order again from scratch. The dashboard has no "cancel order" button. That missing button is the exact boundary between the read-only world and what Foundry is building.

Because Foundry isn't building dashboards; it's building applications — things you operate, not just observe. Operation means writes, and writes need business rules. "A shipped order cannot be cancelled" is business logic, and a read-optimized dimensional model has nowhere to put it. A domain model does: on the action.

Hands-on, this is enforced structurally. There is no path that writes an object's data directly — every change goes through an action, and the action decides who can run it and what must hold. When the intro course has you add an "Assign Order" action to your dashboard, the only input is the assignee; the status flips automatically. A half-baked state like "in progress, assignee empty" is not discouraged — it's unrepresentable. And changes written through the Ontology can propagate back to the source systems (write-back), with the system of record deliberately staying upstream: the Ontology is a junction, not a second source of truth.

Read path: sources → ontology → app. Write path: app → ontology → sources. Palantir's own docs split the Ontology into "semantic elements" (objects, links) and "kinetic elements" (actions, functions) — their words, and the honest ones. The semantic half alone is a read tool. It takes both halves to be the foundation of applications.

Which is exactly why the word "ontology" has become unhelpful: formal ontologies (OWL/RDF), knowledge graphs, and the recent wave of "ontology"-branded AI context layers are all semantic-only — legitimate tools, none of them accepting writes governed by business rules. Calling the Foundry-style pattern by the same name as its read-only neighbors hides the one property that changes what the layer can do.

Naming the pattern: operational ontology

So: a shared domain model built on top of data owned by systems you don't control, where reads traverse the model and writes are gated by rule-carrying, audited actions that propagate back to the systems of record. That's the pattern — and pinning it down is exactly what the reference implementation from the introduction exists for: four testable properties, in a codebase small enough to read in one sitting (TypeScript, MIT).

The four properties, in brief: semantic objects and links over physical data that existed first; action-gated writes with no generic update path; business rules as preconditions at the action, refusing violations with machine-readable errors, every attempt audited; and write-back with a declared owner for every piece of state. The precise wording, the edge cases, and the design decisions live in the repository README — the article you're reading is the walkthrough; the repo is the definition. Foundry is one implementation of the pattern. The repo is another, minimal one — its demo even reuses the two-order-systems-after-an-acquisition scenario. (Honesty note: the phrase "operational ontology" has prior uses, including essays by Vladimir Kozlov pointing at this same lineage. The contribution here isn't the words; it's the testable boundary and the runnable anchor.)

The quick test compresses all four properties into one question: can you cancel an order from your semantic layer? If no — you have a read layer. If yes but no source-system row ever changes — you have a parallel database. If it cancels shipped orders without complaint — you have a write API, not a domain model.

Why this matters right now: agents

The pattern is a decade old inside Foundry, but AI agents are what make it urgent. The common way to give an agent write access today is a SQL tool or a thin API wrapper, with the business rules living in the prompt — which is to say, enforced nowhere.

An operational ontology inverts that default. In the reference implementation, the MCP tool surface is generated from the model: one tool per query shape, one per action — and consequently there is no raw SQL tool. An agent gets exactly the operations the domain model defines. The same preconditions that gate humans gate the agent: try to cancel a shipped order and you get { "error": { "code": "SHIPPED_ORDER_CANNOT_BE_CANCELLED", … } } — a machine-readable refusal the agent can parse, recover from, and explain. The rules live in the model, not in the prompt.

Caveats, honestly

The hardest objection comes from DDD itself: bounded contexts. Sales' "order" and accounting's "order" may be different concepts wearing the same word, which is why one-unified-model-for-the-whole-company projects have failed for decades. Whether Foundry-scale ontologies clear this bar is something I want to verify against real deployments, not courseware. And the courses I ran are Palantir's own material — a miniature built to make the pattern look good. The pattern's boundary is testable either way; that's precisely why I pinned it to four properties instead of to a vendor's story.

What I took away

The fuzzy new concept, decomposed hands-on, turned out to be familiar parts in an unfamiliar order: domain modeling run in reverse, on top of data you don't own, with the write path governed at the action and truth left with the systems of record. None of the parts are new — entities, commands, guarded transitions, audit logs. The placement is new, and the placement is the pattern.

That's what Palantir Foundry ships under the name Ontology. As a vendor-neutral pattern, it's an operational ontology — and now that the thing has a name of its own, "you need an ontology for AI agents" stops being one claim. It becomes two: one about reading, one about acting. They were always different problems. The name just makes it visible.