The Palantir Ontology Explained from a Data Governance View
Why Foundry's central piece is better understood as executable policy than as a data model
Quick Answer
The Ontology in Palantir Foundry is a model of the business made of objects, links, actions and permissions. Seen from data governance, it is something more interesting than a model: it is where rules stop sitting in a document and start being enforced.
A shared definition stops being a glossary entry and becomes an object type. A policy about who may modify an order stops being a procedure and becomes an action with permissions. And the most sensitive controls travel with the data as it is derived, instead of staying behind in the query that read it.
That does not make governance automatic. Somebody in the business still has to decide what each thing is called and who may change it. But it changes where that decision lives: inside the platform, not in a wiki page nobody opens.
A glossary describes what should happen. An ontology decides what can happen.
In most organisations we work with, data governance exists on paper. There is a glossary, an ownership matrix and an access policy. And, at the same time, one report says there are 41,200 active customers and another says 38,700, because each applied a different definition.
The problem is rarely a lack of rules. It is the distance between the rule and the place where somebody does their job. We covered that when discussing operational data governance versus the maturity model. The Ontology is, in practice, a way to close that distance.
Governance that is not enforced in the operation is documentation.
The Four Elements, Read as Governance
The Ontology documentation describes them in product terms. Here is the governance reading:
Objects: The Shared Definition, in One Place
An object — a customer, an order, a turbine — is the shared definition made executable. If "active customer" is an object type with its properties, there are no longer two reports with two numbers: there is one definition, and if somebody disagrees, the argument happens earlier, about the model.
Links: The Relationships Nobody Documents
The link between an order and the plant that serves it, or between a case and its holder, usually lives in three people's heads. Modelling it makes it queryable and auditable.
Actions: Policy Turned into Code
This is the real difference from an analytics semantic layer. An action defines what can be done to an object and who may do it, with permissions evaluated at execution time. Approving a supplier switch stops being an email and becomes a recorded operation.
Permissions: Part of the Model, Not an Annex
Access control is not designed afterwards. It is part of the definition of the object and the action, which is how data governance should always have worked.
The Controls That Travel with the Data
For a regulated company, this is the point worth understanding properly. Palantir's security documentation separates two families of control:
- Mandatory: markings, classification-based access controls and organisations. They apply to the unit of data and follow it as it is derived, supported by the platform's provenance and lineage.
- Discretionary: resource roles and row or column filtering through restricted views and object and property security policies. They filter what a user can read, but do not extend to what is exported afterwards.
The practical consequence is a design rule: genuinely sensitive data is protected with mandatory controls, not with a filtered view alone. The Ontology SDK documentation makes the same point when it warns that row and column controls do not extend to what the application does with the data afterwards, and recommends pairing them with markings or classification.
Who Owns an Object
The question that decides whether a deployment succeeds is not technical: who decides how "order" is modelled?. If the answer is "the platform team", the model will end up looking like the ERP schema.
What works in large corporations is the split we described in federated data governance: each domain owns its objects and actions, and a shared group decides only the minimum standards, such as how shared entities are identified or which classification criteria apply.
Three Modelling Mistakes We See
- Copying the source schema. If the "supplier" object carries all 74 fields from the SAP table, nobody in the business recognises it. The object should reflect how the organisation sees things, not how the system stores them.
- Modelling the whole company before delivering anything. A useful Ontology grows from one concrete process. The one designed on a whiteboard over six months arrives late.
- Treating the model as final. When real data lands, empty fields and broken rules appear. The model gets corrected, and the applications built on it inherit the correction.
How to Start: One Object, One Process, One Action
In our deployments the strongest start is deliberately small: one process that crosses at least two systems, the minimum objects to support it, a single action that is done by email today, and the access control that action requires. With that, something is already in production, and the governance conversation now has a real case in front of it.
Do you have a glossary nobody uses and two numbers for the same metric?
At Galde we model Palantir Foundry ontologies in multinational corporations in regulated sectors, starting from the definitions the business already argues about and turning them into objects, actions and permissions that are enforced.
How Galde Can Help with the Ontology
Through our Palantir consulting and implementation, we design the Ontology with each domain's owners and connect it to source systems without duplicating the data platform you already run.
Through data governance, we translate your policies into platform controls: what is mandatory, what is discretionary and what has to be recorded.
And through data platforms, we sustain the pipelines feeding those objects and the alerts that fire when they stop being reliable.
Conclusion
The Ontology is why Palantir is explained badly as a data platform and well as an operations platform. For a data governance lead, its value is not in the modelling but in the fact that definitions, policies and permissions stop living in documents and start being enforced where people work. In exchange it demands the usual thing: that somebody in the business owns each object.
Palantir®, Foundry® and AIP® are trademarks of Palantir Technologies Inc. Galde is not an official Palantir partner and is not affiliated with the company; we implement the platform for our clients.
Frequently Asked Questions
How does the Ontology differ from a BI semantic layer?
A semantic layer lets you query with shared definitions. The Ontology adds actions and permissions: beyond reading, it allows operations to be executed against systems with a record of who did what, and under what conditions.
Does the Ontology replace our data catalogue?
Not necessarily. The catalogue still helps discover and document assets across the organisation. The Ontology is where the definitions and policies of the modelled process are actually enforced.
Which controls really protect sensitive data in Foundry?
Mandatory controls such as markings and classification-based access control, because they follow the data as it is derived. Row and column filtering limits what is read, but does not travel with what is exported.
Who should own each Ontology object?
The business domain that generates or manages that information, not the platform team. A shared group defines only the minimum standards used across domains.
How many objects do you need to start?
The minimum to support one concrete process, usually fewer than ten. Modelling the entire organisation before delivering anything is the most common and most expensive mistake.
