Palantir's Ontology, Explained: The Concept Everyone Struggles With

Ask five people who've worked in Palantir Foundry to explain the Ontology in one sentence, and you'll get five different answers. That's not because it's poorly documented — it's because "ontology" is doing a lot of work as a word, and most people arrive at Foundry with a mental model (data warehouse, ERD, knowledge graph) that only partially fits.

Here's the version we'd give a new engineer on day one.

Start with the problem it solves

Enterprise data is usually organized around systems, not around the things the business actually cares about. A shipment might exist as three different rows across a WMS, a TMS, and a customer-facing tracking system — each with different keys, different field names, different update cadences. Analysts and engineers spend enormous effort just reconciling "which row in which system is actually the same real-world shipment."

The Ontology is Foundry's answer: a layer that says, explicitly, "here is what a Shipment is, here are its properties, here is what actions can be taken on it, and here is how it links to a Customer, an Order, and a Carrier" — regardless of which underlying system the data originally came from.

The three things people conflate

Most confusion comes from Palantir using "ontology" to describe three related but distinct layers at once:

1. Semantic layer — object types (Shipment, Customer), their properties, and the relationships between them. This is the part that's genuinely like a schema or an ER diagram, just decoupled from any single source system.
2. Kinetic layer — the actions that can be taken on objects (re-route a shipment, approve a claim) and the write-back logic that runs when someone does. This is what makes the ontology operational rather than read-only — it's closer to a domain model with behavior than a passive data schema.
3. Dynamic layer — simulation and "what-if" capability layered on top, letting you model the effect of an action before committing it.

Most teams spend 90% of their early ontology work in the semantic layer, and that's the right place to start. The kinetic layer is where the real payoff shows up, because it's what turns a nicely modeled dataset into a tool an operator can actually use to do something — which is also the foundation AIP agents reason and act against.

How to actually model one

The mistake we see most often is treating ontology modeling as a big-bang, model-everything-up-front exercise. It works far better as an iterative process tied to a real workflow:

• Pick one operational decision that's currently painful (e.g., "which shipments are at risk of missing SLA").
• Model only the object types and relationships that decision actually needs.
• Wire in the actions an operator needs to take in response, not just the read-only view.
• Expand the ontology outward from there, driven by the next workflow, rather than trying to model the whole enterprise on day one.

This is the same discipline good domain modeling has always required — bounded contexts, not a single monolithic schema — it just happens to be enforced by Foundry's tooling rather than a team convention.

Why this matters more than it looks like it should

Teams that get the ontology right end up with something durable: new Workshop apps, new AIP agents, and new pipelines all plug into the same object model instead of re-deriving "what is a Shipment" from scratch each time. Teams that skip this step and go straight to building a dashboard usually end up rebuilding it once the ontology catches up to reality.

If you're mid-buildout and want a second pair of eyes on an ontology design before it hardens into something expensive to change, that's a conversation worth having early — see our services or read our overview of Palantir Foundry 101 if you're earlier in evaluation.