What Does Palantir's Ontology Add Beyond a Semantic Layer?

本文另有中文版：Palantir Ontology 比語意層多了什麼？

If you spend your week in dbt’s Semantic Layer, LookML or a Snowflake semantic view, “ontology” invites a quick question: isn’t that just a semantic layer with a new name?

Palantir’s own documentation answers in one sentence. The architecture page says: 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.

Palantir’s fiscal year 2025 10-K makes a related claim. Ontology generally refers to “the systematic mapping of data to meaningful context,” it says, and Palantir’s version goes far beyond that by folding the data, logic and actions behind a decision into one representation of the organization.

Together the two statements leave a question. Beyond what, exactly?

What follows traces one line: how data becomes objects, how one submitted action changes those objects, who has permission to touch them, and what can be looked up afterward. The mechanisms described below come from Palantir’s documents. They are not tested here.

Data becomes objects before a decision has anything to change

The ontology-overview page opens with a definition: “The Palantir Ontology is an operational layer for the organization.” It sits on top of datasets, virtual tables and models already connected to the Palantir platform. It links them to real-world counterparts, which range from plants, equipment and products to customer orders and financial transactions. In many settings, the page says, it serves as a digital twin of the organization.

The why-ontology page makes the point sharper: “The Ontology represents the decisions in an enterprise, not simply the data.” Traditional data architectures, it argues, do not capture the reasoning behind a decision or the actions that follow, and conventional analytics architectures stay disconnected from operations. So the unit being modeled is the decision, not just the data.

That page breaks each operational decision into four components:

• Data: the information used to make the decision.
• Logic: the heuristics and computation that evaluate it.
• Action: the orchestration and execution of the chosen decision.
• Security: the assurance that the decision complies with operational policy.

On the data-and-logic side, the core-concepts page defines each building block in a sentence. “An object type is the schema definition of a real-world entity or event.” One object is one instance, and a collection of objects is an object set. A property defines a characteristic of an object type, and a link type defines a relationship between two object types. An interface describes the shape and capabilities of an object type so that different object types can be handled the same way. A function is code-based logic that takes inputs and returns an output, and can take objects and object sets as inputs, and can be used by action types and applications.

How does an object come to exist? The documentation says objects are created by adding backing datasources to an object type in the Ontology Manager. To build an Employee object, you first connect an employee directory and related enterprise data to the object type. In a data warehouse the unit is the table and the column. Here it is the object, the property and the link.

Actions and permissions: what an action must pass, and who can see what

Once a decision is made, someone has to act on it. The core-concepts page defines an action type as the schema definition of a set of changes or edits to objects, property values and links that a user can take at once, including the side effects triggered on submission. The action-rules page lists five kinds of rule: create an object, modify an object, delete an object, create a many-to-many link, and delete a link. When rules are not enough, an action type can call a function to define a more complex change.

Whether an action can be submitted depends on submission criteria. The documentation says these conditions “determine whether an action can be submitted.” They were formerly called validations. They let business logic be encoded into data-editing permissions, protecting data quality and editing governance in the Ontology.

What happens after submission runs through side effects, which let data leave Foundry and connect to existing organizational processes. The documentation calls this “decision orchestration.” One kind of side effect is a webhook, which sends a request to Salesforce, SAP or any configured HTTP server, typically to modify data there. What happens when the outside system succeeds or fails is the subject of the next piece.

Who can see what is governed by a separate set of rules. The ontology-permissions page states: “To see objects, you must hold View permissions on the object type and access to the data.” Both are required.

• Object-level security can be set on the object type itself, independent of the backing data sources. Restricted views tie row-level access on a dataset to the objects built from those rows.
• Property-level security runs on markings: Foundry checks each property value against its security markings.
• Markings are all-or-nothing. A user must be a member of all markings applied to a resource. A resource derived from a marked file, folder or Project inherits the marking unless it is explicitly removed.
• Deletion has its own limit: a user who cannot view an object’s full set of properties cannot delete it.
• Roles are the central permissioning model in the Ontology, and can be granted at the Ontology level or on a single resource.

People and AI agents fall under the same rules. The documentation says every operation by a human or an agent must follow rigorous role-, marking- and purpose-based controls, and that tool invocations depend on access to the underlying objects, properties and links.

