Inside Palantir's Ontology: an operational layer that adds 'action' on top of data

What is Palantir's Ontology, and why is it called an 'operational layer'?

This is Part 2 of the series 'Ontology: Hype and Reality'. Part 1 covered the general picture: an ontology is a blueprint that writes down a business's concepts, properties, relationships and rules in a machine-readable form, and its value depends on the ongoing work of filling it with real data and keeping it aligned. This part applies that picture to Palantir, the most commercially successful example. It uses the official documentation to explain the structure, then looks at how that structure fits the business model and what the criticisms are.

Palantir's official documentation source defines the Ontology as 'the operational layer for the organization'. It sits on top of the digital assets integrated into the platform (datasets, virtual tables and models) and connects them to physical assets such as plants, equipment and products, or to concepts such as customer orders and financial transactions. The documentation also says that in many cases it serves as the organization's digital twin.

The key word is 'operational'. The semantic layers and data catalogs covered in Part 1 stop at clarifying 'what this number means' to support analysis and reporting. Palantir tries to put the whole loop into one system on top of the same semantic structure: people make actual decisions, those decisions are carried out, and the record of that execution becomes data again. A company document source says that 'closing the loop on action in real time is what separates operational systems from analytical systems'.

So this article reads the topic from two angles. One is what the design of 'bringing analysis and execution together in one place' trades off technically. The other is what kind of sales model and lock-in that design produces.

Components: semantic elements (nouns) and kinetic elements (verbs)

The official documentation source splits the Ontology into two groups. The semantic elements are objects, properties and links; the kinetic elements are actions, functions and dynamic security. In the company document's source metaphor, the semantic elements are the enterprise's 'nouns' and actions are its 'verbs', and in each workflow people or AI use logic to combine nouns and verbs into 'complete sentences'.

The definitions in the core concepts documentation source can be summarized as follows. An object type is the schema definition of a real-world entity or event (such as an employee, an order or an equipment failure), and an object is a single instance of it. A property is a characteristic of an object type, and a link type is a relationship between two object types. An action type defines a set of changes to objects, property values and links that a user can make at once, along with their side effects (such as notifications). A function is code-based logic that takes inputs and returns outputs; it takes objects and sets of objects as input and is used across actions and applications. On top of these come interfaces, which let several object types share the same shape; shared properties, used across several object types; and roles, which control access.

Interestingly, Palantir itself explains these concepts by analogy to datasets source. It shows in a table that an object type corresponds to a dataset, an object to a row, a property to a column, a property value to a cell value, and a link type to a join. In other words, the company does not hide that its semantic elements map almost one to one onto the relational data model. So the differentiator has to be found not in the semantic elements but in the kinetic elements on top of them, that is, in also defining 'how things are changed'.

An example from the actions documentation source shows this well. An 'assign employee' action type defines how to change the role property of an employee object, takes the new role as input through a standard form, and automatically creates a link between the employee and the new manager object. It also comes with a side effect that sends notifications to the old and new managers, and a validation rule that only HR staff can run it. The company describes this as 'working with data in terms of business goals' rather than editing individual cells.

Data sources to objects, decisions back to source systems: mapping and write-back

An ontology does not start from a blank blueprint. The official documentation source says that defining an organization's semantics means 'mapping existing data sources to objects, properties and links'. According to the company document source, operational data from ERP (enterprise resource planning), MES (manufacturing execution systems) and WMS (warehouse management systems), IoT and edge streams, unstructured document stores, and geospatial data are synchronized and organized as objects, properties and links. In other words, the order is: first pull in the sources through data pipelines, then declare the dataset's columns as properties and its join relationships as links.

The opposite direction is 'write-back'. The actions documentation source explains that when a user runs an action, changes to objects, property values and links are applied to the Ontology and immediately visible in all user applications, and the latest object data, including user edits, is recorded in that object type's writeback dataset. The company document source goes further, saying that human and agent actions can first be simulated as scenarios and then safely written back to the enterprise's underlying systems, such as transactional systems, edge devices and custom applications, under the same access controls as data and logic.

Write-back matters for two reasons. First, it reduces the gap where someone decides on an analytics screen that 'this equipment needs inspection' and then has to enter it again in a separate system. Second, it accumulates what the company document source calls 'decision data'. The claim is that 'decision lineage' — which decision was made, when, on which version of the data, and through which application — is recorded automatically and then becomes material for training and agent memory.

