What is Palantir - Part 3: The Ontology

There's a table in your data warehouse called VND_MST_03. It holds your supplier master records, and a handful of people are the only reason anyone knows that. When a new analyst joins, they get read access to two thousand tables like it and very little to explain them.

They get there in the end, but it takes weeks. Most of it is asking around. Old queries get dug up to see which join is the real one. Slowly, a sense builds for which columns are reliable and which ones everyone quietly works around.

Every AI agent you deploy starts as that analyst on day one. It never gets the weeks of asking around. Unless you give it a map, day one is permanent.

That's the problem the Ontology exists to solve. Part 2 ended with clean, current, governed data flowing into Foundry. This part is about the layer that makes that data mean something, to people and to machines.

A map of the business, not the data

An ontology is a simple idea wearing an intimidating name. It's an explicit map of what your business is made of: the things, the relationships between them, and the actions that can be taken on them.

For the supplier from Part 2, the map looks like this. A Supplier supplies a Plant. It receives Purchase Orders. It's managed by a Procurement Manager. Its shipments can be hit by a Delay.

Notice what's on the map: things a procurement manager would recognise, with names a procurement manager would use, connected by relationships they'd describe the same way. No tables, no foreign keys.

Palantir's docs put it neatly: the objects are the nouns of the business, the actions are the verbs. A workflow joins them into sentences. "Flag this supplier." "Switch the supply for Plant 7."

Everything in the map is backed by the data underneath. The mapping from the warehouse world is direct: a dataset becomes an object type, a row becomes an object, a column becomes a property, a join becomes a link.

"My database already has relationships"

It does. A foreign key says rows in this table match rows in that one. What it doesn't say is what the relationship means, or which of the possible joins between those tables is the right one for this question.

That knowledge lives somewhere today: in your analysts' heads, in saved SQL, in the one engineer who built the pipeline in 2019. The relationship exists only at query time, rebuilt by every person who needs it, slightly differently each time. Ask three analysts for the supplier's open orders and you can get three numbers.

The ontology moves that knowledge out of heads and into the platform. "Supplier receives Purchase Orders" is defined once. The join logic is settled and named in business language, then reused by every screen and agent that touches the supplier from then on.

And a database has no verbs at all. It stores state; it has no concept of what someone is allowed to do about that state. In the Ontology, an action type models that too. "Switch supplier" takes the replacement as a parameter, checks it's approved in the region, accepts submissions only from the right people, and applies the whole change as one transaction. Every submission lands in the action log: who changed what, when, and under which rules. The decision gets attached to the supplier itself instead of living in an email thread. That record is the start of what this series calls decision lineage.

This is also what separates an ontology from a knowledge graph used primarily for discovery and search.

The map is executable: the same model that answers questions carries out the changes.

Humans needed this map first

None of this started as an AI feature. A shared map is how a company gets one answer to "how many suppliers are at risk?" instead of five. It is also how that definition survives the analyst who wrote it leaving.

There's a simple test for whether a model passes: could someone who knows your business, but not your systems, find their way around it? If the supplier is called Supplier and links to Purchase Orders, yes. If it's called VND_MST_03, no. Palantir's design guidance is blunt on this point: model the real world, not the source data. The common failure even has a name in the docs, the Kitchen Sink: map every column of a dataset to a property, keep the cryptic names, call it done. The result mirrors the database's quirks instead of the business.

That was the case for ontologies for years: consistency, onboarding, one version of the truth. Sufficient, never urgent. AI made it urgent.

Then AI made it the whole game

Give an agent 20GB of raw tables and it will produce answers. That's the dangerous part. It guesses which join is right, guesses what STAT_CD = 4 means, and presents the guesses fluently. The day-one analyst eventually learns the truth, a month in, after annoying three engineers. The agent never gets the month. It answers anyway. Tolerable in a demo. Fatal in operations.

And you pay for the guessing on every call. An agent on raw tables re-derives the same understanding each time: which tables matter, how they join, what the codes mean. Every call pays the same toll in tokens and latency, and none of the work compounds. The thousandth call knows the company no better than the first, because there's nowhere for the understanding to live.

A better model only makes the guessing more eloquent.

The ontology is where the understanding lives. Grounding the model in that map is what Palantir calls Ontology Augmented Generation: it reasons over real objects and defined logic instead of guessing at them. The discovery work happens once, by people who know the business, and every call after that starts from it: names a human chose and links a human defined, with visibility scoped by permissions. When the agent wants to change something, it doesn't get SQL access to your ERP; it proposes an action, through the same checks a human submission passes. Each decision then lands in the record attached to the object, so the next question starts with more context than the last. The raw-tables agent re-derived everything and kept nothing.

The way I explain this to boards: a model gets better every quarter, whether you do anything or not. But a brain in a jar can't run a supply chain. It needs senses (what it's allowed to see), hands (the actions it's permitted to take), and memory (the record of every decision so far). The ontology is what supplies all three. Separate the two and you get either a clever brain with no way to operate, or a perfectly mapped business with nobody home.

The model is the brain. The ontology is the body. You rent the first. You build the second.

Run the business as code

Palantir's own phrase for what this adds up to is running your business as code, and they mean it more literally than it sounds.

Like software, the model is versioned and reviewed. Changes to object types, links, and actions happen on a branch and merge through a reviewed proposal. Core types can be protected so nobody edits Supplier directly. For anyone whose last enterprise data model died of uncontrolled drift, that's the answer to "how does it stay good?"

And like software, changes can be tested before they ship. Because the business exists as one governed model, a decision can be staged as a scenario: inspect its downstream effects in the model, then decide whether to commit it in the world. That deserves its own post later in this series.

The quiet payoff is that code reads the same to everyone who opens it. The analyst, the app, and the agent are all reading one model, so there's one version of the business to disagree about.

Who sees what

Security carries straight through from Part 2. The markings on the underlying datasets carry forward. Object types honour the access controls of the data behind them. On top of that, object and property security policies go down to the individual object and the individual property. A regional manager sees only their region's suppliers. Within a supplier, contract pricing is visible only to users cleared for commercial data. The same policies bind humans and agents alike.

One honest caveat. The ontology is the part of Foundry you can't buy your way past. Connectors are mechanical; modelling is design work, and it needs people who know the domain in the room. Start narrower than feels natural. One well-modelled domain in daily use beats a half-modelled enterprise.

The ontology is the part of Foundry you can’t buy your way past.

The supplier is now on the map: properties, relationships, permitted actions, access rules, and a record of every decision taken on it. Part 4 is about what people do with it day to day: how an analyst drills from plant performance down to one underperforming supplier, without SQL, on data that stays live.