The Ontology, in simple terms.
To understand Palantir Foundry, start with the Ontology. It is the foundation every application, workflow, and AI model in the platform is built on, and the reason Foundry works differently from the tools you already have. Once it makes sense, the rest of the platform does too.
“The Ontology is an operational control layer that acts as a live digital twin of an organization by mapping raw data to real-world business concepts, logic, and actions. Unlike a traditional database that only stores data, the Ontology connects data to how a business actually runs. It gives humans and artificial intelligence agents a safe way to understand and change business operations in real time.”
Let’s break down that definition in simpler terms, using a late customer order as an example.
Why Systems Disagree
A customer calls about a late order. The ERP has the order. The warehouse system has the shipment. The supplier portal shows the part the shipment is waiting on. Every system is correct, and none of them can answer the customer’s question: when will I receive my order?
The reason is simple. Each of those systems stores rows. A row does not know that it describes this customer, this order, or the part holding up this shipment. Only a person can see that those four records are one story. So someone pulls an export from the ERP, calls the warehouse, checks the portal, opens the spreadsheet, and pieces it together by hand. Ask a second person and they will piece it together differently. Every answer in this story required a person. The Ontology is what makes the picture exist before anyone goes looking.
A Working Model of the Business
The way an organization actually works usually lives in habits, spreadsheets, and the heads of its most experienced people. The Ontology writes it down in a form software can read. Every application then draws on that one description instead of inventing its own.
Put simply, it is a digital twin of the business: a shared model of what an organization runs on, how it connects, and what people are allowed to do to it, kept in sync with the data underneath. An airline models flights, aircraft, and crew. A hospital models patients, beds, and nurse schedules. The model reflects the operations that matter to the business, whatever industry it operates in.
Nothing gets moved. Nothing gets copied. Existing systems keep running exactly as they do today. The model gives them a shared meaning: the order in the ERP, the shipment in the warehouse system, and the part in the supplier portal are declared, once, as parts of the same customer order. From then on, every screen anyone opens agrees.
Inside the Ontology
The model is built from three types, and together they describe the business as a set of states and the moves between them. Palantir splits them into semantic elements, which describe the business, and kinetic elements, which change it.
Objects and links make the business readable. Actions make it operable. Palantir calls the first half semantic and the second half kinetic, and the distinction matters: a model with only nouns is a very good catalog. It takes the verbs to model a decision, and a decision is the unit of work an operator actually cares about. Automation is the last piece: the event that moves you to the next state without waiting for someone to notice. Known states, permitted moves, and the conditions that trigger one on their own.
Every Application Stands On It
Applications are built on the Ontology so that business workflows can run on it. A workflow is a sequence of decisions and the actions that follow them: review the late orders, decide which ship today, split the ones that cannot, notify those customers. Because the objects, links, and actions are already defined, an application does not implement that workflow from scratch. It arranges pieces the model already provides, which is also why parts of it can be automated: the model knows which states require a decision and which conditions can trigger an action on their own.
It also means the applications agree with each other. A planner’s workflow, an executive’s dashboard, and a forecasting model all read the same shipment, with the same rules about who may change what.
It Grows as Your Business Grows
This is not a diagram of the whole enterprise, signed off before value arrives. It grows one workflow at a time: model what a single team needs, put it in their hands, stop there. The next workflow reuses most of what exists.
Where to Start
Strip away the terminology and the Ontology is a shared vocabulary for the business, made executable. Objects for what an organization runs on. Links for how those objects relate. Actions for what may be done about them. Write that vocabulary down once, agree on it, and every application, workflow, and decision that follows inherits it.
You do not start with the whole enterprise. You start with one question your business cannot answer today without four systems and a phone call. Model that. Put it in front of the people who own it. The first answer proves the model, and every question after it gets easier. That is the conversation we want to have with you.
