The Palantir Ontology, Explained: Objects, Links, and Actions

The Palantir ontology is the layer where Foundry stops describing a business and starts running one. It has three primitives: object types, which define the things you operate on, link types, which define how those things relate, and action types, which define the governed operations that change them. Every Workshop application, Quiver analysis, and AIP agent reads and writes through that same model. The practical difference is easy to state. A dashboard tells a planner that a shipment is late. An ontology lets the planner reroute it, validates the change against available capacity, writes the update back to the ERP, and records who made the call.

If you want the concept without the Palantir specifics, start with what an ontology is. This piece is about how Palantir actually implements one, and where implementations come apart.

Object types are the nouns of your operation

An object type is a definition: a display name, a set of typed properties, a primary key, and one or more backing datasets that populate it. A Vessel object type might use the IMO number as its key and carry properties for capacity, current position, class society, and last inspection date, assembled from three source systems that have never agreed on a vessel list.

Two implementation details matter far more than they sound. The first is the primary key. Foundry needs a stable, unique identifier for every object instance, and choosing the wrong one is the most common reason an ontology gets rebuilt. If the candidate key changes when a record is updated, or the same real-world entity arrives under two different keys from two systems, you have an identity resolution problem that belongs in the pipeline, before the object type is worth defining at all.

The second is the backing datasource. Object types are indexed from Foundry datasets, and the sync between dataset and object index is real infrastructure with its own latency and failure modes. An object type fed by a nightly pipeline is a nightly object type, no matter how live the application above it looks. Teams routinely promise operators real-time visibility and then discover the binding constraint is an extract schedule four layers down in SAP.

Link types connect the nouns

A link type declares a relationship between two object types: a Vessel carries many Containers, a Claim belongs to one Policy, a Work Order affects one Asset. Foundry supports one-to-many and many-to-many relationships, and the many-to-many case is backed by its own join dataset that has to be maintained like any other pipeline output.

Declaring relationships once removes the join rewriting that eats analyst time in a warehouse, but the bigger payoff is runtime traversal. An operator looking at a delayed shipment can walk to the carrier, the origin plant, the customer orders affected, and the inventory those orders were committed against, without anyone writing a query. An AIP agent traverses the same links under the same permissions, which is why agents built on an ontology behave more predictably than agents pointed at a warehouse.

The design discipline is restraint. Every link is a path somebody will traverse, and every path is a place where a stale or wrong relationship turns into a wrong decision. Model the relationships the operation uses, and leave the rest in the data layer.

Action types are where the ontology stops being read-only

Action types are the part most evaluations underweight, and they are the reason Foundry behaves differently from a semantic layer or a metrics store. An action type is a defined, permissioned operation against the ontology: reroute a shipment, approve a claim, take an asset out of service, assign a case to an adjuster. It has typed parameters, submission criteria that validate input before anything is written, and a declared effect on object state.

That effect can stay inside Foundry or write through to the system of record using a webhook or a connector. Built properly, the action type is the only route by which that change can be made, which makes the validation logic and the audit record unavoidable rather than optional.

Three properties come free once operations run through action types. Validation happens before the write, so an operator cannot commit inventory that does not exist. Authorization is granted per action, so a planner can reroute and an external carrier cannot. And the audit log records the action, its parameters, the objects touched, and the identity behind it, which is a materially more useful artifact than a database change log when an auditor or a regulator asks how a decision was made.

Actions are also the control surface for AI. An agent that can only act through action types is bounded by the same validation and permissions as a human operator, and its behavior is reviewable in the same log. That is the governance model our AIP and forward deployed engineering teams configure in the first sprint rather than the last.

Functions, the SDK, and what gets built on top

Two more pieces make the ontology programmable. Functions are typed logic that runs against ontology objects, written in TypeScript or Python, and they are how validation rules, derived values, and action side effects get expressed. The Ontology SDK generates a typed client from your ontology, so an external application, a mobile tool, or a service outside Foundry can read objects and invoke actions through the same governed interface.

This matters for a reason that has nothing to do with Palantir. Once the ontology is the interface, you are no longer choosing between building inside the platform and building outside it. Workshop applications, notebooks, external services, and agents all consume one contract, and the permission model and audit trail follow the contract rather than each consumer.

What the ontology does not do

The ontology is a poor data engineering environment, and treating it as one is expensive. Cleaning, joining, deduplicating, and conforming data belongs in pipelines beneath the ontology, whether those pipelines run in Foundry's transform layer or in a lakehouse that feeds it. The ontology consumes curated datasets and exposes them as governed objects. If your pipelines are unreliable, the ontology will surface that unreliability faster and more visibly than a dashboard would, which is useful but a long way from fixing it.

The ontology also does not replace a system of record. Objects are a governed view over source systems plus the state Foundry owns directly, and when an action writes back, the source system remains authoritative for that field. Deployments that quietly let Foundry become the only place a value exists create a migration problem for whoever inherits the platform.

Who owns the ontology

Ontology changes are schema changes to the operational layer of the business, and they need to be treated that way. Foundry's Ontology Manager is where object types, links, and actions are defined and versioned, and access to it should be as controlled as access to a production database migration.

In the deployments that hold up, every object type has a named owner with the authority to settle definitional questions, action types go through review before release, and there is a documented path for retiring a property nobody uses. In the deployments that decay, the ontology accumulates optional fields, near-duplicate object types, and actions that exist because one team needed a workaround in the third month.

Where Palantir ontologies actually go wrong

The failure patterns repeat across industries, and none of them are technical:

• Modeling the source system instead of the business, which produces object types named after tables and a model nobody outside the data team recognizes.
• Starting with an enterprise-wide model rather than one or two workflows, which guarantees the first application ships late and against objects no operator ever validated.
• Treating the ontology as a warehouse, loading every property from every system because it might be useful, and paying for both the indexing and the confusion.
• Shipping applications without action types, which produces expensive dashboards and leaves the write-back problem for a phase two that never gets funded.
• Unresolved identity, where two source systems disagree about what a customer is and the ontology inherits the disagreement as duplicate objects.

Where BD Emerson fits

We build ontologies as part of Foundry implementation, and we run the definitional workshops that decide what the objects mean, because that work determines whether the build holds up in year two. Our approach is to model one operational workflow end to end, including action types and write-back, before adding a second. The platform overview is in what is Palantir Foundry.

BD Emerson is a Palantir implementation partner and consultancy. If you are scoping an ontology, start with the decision you want an operator to make differently next quarter, then work backward to the objects, links, and actions that decision requires.