필사 모드: The Palantir Ontology — reading, from the official docs, the operational layer that puts "action" on top of data

What the word "ontology" points at

In Palantir's documentation the Ontology is not an academic term but a layer of the product. The overview defines it:

The Ontology is an operational layer for the organization. The Ontology sits on top of
the digital assets integrated into the Palantir platform (datasets and models) and
connects them to their real-world counterparts, ranging from physical assets like
plants, equipment, and products to concepts like customer orders or financial transactions.

A data lake holds tables; a model registry holds models. The Ontology is the layer above both that attaches real-world names such as "plant", "order" and "transaction", and defines what can be done with each. The stated purpose of the investment is one sentence: "The goal of investing in the Ontology is to facilitate better decision-making in an organization at scale."

This post follows how that layer is put together using only sentences from Palantir's official documentation (palantir.com/docs/foundry). Nothing that is not in the docs is written here.

Six pieces — semantics and kinetics

The overview splits the Ontology's components into two groups: those that define the organization's semantics and those that define its kinetics.

Defining the semantics of your organization happens by mapping existing datasources
into objects, properties, and links in the Ontology.

The kinetics of the organization—enabling change while complying with organizational
controls and governance—are defined in the Ontology using action types and functions.

Copying the definitions from the core-concepts page gives six pieces.

For people who know databases the docs give a mapping: datasets correspond to object types, rows to objects, columns to properties, joins to link types. So the first three pieces (objects, properties, links) are "a well-organized schema". Where Palantir diverges from other data platforms is the last three: on top of the schema it places, in the same layer, the actions people may take and logic written in code.

The road from a dataset to an object

Where does an object type get its data? The object-types overview names two routes.

Objects are created and displayed in user applications by adding backing datasources
or configuring actions that create objects of an object type in Ontology Manager.

That is, (1) attach an existing dataset as a backing datasource, or (2) create objects only through actions, with no dataset. The docs give the example of attaching the employee directory to an Employee object type, and conversely note that if every object will be created through actions, you can create the object type without a backing datasource.

Indexing datasets into objects is the job of Funnel in Object Storage v2.

Funnel reads data from Foundry datasources (such as datasets, restricted views, and
streaming datasources) and user edits (from Actions) and indexes these data into
object databases. Funnel also ensures that indexed data is kept up-to-date as the
underlying datasources update.

The important phrase is that "user edits (from Actions)" are an input alongside the datasets. A value from the source table and a value a person changed on screen enter the same index. So when they collide, who wins?

The rules when an edit collides with the source

This is what makes the Ontology different from a read-only view, and the docs state the rule.

the final state of an object is always determined by the user edits applied to it,
regardless of any future datasource updates for edited properties in the same object.

Under the default strategy the user edit always wins. A property a person changed is not overwritten even if the backing dataset changes later. Properties that were not edited receive source updates as usual ("An unedited property receives data update from the input datasource, and it is applied to the object").

Deletion is not an edit: "Deletions are not considered an edit. Once a deletion is applied, the object is no longer visible regardless of datasource state." And if an object with the same key is created again, it does not inherit the earlier edits ("If the object is later recreated, it will not inherit the previous edits").

Edit-only properties are stronger still. Even under the alternative "apply most recent value" strategy, "user edits will always apply regardless of the timestamp on the input datasource".

Why this rule? If an operator marks a piece of equipment "inspected" and overnight the source system pushes down the old state and erases the mark, the Ontology becomes a screen nobody trusts. The edit-wins rule protects that trust. In exchange a value that really changed at the source can be ignored, so deciding which properties are editable becomes the heart of the design.

Actions — transaction, validation, side effects

The action-types page frames an action this way:

An Action in Foundry is a single transaction that changes the properties of one or
more objects, based on user-defined logic.

One action is a bundle of changes to objects, properties and links; parameters standardize input; submission criteria check permissions. The docs' example validates "that authorized employees such as those working in human resources can perform the action" and includes "rules for how to automatically create a link between" related objects on submission. Side effects include notifications and webhooks; the example is a notification "that will notify the old and new manager of the change".

