Palantir Ontology: The AI Decision OS Unifying Data, Logic, Actions & Security

What Is Ontology

Ontology is Palantir's core business semantic operational layer, introduced as the platform's operational layer and often serving as an organization's digital twin. Palantir's official documentation defines it as the integration of semantic elements (objects, properties, links) and dynamic elements (actions, functions, dynamic security). The documentation explicitly states: "The Ontology is not a 'semantic layer'; the fourfold integration and operationalization of data, logic, action, and security cannot be accomplished with a thin semantic layer or a monolithic design." A thin semantic layer only defines what data looks like, but cannot carry what can be done with it or who has permission to do it. Ontology's true definition is the unified integration of data, logic, action, and security.

In Foundry, Ontology's technical composition is divided into three layers:

Language (语言层) : Modeling semantic objects, links, and actions.

Engine (引擎层) : Modular engines supporting read/write, including high-concurrency SQL queries, real-time subscriptions, and atomic transaction write-back.

Toolchain (工具链层) : OSDK and DevOps tooling.

Palantir's core philosophy: refuse to let AI read underlying SQL or data lakes directly; force translation through the business semantic layer. The goal is not prettier BI reports but an "insight → decision → action → feedback" closed loop, fundamentally opposing the traditional data platform approach of "build lake first, model later."

Three Core Concepts

Object Types (对象类型)

An Object Type defines a real-world entity: order, device, employee, flight, drug batch. Its technical composition is a display name + a set of typed properties + a primary key + one or more backing datasets (underlying data sets). Key point: an Object Type is not an independent database but a semantic mapping "grown" on top of Foundry Datasets. Backing datasets can be Parquet tables, virtual tables, or model outputs. The Object Type uses the primary key to abstract data rows into objects directly operable by applications and LLMs. Property column names must exactly match backing dataset column names, otherwise indexing fails.

Link Types (链接类型)

A Link Type defines directed relationships between objects: Employee → Employer, WorkOrder → Flight. Technically two kinds: one-to-one/one-to-many foreign key mappings (based on columns in backing datasource), and many-to-many relationships requiring a separate join table as backing datasource. Link Types are critical for AIP Agents to traverse the business graph. In the Object Query Tool, an LLM can hop along Link Types from one object to related objects, enabling graph-like semantic reasoning.

Action Types (动作类型)

An Action Type is a transactional change unit: it can modify multiple objects' properties and links simultaneously, with parameter validation, permission control, and side effects (notifications/webhook write-back). Example: an Assign Employee action can simultaneously modify a role property, automatically create a Link to a Manager, and trigger downstream notifications. The underlying implementation can be a simple rule edit or a Function-backed Action backed by a full TypeScript or Python function carrying arbitrarily complex business logic.

In one sentence: Objects are nouns, Links are connecting words between nouns, Actions are verbs. Semantics plus dynamics make a complete decision model.

Layered Architecture

The full stack is clearly layered: the application layer calls Ontology via OSDK or API; the Ontology layer packages semantic elements, dynamic elements, and security policies into a unified interface; the data layer's Foundry Datasets are the actual storage medium.

Differences from Knowledge Graphs, Data Platforms, and Data Lakes

Many Chinese technical articles mistakenly equate Palantir Ontology with "Palantir's Neo4j" or "advanced data platform" — a fundamental misreading.

Misconception 1: "Ontology is a graph database." Ontology's underlying layer is Foundry Dataset + Object Storage microservice (now OSv2), not any graph database. Link Types are semantic abstractions based on foreign keys or join tables; physical storage remains structured datasets.

Misconception 2: "Action directly modifies raw data." Edits write to independent writeback/materialized datasets; raw data is preserved, supporting audit and rollback.

Misconception 3: "AIP is just RAG." AIP's core is Tool/Function Calling + Ontology constraints; RAG (Retrieval Context) is only one supplementary capability.

Practical Case: Airbus Skywise Aviation Operations Ontology

This is a public flagship case from Palantir's website Impact section. Skywise integrates data from multiple aviation sources: work orders, spare parts consumption, component data, fleet configuration, onboard sensor data, and flight plans. Official disclosed scale: 300+ aircraft connected, using real-time data for predictive maintenance and operational optimization; 55,000+ global users making data-driven decisions.

Traditional pain point: aircraft maintenance data scattered across airline MRO systems, manufacturer engineering systems, supplier supply chain systems. Answering "when does this aircraft's engine need maintenance" required manual alignment across at least three systems. Palantir's architecture docs explicitly use an airline example: unify fragmented assets like flights, aircraft, crew rosters, schedule optimizers into Ontology to support daily flight operations and long-term planning.

Modeling

Flight object links via flight_id foreign key to Aircraft, FlightSensor, Route, Airport, Carrier.

Code Practice: OSDK Queries and Action Calls

Below code uses standard syntax patterns from official OSDK documentation.

Query recent flights for an aircraft (TypeScript OSDK)

// 官方标准查询模式
import { FoundryClient } from '@osdk/client';
import { Flight, Aircraft } from '@your-stack/sdk';

const client = new FoundryClient();

// 查询单个 Flight 对象
const flight: Osdk.Instance<Flight> = await client(Flight).fetchOne(
  "AA100-20260830"
);

// 沿 Link 遍历到关联的 Aircraft
const aircraft = await flight.assignedAircraft.fetchOne();
console.log(`航班 ${flight.flightId} 由 ${aircraft.tailNumber} 执行`);

Query all pending maintenance work orders for an aircraft (Python OSDK)

# 官方 Python OSDK 标准模式
from foundry_platform_sdk import FoundryClient

client = FoundryClient()

# 获取单个 Aircraft 对象
aircraft = client.ontology.objects.Aircraft.get(
  "B-737-123"
)

# 沿 Link 遍历到所有关联的 Flight（flight_id 外键）
flights = aircraft.scheduledFlights.fetch()

for flight in flights.data:
    print(f"航班: {flight.flightId}, 状态: {flight.status}")

Execute Action: Schedule Maintenance for Aircraft

# 调用 ScheduleMaintenance Action
result = client.ontology.actions.ScheduleMaintenance.apply(
    aircraft={
        "$apiName": "Aircraft",
        "$primaryKey": "B-737-123"
    },
    maintenance_type="engine_overhaul",
    scheduled_date="2026-09-15",
    reason="sensor anomaly detected"
)

Key mechanism: after this Action executes, edits write to an independent writeback dataset; the original backing dataset is not directly modified. This is the core architectural difference from traditional direct-database-write architectures. Downstream Transforms can consume the writeback dataset, forming an "edit → materialize → flow back to master data" closed loop.

AIP Integration: Letting LLMs Call This Ontology

In AIP Logic, configure a Use LLM block mounting two Tools:

Object Query Tool : bound to Aircraft type, allowing LLM to query "sensor data for this aircraft".

Apply Action Tool : bound to ScheduleMaintenance, configured as "execute after human confirmation".

Engineer dialogue example:

工程师：B-737-123 的发动机传感器最近有什么异常？

LLM（调用 Object Query Tool）：
  → 查询 FlightSensor 时间序列
  → 过去 7 天振动值超过阈值 3 次

工程师：需要检修吗？

LLM（调用 Function Tool 查询维修模型）：
  → 模型预测：未来 30 天故障概率 78%
  → 建议：排入 engine_overhaul

工程师：执行吧

LLM（触发 Apply Action Tool，等待人工确认）：
  → ScheduleMaintenance(B-737-123, engine_overhaul, 2026-09-15)

Throughout the process, the LLM never touches SQL or invents field names. All reads and writes go through type-safe OSDK interfaces and permission-checked Actions.