Palantir Ontology SQL Functions: Unify Business Rules Across Systems

Introduction

On November 12, 2026, Palantir announced the general availability of Ontology SQL and Ontology SQL Functions in Foundry. Developers can now query business objects and relationships directly in the ontology, and publish those queries as parameterized functions that multiple applications and workflows can reuse. This update addresses a long-standing enterprise problem: when the same business rule is implemented in three different systems, it inevitably diverges into three versions.

The Problem: One Shipment Delay, Three Different Lists

A shipment originally due Wednesday slips to Friday. The supply chain dashboard flags all related orders red. The customer service workbench filters a list of customers to contact proactively. The automation system sends no alert at all. All three systems look at the same delayed shipment but produce different conclusions:

Some orders are promised for Saturday delivery; Friday arrival is not a breach.

Other orders are split into batches; the remaining items are in this shipment, and the customer expects everything by Thursday.

The automation system only triggers on "already overdue" status, so it would not flag the Thursday-deadline order until after Thursday passes.

Shipment delay ≠ order breach ≠ customer alert. Each state has its purpose, but different systems fail to distinguish them explicitly. Worse, rules change over time — order splitting, ad-hoc reallocations, customer renegotiated dates — causing initially aligned lists to diverge immediately. The enterprise needs to unify not the displayed numbers, but the underlying business judgment: at a given point in time, using the same conditions, which orders are projected to miss their committed delivery date.

Ontology SQL: Querying Objects and Relationships Directly

In Foundry, enterprises model customers, orders, and shipment batches as object types, with links expressing relationships. An order can be split across multiple batches; a batch can contain items from multiple orders — a many-to-many relationship. Ontology SQL can query object types, interfaces, and many-to-many links . For links already defined in Ontology Manager, developers reference the corresponding link table in SQL and join to find orders and customers affected by a specific batch. No separate association table detached from the ontology definition is needed.

Finding linked orders is only step one. The real decision — whether to alert — depends on undelivered quantities, estimated delivery completion date, and the customer's current valid commitment date. If only the batch's estimated warehouse arrival time is available, without the final-mile estimated delivery, the system cannot assert when the customer will receive the goods. Ontology SQL supports a subset of the Spark SQL dialect; suitable queries access object storage directly via an in-memory compute path, while more complex queries fall back to Spark execution. It solves how to traverse ontology relationships to fetch data , but the business semantics must still be explicitly written by developers, not guessed by the engine.

Publishing Queries as Functions: Shared Logic Across Dashboards, Workbenches, and Automation

Previously, the "projected late orders" calculation lived separately in the supply chain dashboard, the customer service workbench, and the automation task. Even with a common data source, independently maintained SQL could drift. Now, developers write the query in SQL Studio, define the shipment batch ID as a parameter, and publish it as an Ontology SQL Function. Callers pass a batch ID; the function returns the projected late orders, associated customers, committed delivery dates, and estimated completion dates — all by a single, reusable rule. The function returns data only; it does not modify orders or send notifications. Those actions remain the responsibility of Actions, Automate, and other downstream processes.

After publishing, Workshop, Actions, Automate, and the Ontology SDK can all invoke the function. The supply chain dashboard uses the result to evaluate reallocation options; the customer service workbench aggregates by customer to decide whom to contact; the automation flow decides whether to create a task. The three systems may present different views — e.g., the dashboard shows five late orders, while customer service only contacts three customers — but the underlying "projected breach" judgment comes from the same reusable function. One customer may have multiple orders, so order count and customer count differ naturally. As long as order-level results are retained, the discrepancy is explainable. The value of functionization is not to eliminate all differences, but to make every difference traceable to clear business logic.

Rule Changes Without Touching Every System: Versioned Functions

Harder than initial alignment is handling rule changes. Suppose the second customer agrees to move the commitment date from Thursday to Friday, while the estimated completion stays Friday. That order drops out of the "projected breach" alert list. Yet during month-end fulfillment review, the team may still need to ask: was the original Thursday commitment met? Therefore, "original commitment date" and "latest customer-confirmed date" must not simply overwrite each other. Which date the alert uses, and what status counts as customer confirmation, must be explicit business conditions. Otherwise, a system might prematurely withdraw an alert because an internal plan date shifted before the customer actually agreed.

When the rule is encapsulated in a function, developers update the judgment logic inside the function while keeping inputs and output fields stable. They can verify the new logic against both renegotiated and unconfirmed orders. Foundry's Ontology Manager shows function published versions; Workshop, Actions, and Automate can either pin a specific version or depend on a version range. Teams can let the customer service workbench validate the new rule first, then decide when to switch the automation flow — without updating all applications simultaneously. Note: version ranges may automatically pick up qualifying new versions; for stability-critical flows, pinning a version remains prudent.

Conclusion

The ontology gives orders, batches, and customers a shared relationship definition. Ontology SQL makes those relationships directly queryable. SQL Functions then turn the business judgment behind the query results into logic that multiple systems can call. Next time a shipment is delayed, the warehouse still sees all affected orders, customer service still contacts only at-risk customers, and automation still runs on its own cadence — but when they answer the same question, they no longer each write their own answer. What enterprises truly reduce is not just duplicate SQL, but round after round of reconciliation, investigation, and correction after rules diverge.

References

Palantir | November 2026 Announcements — Ontology SQL and SQL Functions are GA (2026-11-12)

Palantir | Ontology SQL: Querying Object Types, Interfaces, and Many-to-Many Links

Palantir | Ontology SQL Functions: Parameters, Publishing, and Cross-Application Invocation

Palantir | Version Range Dependencies for Functions: Function Version Dependencies

Palantir | Core Concepts: Objects, Properties, and Links in the Ontology