And this sentence says why actions live in the Ontology:

the same action logic and validations can be made available across all user-facing
applications, ensuring consistent edits.

Not a "save button" written separately in each screen, but an action defined once in the Ontology and used by every screen with the same validation. The scale limit is documented too: one action can edit 10,000 objects by default, with higher limits available on request.

Functions — logic that runs on the server

The functions page pins the languages to two: "The languages supported by functions are TypeScript and Python." Functions treat the Ontology as first class.

This includes support for reading the properties of various object types, traversing
links, and flexibly making Ontology edits.

The four uses the docs list: returning object sets or values to Workshop (Palantir's app builder), "expressing a complex edit to the Ontology that updates many objects through a function backed action", displaying transformed values in a derived column, and aggregating for charts. The execution model is "executed on the server side in an isolated environment", and for use with language models results can be streamed incrementally.

Interfaces — polymorphism

Interfaces let several object types share one shape. The docs' example is a Facility interface with common properties such as location and name, implemented by Airport, Manufacturing Plant and Maintenance Hangar. Then "workflows can interact with Airport, Manufacturing Plant, and Maintenance Hangar object types, either in aggregate or independently", and a new type joins existing workflows the moment it implements the interface. Interface properties are "defined locally on the interface (recommended) or using shared properties", and one object type can implement several interfaces.

Scale and architecture — in numbers

The figures the Object Storage v2 documentation states:

The design point of v2 is one sentence: "by separating the subsystems responsible for indexing and querying data, Object Storage v2 can scale horizontally more easily to meet future needs." The indexing side and the query side are decoupled.

Where models and LLMs attach

The models page lists four steps for operating a model on the Ontology: create the model, configure a direct model deployment, "publish a simple wrapper function for your model", then use that function for live inference in user apps such as Workshop. A model's results are defined "in terms of real-world concepts (properties of an object type)" — a prediction becomes a property of an object rather than a separate technical artifact.

The LLM side is AIP. The AIP Logic definition is "a no-code development environment for building, testing, and releasing functions powered by LLMs"; such a function takes "Ontology objects or text strings" as input and can "return an output (objects and/or strings) or make edits to the Ontology". So logic produced by an LLM enters the Ontology as the same piece, a function, and its edits travel the same path as actions. The AIP overview says these tools build "production-ready AI-powered workflows, agents, and functions on top of the Ontology".

For developers, the SDK

The Ontology SDK (OSDK) page lists the routes: "The OSDK supports npm for TypeScript, pip or Conda for Python, Maven for Java, and OpenAPI spec for any other language." It generates functions and types from the Ontology, and the token is "scoped only to the ontological entities you want your application to access". Since an object type becomes a type in code, regenerating the SDK after changing the Ontology becomes part of the development flow.

Reading it again as an engineer

In one line, the Palantir Ontology is "schema + edit rules + action definitions + logic, in one layer". It sounds unfamiliar, but these are things most internal systems already have, scattered: tables in a warehouse, save-button validation in each app, batch logic in a scheduler, predictions in a notebook. The Ontology gathers them in one place and defines there "who may change which object, and how".

What the docs alone cannot tell is also worth writing down. How the edit-wins rule plays out in real operations, which workloads hit the 2,000-property or 10,000-edit limits, and what Funnel's update latency is are not in the documentation. This post stops where the official documentation stops.

Sources

Every quotation in this post comes from the Palantir documentation below (retrieved 11 September 2026, all responding 200).

이 글의 인용은 전부 아래 팔란티어 공식 문서에서 가져왔다(2026년 9월 11일 열람, 응답 200 확인).

• Ontology overview
• Ontology core concepts
• Object types overview
• Object backend (Object Storage v2) overview
• Object edits overview
• How user edits are applied
• Action types overview
• Functions overview
• Interfaces overview
• Models in the Ontology
• AIP overview
• AIP Logic overview
• Ontology SDK overview
• Ontology Manager overview