What Is an Ontology? The Idea Behind Palantir Foundry

Ontology is a word borrowed from philosophy, where it means the study of what exists. In enterprise software it means something narrower and more useful: a governed model of the things your business deals with, the relationships between them, and the actions people and systems may take against them.

It is the central idea in Palantir Foundry, and it has been quietly adopted under other names elsewhere. It is also routinely dismissed as a rebranded data model, which misses what makes it operational.

Start with what it replaces

Most organizations have tables. They are named things like orders_fct_v3 and cust_dim_final, and alongside them sits cust_dim_final_DO_NOT_USE, which somebody's dashboard still queries. The meaning of these tables lives in the head of whichever analyst last worked on them. When a new person asks what counts as a customer, they get three answers depending on who they ask, because finance, sales, and support each built their own definition.

What an ontology adds

Objects instead of tables. A Customer is a defined thing with agreed properties, not a join you rewrite each time. Relationships are declared once, so the fact that a Customer places Orders and an Order has Shipments is part of the model rather than tribal knowledge rediscovered in every query.

Three further properties are what make it operational rather than merely tidy.

Actions. Rerouting a shipment is a defined operation on the Shipment object that writes back to the source system, with validation and an audit trail. This is the crucial difference from a semantic layer or a warehouse: an ontology is not read-only. People and agents do things through it, and those things happen in the systems of record.

Permissions. Access is granted at the object and field level, so the same operational application can safely show a planner one slice and an external vendor another. You are not maintaining parallel filtered copies of data per audience.

Lineage. Every object traces back to the pipeline and source that produced it. When someone asks why a number looks wrong, or an auditor asks where an AI-assisted decision came from, the answer is in the system rather than in someone's memory.

Why agents work better on an ontology

This is the reason the concept has become newly fashionable. An AI agent operating on raw tables has to infer meaning from column names and hope it inferred correctly, and it can write anything anywhere its credentials allow. An agent operating on an ontology works against defined objects with declared relationships, and it can only take actions that exist in the model, which are already permissioned and audited.

That converts a broad and rather alarming attack surface into a bounded one. It is also what makes agent behaviour reviewable: the audit trail records which action ran against which object, not merely that a query was executed. Anyone building agents against enterprise data eventually rebuilds some version of this, usually badly and eighteen months late.

The hard part is not the software

Standing up the platform is the easy half. The difficult half is getting four departments to agree on what Customer means, and whether a trial account, a churned account, and a subsidiary of an existing account are all the same object type. Those conversations surface genuine business disagreements that the old table sprawl allowed everyone to avoid.

This is where ontology projects actually fail. Not on modelling technique, but on governance: nobody was empowered to decide, so the model accumulated optional fields and special cases until it described the disagreement rather than resolving it. Successful builds have a named owner per object type with authority to settle definitions, and they start narrow, with one or two workflows that matter, rather than attempting to model the enterprise up front.

Do you need one?

Probably not, if your analytics needs are served by a warehouse and dashboards and nobody is trying to automate operational decisions. An ontology earns its cost when decisions and actions, rather than reports, are the output, and when those actions span systems that do not agree with each other. That is why the pattern shows up first in supply chain, manufacturing, healthcare operations, and claims handling.

Where the ontology and the data estate meet, the common architecture is to let a lakehouse engineer and govern the data and the ontology run the operation, which we compare in Palantir vs Databricks. Real-world examples of ontology-driven operations sit in our pieces on hospital operations and insurance underwriting, and the platform itself is introduced in what is Palantir Foundry.

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 is the part that determines whether the build succeeds. Agent work on top of the ontology runs through AIP and forward deployed engineering, with the wider practice at Palantir consulting.