Palantir Says Its Ontology Is Not a Semantic Layer

本文另有中文版：Palantir 文件自己說：Ontology 不是資料庫，也不是 semantic layer

To anyone who spends the week inside dbt’s Semantic Layer, LookML, or a Snowflake semantic view, “ontology” sounds like Palantir’s word for the same job, dressed up. Palantir’s own architecture documentation (read in August 2026) disagrees with that reading in one sentence: 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. That line comes from the arch-ontology-system page. Palantir’s fiscal year 2025 10-K makes a second, related claim: “Ontology generally refers to the systematic mapping of data to meaningful context”, and Palantir’s version “goes far beyond the traditional concept” by folding the data, logic, and actions behind a decision into one representation of the organization. Two documents, two claims, and one open question: beyond what, exactly?

There is a third oddity, and Palantir’s own documents put it in plain view: they do not agree on how many parts the Ontology has. The ontology-overview page splits it in two — semantic elements (objects, properties, links) against kinetic elements (actions, functions, dynamic security). The why-ontology page splits it in four — Data, Logic, Action, Security. The arch-ontology-system page uses the same four, and of the Palantir pages quoted here, it is the only one that calls the split “fourfold”. A January 2024 Palantir blog post lists three — data, logic, action. An October 2022 Palantir blog post lists six required services, among them security architectures. This piece uses the four-part version, for one reason only: it is the one Palantir’s own documentation labels fourfold. What follows is one framing among several Palantir has used, not the framing.

Palantir’s Documentation Defines the Ontology as an Operational Layer

Palantir’s ontology-overview page opens with a plain claim: “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, and links them to real-world counterparts — physical assets such as plants and equipment, and less physical ones such as customer orders or financial transactions. Palantir describes this role as a digital twin of the organization, containing both semantic elements (objects, properties, links) and kinetic elements (actions, functions, dynamic security).

The why-ontology page states the same idea more sharply: “The Ontology represents the decisions in an enterprise, not simply the data.” Traditional data architectures, the page argues, do not capture the reasoning behind a decision or the actions that follow it; conventional analytics architectures do not connect computation to how operations actually run. Closing what Palantir calls the “action loop” — executing a decision the moment it is made, rather than recording it afterward — is what the documentation treats as the line between an operational system and an analytical system. Elsewhere on the same page, Palantir reaches for a grammar metaphor: if the data elements in the Ontology are “the nouns” of the enterprise, the actions can be considered “the verbs,” and an Ontology-driven workflow brings the two together into complete sentences.

Palantir Splits Every Operational Decision into Four Components

The why-ontology page states that Palantir models every operational decision as comprising four components: “Data : The information leveraged to make the decision. Logic : The heuristics and computational processes that evaluate a decision. Action : The orchestration and execution of the chosen decision. Security : The assurance that the decision complies with operational policies.” A fifth idea sits alongside those four in the same document: an end-to-end “decision lineage” — when a decision was made, against which version of enterprise data, and through which application — is automatically captured and made securely accessible to both human developers and agents.

This piece organizes the rest of its argument around four terms — semantic, action, permission, lineage — that are not Palantir’s own vocabulary. They are a rewording, mapped as follows: semantic covers Data plus Logic, action covers Action, permission covers Security, and lineage covers decision lineage. The table below sets out that mapping term by term, together with where each piece falls inside the ontology-overview page’s two-way split between semantic and kinetic elements.

The Semantic Layer Maps Data Sources onto Real-World Objects

Palantir’s core-concepts page gives each semantic building block a one-sentence definition. “An object type is the schema definition of a real-world entity or event.” A property is “the schema definition of a characteristic of a real-world entity or event.” A link type is “the schema definition of a relationship between two object types.” An object set is “a collection of multiple object instances”. An interface “describes the shape of an object type and its capabilities”, providing what the page calls object type polymorphism — letting object types that share a common shape be modeled and interacted with consistently. A function is “a piece of code-based logic that takes in input parameters and returns an output”, and is, in the page’s words, natively integrated with the Ontology: functions can take objects and object sets as input, read property values, and be used across action types and applications built on the Ontology.

The contrast with a data warehouse is not a matter of scale; it is a matter of what gets modeled. A warehouse maps rows and columns. The semantic layer, in this article’s sense of the term, maps datasources into objects, properties, and links — entities and events, not tables and fields. Objects, the documentation states, “are created and displayed in user applications by adding backing datasources to an object type in the Ontology Manager”; building an Employee object means connecting an employee directory and related enterprise data to that object type. One further piece sits above this: Roles, “the central permissioning model in the Ontology”, which can be granted either at the Ontology level or on an individual resource.

The Action Layer Ties Submission Criteria, Side Effects, Writeback, and Logging Together

