Palantir Ontology SQL Functions: Unify Business Logic Across Systems

Same Delayed Shipment, Three Different Lists

A single delayed shipment triggers three different alert lists across the supply chain dashboard, the customer service workbench, and an automation system. The supply chain flags every order on the shipment, customer service prioritizes only orders whose committed delivery date is at risk, while the automation system waits until an order is actually overdue. The root cause is not a data discrepancy but a logic discrepancy: each system encodes its own interpretation of "orders predicted to miss their commitment." When business rules change — split shipments, ad‑hoc transfers, revised delivery dates — these independent implementations diverge further.

Querying Orders and Shipments with Ontology SQL

Foundry's Ontology lets enterprises model customers, orders, and shipment batches as object types with links expressing many‑to‑many relationships (an order can be split across batches; a batch can contain items from multiple orders). Ontology SQL understands these object types, interfaces, and links directly. Developers write queries that join through the predefined link tables in the Ontology Manager, avoiding the need to maintain separate join tables outside the ontology. The dialect supports a subset of Spark SQL; suitable queries run on an in‑memory compute path against object storage, while more complex queries fall back to Spark execution. The engine handles the traversal of ontology relationships, but the business definition of "predicted miss" — e.g., comparing undelivered quantity, estimated delivery date, and the customer's current committed date — must be expressed explicitly in the query.

Publishing Queries as Reusable Functions

Instead of copying the same SQL into a dashboard, a workbench, and an automation script, developers can publish the query as an Ontology SQL Function in SQL Studio. The function takes parameters (e.g., a shipment batch ID) and returns a result set of orders, customers, committed dates, and estimated delivery dates. The function does not mutate data or send notifications; those actions remain the responsibility of downstream Actions, Automate, or custom workflows. Once published, the function is callable from Workshop, Actions, Automate, and the Ontology SDK. Each consumer can present the results differently — the dashboard shows five at‑risk orders, the workbench groups them into three customers — but the underlying judgment comes from a single, versioned function.

Versioning Rules Without Updating Every System

When a customer agrees to move a committed date from Thursday to Friday, the "predicted miss" status for that order may change. However, the original commitment date must be retained for later compliance reporting. The function can encapsulate both dates and the logic that decides which date governs the alert. Updating the function's logic while keeping its input/output signature stable allows teams to test the new rule (e.g., in the customer service workbench) before rolling it out to automation. Ontology Manager tracks function versions; consumers can pin a specific version or declare a version range. Pinning is recommended for high‑stability workflows because version ranges may automatically pick up newer versions.

The net effect is not merely deduplicated SQL but the elimination of repeated reconciliation, investigation, and correction cycles that arise when business rules fork across systems.

References: Palantir — November 2026 Announcements: Ontology SQL and SQL Functions are GA (12 Nov 2026) 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 Palantir — Core Concepts: Objects, Properties, and Links in the Ontology