Palantir gets dismissed as "analytics with a nice UI" because people look at Foundry through the lens of the modern data stack: ingest → model → dashboard. The Ontology is a different bet. I think of it as an operational schema—a set of typed objects and relationships that can be queried like a semantic layer and acted on like an application backend. The tell is that Palantir's public docs treat "actions" as first-class configuration, complete with side effects (webhooks/notifications), permissions, monitoring, and an action log—not as an afterthought glued on via reverse ETL.
Fragmentation is not the hard part—coordination is
A large enterprise doesn't have "customer data." It has customer-shaped fragments living in at least three worlds:
- systems of record (ERP/CRM)
- operational tools (ticketing, WMS/TMS, MES)
- analytical copies (warehouse/lakehouse)
The warehouse solves the analytical copy. Operations still break because the place you notice the problem is rarely the place you can fix it. In a typical stack, the "fix" happens by logging into SAP/Salesforce/ServiceNow, changing something, then waiting for sync.
Foundry's Ontology tries to collapse that loop: the "thing you're looking at" is an object with identity, typed properties, links to related objects, and actions that change state with governance and auditability.
Semantic layer vs. operational ontology (what actually changes)
- •Read-only analytics
- •Metrics and views
- •External orchestration
- •Descriptive
- →Read-write operations
- →Typed entities with actions
- →Built-in governance & audit
- →Prescriptive
| Topic | Traditional semantic layer | Foundry Ontology |
|---|---|---|
| Primary unit | metric / view / model | object type / link type / action type |
| Core interface | SQL/semantic queries | search + object views + actions |
| Write path | out-of-band (reverse ETL, API scripts) | action submission path with rules, permissions, monitoring |
| Side effects | external orchestration | built-in side effects (webhooks, notifications) |
| Auditability | depends on each tool in the stack | action log + platform auditing posture |
| Failure mode | "dashboard is wrong" | "action is wrong" (must be reversible, governed) |
A semantic layer is still useful—but it's descriptive. The Ontology is prescriptive: it's the contract your apps and users operate against.
What "write-back" looks like when it's designed, not bolted on
When people say "write-back," they often mean "update a row in the warehouse and hope a sync process catches up." Foundry's docs describe a more explicit execution model:
- Action types exist as configurable entities.
- Actions can be function-backed (i.e., implemented by code in Foundry Functions).
- Actions can have side effects, including webhooks and notifications, so you can push the change outward.
- Actions can be monitored, logged, and in some cases undone or reverted.
That last bullet is the operational clue: if you let humans change business state from the "data platform," you need the safety rails that mature operational systems have.
Here's a concrete example I've seen repeatedly in manufacturing/logistics-style workflows:
| Object | Common properties | Typical action | Common side effects |
|---|---|---|---|
Shipment | status, carrier, ETA, priority, exception_reason | RescheduleShipment | webhook to TMS; notification to planner |
WorkOrder | state, asset_id, planned_start, parts_required | ApproveRepair | notification; downstream reservation call |
Invoice | amount, vendor, terms, due_date | PutOnHold | webhook to AP system; audit justification |
Nothing in that table requires magical UI. It requires a platform that treats actions, permissions, and audit as native.
Ontology as an integration abstraction (why apps don't shatter every quarter)
Point-to-point integration couples code to upstream schemas: table rename, field split, API version bump—someone's on pager duty.
The Ontology gives you a stable interface:
| Layer | What developers code against | What changes when systems change |
|---|---|---|
| App code | Employee, Shipment, Invoice objects + actions | ideally nothing |
| Ontology mappings/types | mapping from source datasets → object properties/links | updated by platform/data engineering |
| Systems of record | SAP tables, Salesforce objects, custom APIs | can change frequently |
This is not unique in principle (it's close to domain-driven modeling and, in places, CQRS), but Foundry pushes it into the product surface area: object types, link types, action types, and functions are explicit platform concepts.
The real trade-off: the modeling tax is political, not technical
The Ontology's cost isn't "it's hard to create types." The cost is that someone must win the argument over what an Order is.
I use this checklist when I'm judging whether the Ontology approach is worth it:
| Question | If "yes" | If "no" |
|---|---|---|
| Do you need edits/approvals/audit trails in the same tool people use to analyze? | Ontology-style systems shine | warehouse + BI is usually enough |
| Do you have multiple systems claiming "source of truth" for the same entity? | object identity + links pay off | MDM + warehouse may suffice |
| Are operational mistakes expensive (safety, compliance, downtime, revenue leakage)? | governance features are worth the friction | you'll resent the overhead |
| Can you get cross-functional agreement on definitions? | you can amortize the model | you'll build a brittle pile of exceptions |
If your world is mostly dashboards and one clean source system, the Ontology is a heavyweight solution. If your world is messy operations and regulated workflows, it's a credible moat—because the moat is not the UI; it's the combination of typed operational entities + action execution + governance that survives reality.