Core-concepts 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 effect behaviors triggered on submission. The action-rules page lists five kinds of rule an action type can apply: create an object, modify an object, delete an object, create a many-to-many link, and delete a link.

Whether an action can be submitted at all comes down to submission criteria — “formerly known as validations” — described as “the conditions that determine whether an action can be submitted.” Actions can only be submitted if every submission criterion is met, and the mechanism, Palantir states, supports encoding business logic directly into data-editing permissions to protect Ontology data quality and editing governance.

What happens after submission runs through side effects, which “enable you to send data out of Foundry to integrate with existing organizational processes” — a pattern Palantir’s documentation calls “decision orchestration.” One kind of side effect is a webhook, “a concept in Data Connection that enables sending a request to an external system, such as Salesforce, SAP, or any configured HTTP server, typically to modify data in that external system.”

Where the edit lands and what gets logged is the third piece. Edits made through an action are written to a writeback dataset rather than to the dataset backing the object type or link type itself — Palantir’s documentation is explicit that this “ensures that users have access to both the original data and the edited data in their analyses.” Every action submission also generates an action log entry, recording the submitting user’s Multipass ID, a timestamp, and the primary keys of the objects that changed; the documentation describes the log as built to answer “what changed, by whom, and when?” When the five standard rules are not enough, an action type can instead call a function that defines a more complex change.

Submission criteria, side effects, writeback, and the action log all have to work correctly together, every time an action fires; the argument here is that this combination — not any single piece of it — is what makes the action layer the hardest of the four to copy. Writing data to an external system on its own is not difficult. Verifying in advance whether an edit can go through, knowing what it will trigger once it does, preserving the original record alongside the edited one, and leaving an auditable trail at every step, all at once, is a different problem.

The Permission Layer Requires Two Keys Before an Object Becomes Visible

Palantir’s ontology-permissions page states the rule plainly: “To see objects, you must hold View permissions on the object type and access to the data.” Object-level security can be configured independent of the backing data sources, set directly on the object type in Ontology Manager; restricted views extend this by tying row-level access on a dataset to the object instances built from those rows. Property-level security runs on a separate track through markings: “Foundry verifies each property against its security markings to ensure all users with the appropriate access can view its value”. Markings follow an all-or-nothing rule — “a user must be a member of all Markings applied to a resource to access it” — and they propagate: “All resources derived from a marked file, folder, or Project will assume a Marking unless the Marking is explicitly removed.” Deleting an object carries its own restriction: a user who cannot view an object’s full set of properties is not permitted to delete it.

Humans and AI agents sit under the same rules. Palantir’s documentation states that every operation performed by a human or an agent must abide by “rigorous role-, marking-, and purpose-based controls”, and that tool invocations depend on access to the underlying objects, properties, and links in the Ontology. A January 22, 2026 Palantir blog post, Securing Agents in Production, goes a step further on agent permissions specifically: a given agent runs with “permissions that are a function of 1) the user that configures it and “owns” it; 2) the agent service user and/or agent OSDK scope; 3) the user on behalf of whom the agent is executing at a particular point in time”.

The Lineage Layer Keeps a Traceable Record of Every Decision

Decision lineage — when a decision was made, against which version of enterprise data, and through which application — is, per Palantir’s documentation, captured automatically and made securely accessible to human developers and agents alike. On the platform side, that promise breaks into a few concrete tools. Data Lineage is “an interactive tool that facilitates a holistic view of how data flows through the Foundry platform.” Platform audit logs provide “a comprehensive record of every action taken in Foundry, enabling security teams to detect threats, investigate incidents, ensure compliance, and maintain accountability across the platform.” For a function-backed action to appear in the action log at all, the backing Ontology edit function needs edits provenance configured. None of these pieces is complicated on its own; what makes the lineage layer worth naming separately is that it stitches together every change made across the semantic, action, and permission layers into a chain that can be traced back afterward.

Palantir’s Documentation Stages AI-Triggered Actions for Human Review by Default

Palantir’s fiscal year 2025 10-K states that the company began deploying AIP, its AI platform, in 2023. AIP’s builder tools — AIP Logic, AIP Chatbot Studio, and AIP Evals — are described in Palantir’s documentation as built on top of the Ontology and its developer toolchain.

Palantir’s why-ontology page walks through a fictional manufacturer, Onyx, to illustrate the guardrails the Ontology places around AI. In the worked example, Onyx grants a set of AI agents access to a limited group of actions. “In the default case, these actions (like changing the status of a work order or pushing a reallocation plan) can only be staged by the AI, before being handed off to a human for final review.” Only once trusted, well-tested processes have earned confidence, the fictional example continues, might Onyx choose to let some of them close the action loop without a human in it.