There is a trade-off. Once there is a path for writing to source systems, the Ontology is no longer a read-only copy but a part of how business is processed. If permissions, validation and change management are designed poorly, the result is not an analysis error but an operational incident; and the better they are designed, the more deeply the business becomes tied to this layer. The switching cost debate discussed later starts here.

Design principles and AIP: modeling decisions and giving them to agents as tools

The company document source says the Ontology 'represents the enterprise's decisions, not its data'. It sees each operational decision as having four components: data (the information used in the decision), logic (the heuristics and calculations used to evaluate it), action (carrying out and coordinating the chosen decision) and security (assurance that the decision follows operational policy). The company's argument is that conventional data architectures cannot capture the reasoning behind a decision or the action that follows, and that conventional analytics architectures are separated from operations.

On the logic side, the company emphasizes 'logic binding' source. The idea is to bring business rules inside CRM and ERP systems, predictive models in data science environments, and optimization and simulation algorithms in domain tools under one interface, whether they run on-premises, in the cloud or as SaaS, so that deterministic functions (which give the same result for the same input) and statistical methods complement the non-deterministic reasoning of LLMs. It can be read as an attempt to have agents call verified calculation tools instead of 'guessing' numbers.

AIP (Palantir's AI Platform) is the layer that puts LLMs on top of this structure. According to the AIP documentation source, builder tools such as AIP Logic, AIP Chatbot Studio (formerly AIP Agent Studio) and AIP Evals are used to build AI workflows, agents and functions on top of the Ontology and developer tools, which run as sandboxed applications within the existing security, auditing and resource management systems. The documentation says users can choose from multiple LLMs and that audit logs and evaluation tools are provided.

For an agent, the Ontology is effectively its list of tools. The company document source explains that tool use is dynamically enforced by the same security system as data access, and that at a minimum, tool calls depend on access permissions to the underlying objects, properties and links. To prevent privilege escalation, such as queries that cross organizational boundaries or calls to unapproved external systems, permissions must explicitly specify the allowed operations. From an agent design perspective, 'action type = a function calling schema with validation rules' and 'roles and markings = the principle of least privilege'; it can be understood as this site's harness and guardrail concepts built into the data layer.

Business structure: growth in numbers and forward deployed engineers

All figures below are company-reported numbers from Palantir's Q2 2026 earnings press release source filed with the US Securities and Exchange Commission, and are labeled as unaudited. Q2 revenue was $1.935 billion, up 93% year over year. US revenue was $1.573 billion (up 115%), of which US commercial was $764 million (up 149%) and US government was $809 million (up 90%), according to the company. The company reported closing 220 deals of $1 million or more, 98 of $5 million or more, and 73 of $10 million or more, with total contract value (TCV) of $3.373 billion, including US commercial TCV of $2.132 billion (up 153%). It raised its full-year revenue guidance to $8.150 billion–$8.158 billion and its US commercial revenue guidance to more than $3.424 billion (growth of more than 134%).

The link between these numbers and the Ontology story is the US commercial segment. Government business is a long-standing base, but the company's framing is that expansion among general enterprise customers, led by the Ontology and AIP, is now the center of growth. However, the risk factors in the same press release source should be read alongside it, to be fair. The company itself notes that sales cycles are long and hard to predict, that platform deployment can be complex and lengthy, that total contract value may not all be realized as revenue because of contract options or termination-for-convenience clauses, and that it needs to make the platform easier to install and use. This article uses the earnings figures only to understand the business structure and has nothing to do with stock prices or investment decisions.

What stands out in the sales model is the forward deployed engineer (FDE). Engineers go to the customer's site, analyze the business together with the customer, map data to objects and build the first use case. As the previous section showed, the Ontology starts with mapping existing data sources, so without someone who knows the customer's business and data well, it can easily remain an 'empty platform'. FDEs are therefore not just a sales team but the people who build the Ontology itself, and selling and building are tightly bound together. Sales approaches such as bootcamps that build a prototype in a short time are also often mentioned, but the sources for this article contain no official description of them, so they are not covered here.

In Korea, there is the partnership with LG CNS. According to an announcement dated March 12, 2026 source, the two companies said they would deepen their strategic partnership to accelerate the AI transformation (AX) of LG Group. Palantir software was first introduced at one LG Group affiliate in late 2025 and used to improve quality control, and the plan is to expand it company-wide. Notably, LG CNS will set up a dedicated FDE team to identify use cases with the affiliates. This is only an announced plan, and the sources contain no rollout results or quantitative outcomes. Still, the structure in which a Korean SI (system integration) company takes on the FDE role matches the earlier analysis that the ontology business is ultimately tied to human integration work.

Moat or consulting? A fair look at both arguments

The main critical argument is well summarized in a post source by Vonng, a database blogger. The author maps object types to tables, properties to columns, links to foreign keys and actions to stored procedures at the technical level, and argues that Palantir's Ontology is database modeling wrapped in philosophical terminology. As evidence, the author points out that the background sections of Palantir-related patents describe the ontology as 'a data model implemented as a database schema'. The author also views Palantir as 'a consulting company dressed up as SaaS', and sees its real moat as political connections, security clearances, the labor-intensive FDE model, and path dependence from vendor lock-in. The post also asks why, if the Ontology really is a revolutionary intelligence platform, so many engineers need to stay on customer sites for so long.

The post source also raises the issue of portability. It argues that, unlike academic ontology research, which aimed at knowledge sharing and interoperability between systems, Palantir-style modeling takes months, carries high switching costs and makes data hard to move. Citing the case of the New York Police Department, which complained in 2017 when ending its relationship with Palantir that it could not get its analysis results in a portable format (the author cites reporting by BuzzFeed News and the Brennan Center), the post says the ontology meant to build a 'bridge' became a 'wall'. However, the same post acknowledges the engineering value of Palantir's products and that data modeling and system integration are real work in themselves. It draws the line at the narrative that credits that value to the name 'ontology'.

The opposing argument can be read in the company's own documentation. Palantir openly explains that its semantic elements correspond to dataset structures source and locates its differentiation elsewhere: actions with validation rules and side effects, write-back to source systems, row-, column- and marking-based permissions computed at execution time, decision lineage, and the integration that lets people and agents use all of this under the same rules sourcesource. The argument is that while individual features can be imitated with stored procedures or permission tables, the value lies in bundling them into a single product that runs business applications, agents and auditing consistently.

The two views are in fact different names for the same phenomenon. Both sides agree that remapping an entire business into objects and actions is heavy work. Once that effort is made, the customer's business runs on top of this layer and is hard to leave; from the company's point of view this is a moat, and from the customer's point of view it is lock-in. For practitioners, the important question is not 'is the ontology truly an innovation?' but 'is the speed and control gained by doing this integration work on an external platform worth the switching costs later?'

Questions to ask when evaluating a Palantir-style approach

First, check the nature of the problem. The value the company document source describes lies in closing the loop between decision and execution. If the goal is dashboards and reports, the semantic layer or data warehouse covered in Part 1 is likely enough. Start by asking whether 'the gap where someone takes analysis results and re-enters them into another system' is a real cost.

Second, check ownership of the mapping. At the contract stage, ask whether object type, link and action definitions, as well as writeback datasets and decision records, can be exported in standard formats. As the portability dispute cited in the critical post source shows, you only have negotiating leverage over data export terms at exit when you first adopt. Also plan for in-house staff to take over the logic FDEs build, so they can understand and modify it.

Third, check controls on write-back and agents. Decide which actions write to which source systems, how changes are rolled back on failure or conflict, and how far agents can execute actions without human approval. Filling the scenario simulation and permission system the company says it provides source with actual business rules is the customer's job.

There are three common mistakes: trying to draw a company-wide model all at once and falling back into the 'single enterprise-wide model trap' covered in Part 1; hastily generalizing the results of the first use case into a case for company-wide rollout; and counting only licensing in adoption costs while leaving out the staff needed for mapping and maintenance. It is worth remembering that the company itself wrote that deployment can be complex and lengthy source.

Further study, and on to Part 3

To get the structure first, a good order is to look at the table mapping datasets to the Ontology in Palantir's core concepts documentation source, confirm the semantic/kinetic distinction in the Ontology overview source, and then use the 'assign employee' example in the action types documentation source to see what kinetic elements actually define. The company's design philosophy and its claims about agent security are set out in the 'Why Ontology' document source, and the way LLMs are connected is summarized in the AIP overview source.

On the business side, read the earnings press release source not only for the figures but through to the risk factors at the end. For a critical view, Vonng's post source is the most systematic, and the Korean context can be checked in the LG CNS partnership announcement source. Putting the company documents and the critical post side by side and comparing 'what name each gives to the same fact' makes this article's point clear.

Part 3 moves to heavily regulated domains such as financial services. The write-back, agent permissions and decision lineage covered in this part are exactly where regulated industries run into model risk management, auditing and accountability for explanations. Who owns the semantic structure, and who bears final responsibility for automated decisions, become questions that come before technology choices.