What about actions that AI triggers? The why-ontology page uses a fictional company, Onyx, as its example. Onyx gives some AI agents access to a small set of actions. In the example’s default case, actions like changing the status of a work order or pushing a reallocation plan can only be staged by the AI and handed to a human for final review. The example then says Onyx can carefully choose to let trusted, well-tested AI processes close the action loop automatically, with no human review.

That is the setup of a fictional example. It is not a rule for every entry point.

So actions and permissions belong together. The criteria decide whether a submission can go through, and permissions decide who can see an object and who can act on it.

What record an execution leaves

Where the edits go. Edits a user makes through an action are not written back to the dataset backing the object type. The documentation says this keeps both the original data and the edited data available for analysis. Where the edits land is the subject of the next piece.

The action log. An action type can be given an action log. Once configured, each successful submission adds an entry recording the submitting user’s Multipass ID, a timestamp, and the primary keys of the objects edited. The documentation says the log is meant to answer “what changed, by whom, and when?”

Three limits matter:

• For the edited objects, properties other than the primary key are not supported. So the log tells you which objects were touched. It does not hand you before-and-after values for every field.
• A function-backed action appears in the action log only if the backing Ontology edit function has edits provenance configured.
• A fuller edit history for a single object comes from a separate feature that does not reach back before it was turned on. The next piece covers it.

Decision lineage. Under Data, the why-ontology page says that when a decision was made, against which version of enterprise data, and through which application is “automatically captured and securely accessible” to human developers and agents. It calls this “decision lineage.” This is the goal Palantir describes. On the platform, several tools each answer a different question:

• Data Lineage is an interactive tool for seeing how data flows through Foundry.
• Platform audit logs, as the documentation describes them, give a comprehensive record of every action taken in Foundry, so security teams can detect threats, investigate incidents and ensure compliance.
• The action log covers the submissions of one action type.

They answer different questions. Whether together they can reconstruct the full history of a given decision depends on which are turned on and which fields they record. So before accepting “traceable,” ask which kind of record is meant.

Reading it: Palantir says the difference is integration

Semantic modeling, permission systems and audit trails each exist as product categories already. A single feature can be found elsewhere too. The next piece notes that Looker’s Action Hub does write back to external systems.

Back to the two statements at the start. The 10-K says Palantir’s version goes far beyond the ordinary meaning, and the architecture page says a semantic layer cannot do the fourfold integration. On the reading built here, the part beyond is Action, Security and decision lineage, plus the integration that ties them into one model. The reading rests on those two Palantir documents. It does not say other products cannot do these things.

Next time you read an “integration” claim from Palantir or anyone else, three questions help. Where is the data and logic for the decision defined? Who can submit, and under what conditions? What kind of record can you look up afterward?

Next in this series, the action piece: When a Palantir Action Succeeds, What Has Changed?.

Frequently asked questions

Is Palantir’s Ontology a database?

Palantir’s documentation defines the Ontology as an operational layer for the organization. It sits on top of datasets, virtual tables and models already connected to the platform and links them to their real-world counterparts. That is Palantir’s own product definition, not an independent test, and it does not mean the underlying data stores go away.

How is Palantir’s Ontology different from a semantic layer?

Palantir’s architecture page says the Ontology is not a semantic layer, because the fourfold integration and operationalization of data, logic, action and security cannot be done with a thin semantic layer or a monolithic design. That is Palantir’s claim. It does not mean other products cannot do it.

What are Actions in Palantir’s Ontology?

An action type defines the set of changes a user can make at once. It carries submission criteria and side effects, such as a webhook that sends a request to an external system. An action type can also be given an action log, which records the submitter, the time and the primary keys of the objects edited in each successful submission.

Does an AI-triggered action always need human review?

That would be too broad a reading. Palantir’s documentation uses a fictional company, Onyx, as an example. In its default case, AI can only stage actions for a human to review. The example also says Onyx can choose to let trusted, well-tested AI processes close the action loop without human review. That is the example’s setup, not a rule for every entry point.

Scope and version

• Every Palantir docs page cited here is the version read in August 2026. Palantir’s pages carry no date, so a page read later cannot be used to infer what it said in August.
• Quotes from the 10-K carry over from the August 2026 reading.
• The October 16, 2026 revision changed structure and the wording of qualifications. It did not update the data.