What Is Palantir Ontology? Connecting Business Data, Decisions, and Actions
What you’ll learn
- How a general ontology differs from the role of Palantir Ontology
- How business data, calculations, change procedures, permissions, and user interfaces connect
- How to distinguish among databases, knowledge graphs, RAG, AI execution environments, and Palantir Ontology
- Four perspectives for evaluating a pilot: business entities, change procedures, permissions, and records
Palantir Ontology connects business data and operations through a shared foundation
Palantir Ontology is a foundation for handling business data and the decisions and operations based on that data through a shared system. It connects entities such as equipment and orders, their relationships, calculations, change procedures, permissions, and operation history in one business model—a structured representation of business entities and rules.
Moving an inspection forward when equipment may fail requires more than checking its condition. The team also needs to know whether parts are available, who may change the schedule, and which conditions permit the change. Afterward, it needs a record of who changed what and when.
Palantir describes the Ontology as an operational layer that supports business decisions and operations.[3] It is designed to help carry a decision into the business workflow, rather than ending with a view of the data.
This article uses the Ontology’s components and an equipment-maintenance example to distinguish it from a knowledge graph, which represents relationships among entities, and RAG, which retrieves information for a generative AI response. It then presents criteria for deciding whether Palantir Ontology fits an organization’s work.
General ontology and Palantir Ontology serve different scopes
In information science, an ontology explicitly describes the concepts in a domain, the relationships among them, and the conditions or constraints that apply. In a business setting, this includes shared definitions such as what counts as equipment and which site a piece of equipment belongs to.
The word originates in philosophy as a theory of existence. AI researchers began using it as a component of knowledge systems in the 1980s, and the definition “an explicit specification of a conceptualization” became influential in the 1990s.[1] In practical terms, an ontology makes a way of identifying and classifying things shareable with people and computers.
OWL, the W3C Web Ontology Language for representing concepts and relationships in logic, allows software to check whether expressed knowledge is consistent and to make implicit knowledge explicit.[2] In that context, the main role of an ontology is to define what exists and how those things relate.
Palantir Ontology connects those definitions to business decisions and operations. The official documentation describes it as an operational layer that connects integrated datasets, virtual tables—which present referenced source data in tabular form—and models to real-world counterparts such as equipment, products, customer orders, and financial transactions.[3]
It is therefore more useful to view Palantir Ontology as an architecture that connects a model of data meaning and relationships to business applications and change processes, rather than as a direct productization of academic ontology.
Ontology components represent entities, relationships, calculations, and operations
Objects, Properties, and Links first represent business entities, their state, and the relationships among them. Functions add calculations and decisions, while Actions add controlled change procedures.
Palantir documentation calls Objects, Properties, and Links Semantic Elements, which represent meaning and relationships. Functions and Actions are among the Kinetic Elements that perform calculations and operations.[3]
| Element | Role and example | Maintenance question |
|---|---|---|
| Object (business entity) | Represents equipment, orders, customers, and similar entities. An Object Type defines a kind of entity, while an Object is an individual entity | Are the identifier and rules for recognizing the same entity clear? |
| Property (entity attribute) | Represents information such as equipment status, inventory quantity, or an order deadline | Are the meaning, unit, and update source consistent? |
| Link (relationship) | Connects an order to a customer or equipment to a site | Can the basis and valid period of the relationship be traced? |
| Function (calculation or decision logic) | Calculates risk, evaluates a condition, or estimates results under changed assumptions | Can the inputs, version, and exception conditions be tested? |
| Action (change procedure) | Creates or updates data, supports approval, or connects to an external system | Who may change what, and under which conditions? |
| Permission control | Controls access to entities and attributes and the execution of operations | Can viewing permission be separated from change permission? |
Objects, Properties, and Links show which equipment exists, where it is, and its current state. Functions and Actions define what can be calculated for that equipment and which changes are permitted.
An Action Type, which defines a change procedure, includes input parameters, Ontology edits, related processing such as notifications, and execution conditions. The same Action logic can be reused from applications for different groups of users.[4]
An equipment-maintenance workflow connects state checks to change records
Palantir Ontology can treat state checks, option comparison, permission checks, changes, and records as one business workflow. This operational scope distinguishes it from a general semantic layer, which standardizes the meaning of data and terminology.
This article organizes the official components into the following four stages for explanation.
- Check the current state: Retrieve the information required for a decision from entity attributes and relationships.
- Compare options: Use calculations and trial conditions to compare the impact of each candidate.
- Change within conditions and permissions: Execute a change procedure only when the required conditions and permissions are satisfied.
- Review the change record: Use operation history to determine who changed what and when.
An operational application—a business application that supports decisions and data writeback in addition to displaying information—shows the Ontology’s current state. A Scenario lets a user test the impact of a proposed change under trial conditions, and an Action commits the decision.[5]
Action submission criteria can combine the user, input values, and the state of target Objects. A change that does not satisfy the criteria is rejected.[6]
Consider a maintenance team deciding to bring forward an inspection for equipment with a high risk of stopping.
First, Objects and Links connect equipment, failures, work orders, and parts inventory. A Function calculates the risk and impact of a change, and the coordinator compares candidate dates.
Next, the Action checks whether the equipment is operating, parts are reserved, and the operator has approval authority. If the conditions are satisfied, it updates the work order. When Action Log is enabled, it can retain the decision from a successful Action and link it to the edited Objects.[7]
The design gains value because data meaning, calculations, operations, and permission controls refer to the same business definitions. It can reduce the need for each user-facing application or AI agent—AI that uses tools to pursue a goal—to implement a separate version of the same rules. Whether relationships can be shown as a graph does not by itself capture this benefit.
Databases, knowledge graphs, RAG, and Ontology address different needs
Palantir Ontology is not a single feature that replaces databases, search, and other technologies. Separating what each one is responsible for helps avoid choosing a larger architecture than the requirement needs.
| Technology or system | Primary role and what it handles | What it does not handle well by itself |
|---|---|---|
| Database and schema (definition of data structure) | Determines storage and format by defining tables, fields, data types, and input constraints | Shared business vocabulary and decision procedures across systems |
| Semantic Layer (shared analytical metrics and terms) | Standardizes metrics, classifications, and aggregation methods used in analysis | Executing business-data changes and recording operations |
| Knowledge graph | Represents actual entities, their attributes, and their relationships so that relationships can be traversed | Managing who may change state and under which conditions |
| RAG | Uses document fragments and vectors—numeric representations of semantic similarity—to retrieve relevant information for an answer | Authoritative business relationships, data updates, and operational permissions |
| Palantir Ontology | Connects entities, relationships, calculations, change procedures, and permissions from state interpretation through governed change | Improving source-data quality or creating agreement among accountable business owners |
| AI work rules and execution environment | Organizes instructions, tools, evaluations, approvals, and the execution environment to make AI processing more consistent | A shared model that connects enterprise concepts to operational data |
If document search and summarization are the goal, RAG provides a smaller starting architecture. If the goal is to traverse relationships across systems, a knowledge graph combined with existing applications may also fit.
Palantir Ontology adds clearer value when multiple workflows need to reuse the same entities, relationships, calculations, change procedures, and permission controls.
The related AWS Context Ontology Accelerator article covers a foundation for supplying data meaning and relationships to AI agents. It also addresses GraphRAG—retrieval and generation using graph structure—and operating conditions on AWS. This article focuses on the Palantir-specific path from a decision to its change record through Functions, Actions, business applications, permissions, and Action Logs.
Separating view and change permissions clarifies operational responsibility
When multiple workflows and applications share an Ontology, a change to its definitions can have a wider impact. Before connecting data, an organization needs to determine who manages definitions and who authorizes changes.
Permissions for definitions and operational data are separate
In the project-based permission model referenced here, access to Ontology resources—definitions such as Object Types, Links, and Actions—is separate from access to actual Object data.[8]
The model is enabled for new Ontologies. Existing Ontologies may require migration, and the official documentation states that it is not available for Default Ontologies.[8]
For example, permission to view an Object Type definition does not by itself grant access to individual Object values. The user must also have access to the underlying data or satisfy the applicable Object security policy, which controls access to Objects.
Editing a Link or Action also requires edit permission for the related Ontology resources.[8] The design therefore needs to separate the ability to inspect structure, view operational data, and make changes.
Operations require explicit ownership
Based on that separation, this article distinguishes at least the following responsibilities.
| Role | Primary responsibility |
|---|---|
| Concept Owner | Approves Object and Link definitions, the rule for treating records as the same entity, and retirement conditions |
| Logic Owner | Maintains the basis, version, and test cases for Functions |
| Action Owner | Approves inputs, edited entities, execution conditions, and related processing such as notifications |
| Security Owner | Verifies viewing and execution permissions applied to Objects, Properties, and Actions |
| Application Owner | Manages the Ontology scope used by Workshop—Palantir’s business-application builder—or custom applications and the impact of changes |
Ontology changes can affect external applications
The Ontology SDK, or OSDK, is a development toolkit for using an Ontology from an application. It makes a selected subset of the Ontology available from TypeScript or Python. An external application can retrieve Objects, apply Actions, and call Functions.[9]
This broadens where the Ontology can be used, but it also means an Ontology change may affect multiple applications.
When an Object or Action version changes, regression checks—confirming that behavior that worked before still works after the change—need to cover applications and business procedures as well as data pipelines that collect, transform, and connect data.
A pilot needs four perspectives: entities, changes, permissions, and records
A PoC, or limited proof of feasibility and value, is easier to evaluate when it begins with one recurring decision rather than the design of an enterprise-wide ontology.
For a workflow that adjusts equipment inspection dates, the pilot needs to identify the required information, who may make a change, and what must be recorded. The following table is an article-specific framework for scoping that pilot.
| Perspective | Questions for defining the pilot | Condition to defer adoption or revisit a prerequisite |
|---|---|---|
| Business entities and relationships | Which entities, attributes, and relationships are required? Are identifiers, update sources, relationship evidence, and the data owner clear? | One table or document completes the workflow |
| Calculations and change procedures | Which calculations, changes, and exception conditions are required? Can inputs, outputs, test cases, execution conditions, and the destination of the change be verified? | Read-only analysis meets the requirement |
| Permissions | Who may view and execute what? Can viewing and execution be tested for representative roles? | Source-system permissions cannot be mapped |
| Records | How will the decision and change be traced? Can the operation record, reason, related entities, and recovery procedure be verified? | The change owner or record requirements are undefined |
A working screen is not enough to complete the evaluation. A representative decision should demonstrate all of the following:
- The current state required for the decision can be retrieved.
- Multiple options and their effects can be compared.
- A change can be made within permissions and execution conditions.
- The basis for the decision and the resulting change can be traced afterward.
If one is missing, the organization needs to supply the missing responsibility or evidence before expanding the workflow’s scope.
A smaller architecture may be appropriate when shared business concepts are not used across multiple applications, no data is written back, or relationship traversal is rare. An existing data mart—data organized for a particular workflow or analysis—Semantic Layer, RAG system, or workflow product can keep the maintenance surface smaller.
The reason to evaluate Palantir Ontology is not to make the data model more sophisticated for its own sake. The deciding question is whether the organization needs to operate decisions and execution continuously through the same business model.
Summary: Ontology is a shared foundation for decisions and execution
Palantir Ontology is an operational layer that connects definitions of business entities and relationships to calculations, change procedures, permission controls, business applications, and operation records.
Its distinction from a knowledge graph or RAG becomes clearer when the question moves beyond data representation: does the organization need to use one business model for current-state checks, option comparison, condition-based changes, and operation records?
Search or read-only analysis may justify a smaller architecture. Ontology becomes a clearer candidate when multiple workflows and applications need to share change procedures, permissions, and records.
One recurring decision can make that evaluation concrete. The pilot can test business entities and relationships, calculations and change procedures, permissions, and records while also confirming that people are accountable for definitions and changes.
References
These are the references from the original article. The years follow the original article’s notation.
- Tom Gruber, Ontology, Encyclopedia of Database Systems, 2009
- W3C, Web Ontology Language (OWL), December 11, 2012
- Palantir, Overview — Ontology, 2026
- Palantir, Overview — Action types, 2026
- Palantir, What is an operational application?, 2026
- Palantir, Submission criteria, 2026
- Palantir, Action log, 2026
- Palantir, Ontology permissions, 2026
- Palantir, Overview — App building, 2026
For the latest releases and updates, check the official website and official documentation.