The most expensive way to use Palantir Foundry is as a data warehouse. We've now seen it from both sides — implementations we've built and implementations we've been called in to rescue — and the dividing line is always the same. Teams that fail bought Foundry, pointed pipelines at it, produced very clean tables, and wondered why nothing changed in the business. Teams that succeed understood that in Foundry, the ontology is the product. Everything else — pipelines, applications, AI — exists in service of it.
The ontology is Foundry's operational model of your business: objects (the things that exist — an Order, a Shipment, a Supplier), properties (what you know about them), links (how they relate — this Shipment fulfils that Order, from this Supplier), and actions (what an operator can legitimately do — expedite the shipment, reallocate the stock, escalate to the supplier). Skip that layer, or treat it as an afterthought, and you've paid a premium price for a place to put tables you could have put anywhere.
Model the business before you touch a pipeline
Our Foundry engagements start in a workshop room, not a code repository. Before anyone discusses sources or schemas, we make the team answer business questions: What is an Order, precisely — when does it come into existence, and when is it done? Is a Shipment one truck or one consignment? Can a Supplier be both a vendor and a customer, and what happens to your model when it is? Which of these does an operator actually make decisions about on a Tuesday afternoon — and what are they allowed to do about it?
That last question is the one most teams never ask, and it's the one that separates an operational platform from a reporting layer. Actions are first-class citizens of the ontology. If your model says what a Shipment is but not what a planner can do to it, you've built a museum: accurate, well-lit, and useless under pressure.
If your ontology has no actions, you've built a very expensive read-only model of your business.
Pipelines hydrate, apps act, AIP reasons
Once the ontology exists, every other Foundry component snaps into a clear role:
- Pipelines hydrate the ontology. Their job isn't "land the data" — it's keeping every Order, Shipment and Supplier object current and trustworthy. That framing changes how you build them: completeness and freshness are measured per object type, not per table.
- Workshop apps act on the ontology. Operators see objects they recognize and buttons that do real things — with the writeback, permissioning and audit trail handled by the platform instead of bolted on later.
- AIP reasons over the ontology. An LLM grounded on typed objects, links and permitted actions can answer "which at-risk shipments serve our top-tier customers, and what can we do tonight?" — a question that's nearly unanswerable over raw tables.
Notice the dependency direction. Get the ontology right and the apps almost design themselves. Get it wrong and no amount of pipeline engineering or prompt tuning compensates downstream.
What this looked like at 12 systems of scale
The clearest proof we've seen came from a supply-chain control tower spanning 12 source systems — two ERPs, a TMS, a WMS, supplier portals, spreadsheets that were load-bearing in ways nobody admitted. The integration work was hard but unremarkable. What made the platform land was three weeks spent with planners — not data engineers — defining roughly 20 object types and, crucially, the 14 actions planners actually take when a shipment goes sideways: expedite, split, re-source, escalate, accept the delay.
When the first Workshop app went live, adoption needed no campaign. Planners recognized their world in the object model — these are my lanes, my suppliers, my late shipments, and here is the expedite button — rather than someone else's star schema wearing a new UI. Twelve systems' worth of mess, presented as one legible operational picture. That recognition moment is the whole game, and you can read more of these outcomes in our case studies.
Key takeaways
- In Foundry, the ontology — objects, properties, links, actions — is the product; pipelines and apps exist to serve it.
- Model the business first: define what an Order, a Shipment and a Supplier are before writing any pipeline code.
- Actions are not optional — an ontology that can't be acted on is a reporting layer at platform prices.
- Put operators in the modeling room; data engineers alone will faithfully reproduce source-system schemas, not the business.
- Judge readiness by one test: does a frontline operator recognize their world in the object model?
The three anti-patterns we keep removing
Table-first thinking. Teams migrate their warehouse mental model into Foundry: land the data, conform it, expose it. Six months in, they have excellent datasets and an ontology that's a thin veneer over them — object types that are really just tables with better names, no links worth traversing, nothing to act on.
Skipping action modeling. The objects get defined, the actions don't, and the "operational platform" launches as a dashboard. Operators look, then go back to the ERP and email to actually do anything — and every decision made in those tools is invisible to the platform that was supposed to capture it.
Ontology by data engineers alone. This one is subtle because the work looks right. But data engineers, modeling without operators in the room, faithfully reproduce the source systems — the ontology mirrors the ERP's tables instead of the planner's reality. The fix costs almost nothing: put the people who will use the platform in the modeling workshops from day one, and let them argue about what a Shipment really is. Those arguments are the design work.
If you're scoping a Foundry programme — or holding one that's become a very expensive warehouse — our Decision Intelligence practice runs ontology-first implementations, and we're happy to pressure-test your object model before you commit another quarter to pipelines.