The documentation’s own language for this framework has shifted over time. A January 2024 blog post by Palantir chief architect Akshay Krishnaswamy described the Ontology as bringing together “data, logic, and action into a decision-centric model of the enterprise” — three components. Palantir’s 2026 documentation describes four, adding security. What can be said is that the documentation’s language changed from three items to four; nothing here speaks to when the underlying product gained that capability.

Palantir chief executive Alex Karp, in a shareholder letter dated May 4, 2026, put the Ontology’s relationship to reality this way: “The Ontology is based firmly in reality—there is, here, a dialectic between ground truth, tribal knowledge, and enhancements.”

The Word Ontology Now Carries At Least Three Different Meanings

The W3C’s definition of OWL 2 describes “an ontology language for the Semantic Web with formally defined meaning” — a knowledge-representation standard that shares a name with Palantir’s Ontology and little else. A second group of same-name products comes from semantic layer vendors. dbt’s documentation states: “The dbt Semantic Layer, powered by MetricFlow , simplifies the process of defining and using critical business metrics”. Looker’s documentation defines LookML as “the language that is used in Looker to create semantic data models.” Databricks describes metric views as “the core implementation of Unity Catalog semantics in Unity Catalog”. Snowflake’s documentation states: “You can store semantic business concepts directly in the database in a Semantic View”. Microsoft’s documentation describes Power BI semantic models in Microsoft Fabric as “a logical description of an analytical domain, with metrics, business friendly terminology, and representation”. All five definition sentences describe defining and unifying metrics or semantic models; none of them mentions writing an action back to anything. That is a statement about what the five sentences say, not about what the five products can or cannot do — this piece did not check that.

More platforms have picked up the word recently. Microsoft’s Azure blog, describing Fabric IQ, states: “Ontologies capture operational context by defining business entities and their relationships so agents can reason in the language of the business.” C3 AI’s own materials say its platform “models your entire enterprise as a unified ontology graph”. A ServiceNow community post from the company’s official account, dated November 17, 2025, describes a knowledge graph in the same terms: “In AI terminology, this is known as an ontology, which defines the language, structure, and logic the AI will use.” One word now covers a W3C knowledge-representation standard, a family of semantic-layer products, and Palantir’s four-part decision architecture — three different things.

Two Outside Critics Raise Different Doubts

BD Emerson managing director Leslie Sakal, writing on July 30, 2026, took aim at how the Ontology gets used: “The ontology is a poor data engineering environment, and treating it as one is expensive.” Cleaning, joining, deduplicating, and conforming data, she argues, belongs in pipelines beneath the ontology, not inside it.

Substack writer Pankaj Kumar, on May 30, 2026, raised a different concern, about portability. Foundry, he wrote, does not use the W3C standards OWL, RDF, or SPARQL — it uses its own representation of object types, link types, and action types instead. “You cannot export a Foundry ontology as an OWL file” that another platform could reason over, which is part of why he considers moving off Foundry an expensive proposition once business logic and workflows are encoded inside it.

Semantics, Actions, Permissions, Lineage: How Far Each Gets Without Palantir

A semantic layer, in the narrow sense, already exists as a product category outside Palantir. So do permission systems and audit trails. What is left open is which of the four layers described above can be assembled from tools already on the market, and which ones require the kind of integration engineering that a single vendor controls end to end. That question is for the next two pieces in this series, not this one.

Back to where this piece started: Palantir’s 10-K says its version of ontology goes far beyond the ordinary meaning of the word. On the reading built here, the part beyond ordinary mapping is Action and Security, plus the decision lineage that gets captured automatically alongside them.

Next in this series: Palantir Calls an Action a Single Transaction.

Frequently Asked Questions

Q: Is Palantir’s Ontology a database? No. Palantir’s documentation defines the Ontology as an operational layer for the organization that sits on top of existing datasets, virtual tables, and models, connects them to their real-world counterparts, and ties data, logic, executable actions, and permission rules together. It serves decisions, not queries.

Q: How is Palantir’s Ontology different from a semantic layer? Palantir’s own documentation states directly that the Ontology is not a semantic layer, because it integrates and operationalizes data, logic, action, and security together — something a thin semantic layer cannot do on its own. The definition sentences from dbt, Looker, Databricks, Snowflake, and Microsoft Fabric all describe defining and unifying metrics and semantic models, and none of the five mentions writing an action back to anything.

Q: What are Actions in Palantir’s Ontology? Action is the third of the four components Palantir’s documentation assigns to a decision, covering how a chosen decision gets orchestrated and executed. An action type carries submission criteria that decide whether it can be sent at all, side effects such as a webhook that writes data back to Salesforce or SAP, edits recorded in a writeback dataset, and an action log tracking who changed what and when.

Q: Is Ontology a Palantir trademark? Palantir’s fiscal year 2025 10-K lists the company’s registered trademarks as Palantir, Gotham, Palantir Foundry, and its corporate logo. Ontology is not on that list.