Palantir Ontology 技术研究与 TAOS 实现借鉴

1. Summary of Research Conclusions

First of all, the conclusion: the most worthy reference of Palantir Ontology is not that it makes enterprise data into a "knowledge map", but that it combines the data, rules, actions and permissions in the enterprise into a set of business object systems that can be used by people, applications and agents.

This point is very crucial. When many enterprises make AI platforms, their first reaction is to connect models, knowledge bases and packaging tools. However, when it comes to business execution, Agent is often faced with scattered interfaces, scattered documents, different caliber data tables and separate authority systems. Palantir idea is closer to "build a model of the business world of the enterprise first, and then let the AI act in that model".

I took it apart and saw that the core was about four layers:

1. Business Object Modeling Layer: uses Object Type, Property Type, Link Type, Interface, and other abstractions to express the real business world.
2. Data Mapping and Index Layer: Maps data in databases, data lakes, streaming data, files, and external systems to objects, attributes, and relationships, and builds multiple indexes for object queries, graph queries, searches, time series, and geography.
3. Action and Logic Layer : Use Action Type, Function, Query, Workflow and other mechanisms to upgrade "Query Data" to "Trigger Business Action" and support approval, verification, write back, automation and human-machine collaboration.
4. Governance and Security Layer: Permissions, data blood, auditing, object-level security, attribute-level security, and dynamic security policies are integrated into the entire process of object query, action execution, and Agent tool invocation.

The inspiration for TAOS is also more direct: enterprise-class Agent OS can't just stop at model access, Prompt management, MCP tool gateway and knowledge base Q & A. It requires a layer of Enterprise Operational Ontology (enterprise operation ontology layer), which allows the Agent to face managed business objects such as "customers, orders, products, stores, packages, work orders, contracts, equipment, policies, approvals", and then complete the business closed loop through controlled actions.

2. Data pool and document list

One point needs to be made here: strictly speaking, there are not many academic papers on Palantir Ontology, and public information is mainly scattered in official white papers, product documents, SDK, patents and a small number of conference papers. Therefore, this material is not a simple paper review, but put these public materials together, from the perspective of engineering implementation to push back the design ideas behind it. Descriptions in patent and product documents will be accompanied by vendor expressions, and the following technical inferences will try to indicate boundaries.

2.1 Official White Papers and Technical Documents

2.2 Official Blog and AI Agent Information

2.3 Patents and Engineering Implementation Clues

2.4 Academic and Research Materials

3. What is Palantir Ontology?

3.1 one sentence definition

In one sentence, I would understand Palantir Ontology as the "executable object layer" of the enterprise business world ". It does not only describe "what entities are there and what relationships are there between entities", but further describes "who can see these objects, what actions can be performed, how actions are verified, where they are written back after execution, and how the whole process is audited".

3.2 it's not just a knowledge map

Traditional knowledge graph focuses on "entity, relationship and semantic query", and mainly answers "what is and what is the relationship". The focus of the Palantir Ontology is more on the operating system, and the answer is "based on these business objects, what can we do, who can do it, where to write and how to audit".

3.3 it's not just a data center

The data center typically focuses on data collection, modeling, metrics, reports, labeling, and services. Ontology go one step further: translate data assets into objects that business people, applications, and agents can understand, and bind these objects to actions. For example:

-The data center cares about "order table, customer table, product table, indicator table".

-Ontology care about the customer object, order object, product object, which organization the customer belongs to, the current risk of the order, what actions can be initiated, whether the actions need approval, and which system to write back to after execution ".

So I prefer to think of Ontology as an "operational object model" between the data middle desk and the business application ". For Agent OS, this layer is especially important because it determines whether the agent is "reading data and adjusting interfaces" or working in a governed business world.

4. Core abstract model

4.1 Object Type: Business Object Type

An Object Type is a schema definition of a real-world entity, event, or business concept. Typical objects include:

-Communications industry: customers, numbers, packages, bills, tariffs, base stations, work orders, complaints, marketing activities.

-Food and beverage industry: brands, stores, dishes, orders, members, inventory, suppliers, employees, shifts, activities.

-Manufacturing industry: equipment, production lines, work orders, materials, batches, quality events, maintenance plans.

-Government and enterprise scenarios: enterprises, projects, contracts, personnel, assets, approval documents, risk events.

Object Type should not simply copy database tables, but should express stable business concepts that business users and agents can understand.

4.2 Property: Object Properties

Property are the fields and characteristics of an object, for example:

-Customer object: customer number, customer level, attribution area, ARPU, churn risk, time of last complaint.

-Store object: store code, brand, city, business status, daily turnover, customer complaint rate, inventory risk.

-Work Order Object: Work Order Type, Priority, Current Status, Handlers, SLA Remaining Time.

In terms of technical implementation, Property need to support:

-Base type: String, Number, Boolean, Date, Datetime, Enum.

-Complex types: JSON, Array, Geo, Media, Attachment.

-Analysis type: Time Series, Metric, Embedding, Score, or Feature.

-Governance attributes: source system, update time, blood ID, trust level, desensitization level.

4.3 Link Type: Object Relationship Type

A Link Type describes a business relationship between two object types, for example:

-Customers "order" packages.

-The store "belongs" to the brand.

-The job is "associated" with the customer.

-The device is "at" the site.

-Dishes "consume" raw materials.

Relationships need to express direction, cardinality, navigability, and security policies. Much of the agent's reasoning power comes not from the big model itself, but from these explicit business relationships. For example, "find out the reason why a store's bad reviews have increased in the last 7 days" requires searching along the relationship between stores, orders, reviews, dishes, shifts, employees, inventory, etc.

4.4 Interface and Shared Property Type: Shared Semantics

Interface can be understood as a set of properties and behaviors that are reused across objects. For example:

-Approvable objects: approval status, applicant, approver and approval time.

-Locatable objects: longitude, latitude, administrative division.

-Traceable object: creation time, update time, source system, blood ID.

-Risk assessable objects: risk level, risk reason, scoring model version.

This type of design prevents each object from repeatedly defining similar fields, and also allows the Agent to use unified logic to process different objects. For example, all objects that implement Approved Object can access the same set of Approval Actions.

4.5 Action Type: Business Action Type

Action Type is a key capability that distinguishes Palantir Ontology from the general knowledge graph. Action is not a normal button, but a business operation subject to schema, rules, permissions, approval, and audit constraints.

Typical Actions include:

-Create a job.

-Modify customer packages.

-Adjust the store inventory alert threshold.

-Launch a marketing campaign.

-Approve price changes.

-Mark the device as faulty.

-Trigger external system writeback.

An Action Type usually needs to be defined:

-Input parameters: which fields are required for the action.

-Action object: which Object Type or Link Type the action acts on.

-Validation rules: under which conditions submission is allowed.

-Permission policy: who can execute and whether the Agent can execute.

-Approval rule: whether manual confirmation is required.

-Execution logic: rule-based updates, function calls, workflow calls, external API calls.

-Writeback policy: Writeback Ontology, local object library, source system, or message queue.

-Audit information: who triggered the action when and for what context.

4.6 Function / Query: Business Logic Encapsulation

Function and Query are used to encapsulate reusable business logic:

-Query is read-only and is used for object filtering, graph traversal, aggregation, metric calculation, and complex queries.

-Function encapsulates computation, model inference, external service invocation, and object editing.

-Function-backed Action can host complex action logic for code execution.

-The External Function can be connected to the internal interface, model service, ERP, CRM and work order system through the Webhook.

For TAOS, this part can be combined with MCP, enterprise internal API gateway and workflow engine. MCP tools should not be just "bare interfaces", but should be mounted to concrete objects and actions.

4.7 Security Policy: Object-Level Security and Action-Level Security

Ontology security is not only controlled on the page menu, but throughout:

-Whether the object type is visible.

-Whether the object instance is visible.

-Whether the property is visible.

-Whether the relationship is traversable.

-Whether the Action is executable.

-Whether the Function is callable.

-Whether the Agent can execute on behalf of the user.

-Whether the output content can be written to memory or log.

This is critical for enterprise-class agents. Agent cannot bypass the existing permission system of the enterprise just because it can call tools. It is more reasonable for the Agent to inherit the user identity, position role, data domain, security level, and scenario authorization, and evaluate the policy for each object query and action execution.

5. Ontology technical implementation ideas

Overall 5.1 Architecture

If you only look at the product introduction, it is easy to understand the Ontology as an "advanced data catalog" or "business map". However, from the combination of public documents, SDK and patent information, it is more like a metadata-driven runtime system. In the picture above, I split it into three pieces:

1. Ontology Language: defines the language of the business world, including objects, attributes, relationships, actions, functions, and security policies.
2. Ontology Engine: Execute this set of languages, including object queries, graph traversal, indexing, action execution, transactions, writeback, and subscriptions.
3. Ontology Toolchain: Provides a toolchain for modeling, publishing, SDK generation, application building, permission governance, and audit operations.

The most notable one here is the Engine. Without Engine,Ontology is just a beautiful metamodel; with Engine, it can compile object definitions into queries, indexes, permission judgments, and action executions.

5.2 Data Entry Ontology:Hydrate

Hydrate can be understood as the process of "pouring existing enterprise data into the world of business objects. This process is not just ETL, the real trouble is to translate technical fields into business semantics.

I think there are a few points here that are easily underestimated:

-Identify the primary key, foreign key, enumeration, time field, state field, and permission field of the source system first.

-Redesign the business object instead of mechanically copying the table structure.

-Describe "how source fields are mapped to object attributes and source table relationships are mapped to Link" with Mapping Profile ".

-Use Parser and Validator for data type conversion, quality verification, standardization and exception logging.

-Record the source, update time, kinship and trust level for each object, attribute, relationship.

5.3 From Object to Action: Activate

Activate solves another problem: how to make the object really participate in business actions after it is built. A read-only object model can only support analysis and become an operational object layer after query, Function, action, and policy are bound.

For example, in the communications industry:

-Customer object binding "Query Customer Profile" Query.

-The "Adapt to package recommendation" Function is bound to the package object.

-The customer-package relationship binds the "change package" action.

-Strict access policies for high-value customers and sensitive tariff attributes.

-Agents can only access and manipulate business objects through these controlled queries, Function, and actions.

5.4 action execution link

This link is also the key boundary that I think TAOS needs to absorb: Agent should not directly adjust the database or bare API, but perform business actions through the governed Action. Only in this way can the authority, approval, audit, failure compensation and business responsibility be put into the same link.

5.5 Object Storage and Multiple Backend Indexes

A clear signal from public patents and official information is that the Ontology back-end is probably not a single database, but a multi-back-end object index system. It is more reasonable to give different query loads to different stores:

-Relational databases are suitable for storing normalized object properties, versions, transactions, and metadata.

-The graph database is suitable for relational traversal, Search Around, path query and network analysis.

-Search engine suitable for full-text search, fuzzy matching, multi-condition filtering.

-Time series databases are suitable for IoT, metrics, performance curves, and historical trends.

-Vector database is suitable for document semantics, object similarity, case recommendation and Agent memory retrieval.

-Object storage is suitable for attachments, pictures, contracts, audio and video, model files.

Therefore, the technical key is not to choose a "universal database", but to use Ontology Metadata as a unified schema, compile the same business object into different back-end indexes, and select the appropriate execution plan by Engine during query.

5.6 Metadata Driver and SDK Generation

Another engineering value of Ontology is metadata-driven. Once objects, properties, relationships, actions, functions, interfaces, and policies are registered as metadata, they can be further generated:

-API documentation.

-TypeScript/Python / Java SDK.

-MCP tool description.

-Low code form.

-Permission configuration interface.

-Action parameter validator.

-Agent Tool Schema.

-Audit and Bloodline templates.

In other words, once the business model is precipitated, it is not just a modeling document for people to see, but a "business operating system API" that people, applications, and agents can call ".

6. Relationship between Ontology and Agent OS

In order for Agent OS to truly enter the enterprise production environment, I think three questions must be answered first:

1. What the Agent looks at: Can you see the correct, up-to-date, and permission-controlled business context.
2. What Agent can do: Can it affect real business systems through controlled actions.
3. How Agent is responsible for : whether it can record the reason, context, executor, approver, input and output and result.

The value of Ontology is here: it puts these three problems into the same framework.

7. TAOS can learn from the enterprise operation ontology design

7.1 Core Objects in TAOS

For TAOS, you can first objectification the assets that are most likely to get out of control and most worthy of precipitation in the operation of the enterprise Agent:

7.2 TAOS Ontology Metamodel Recommendations

7.3 TAOS Technology Module Split

8. Combination of MCP, Prompt, Skill and Ontology in TAOS

8.1 MCP is not an interface market, but an execution channel for Action

After the internal interface of the enterprise is packaged into MCP, I do not recommend directly exposing it to Agent. A safer way is to bind to the Ontology Action first.

For example:

-Bare MCP tool: 'changeCustomerPlan(customerId, planId)'.

-Ontology Action: 'Customer. Change Package '.

-Action Governance: Check whether the customer exists, whether the package is available for sale, whether the user has permission, whether approval is required, whether change reasons need to be recorded, and whether to write back to CRM/BOSS.

The benefits of this are more practical:

-Agent sees business actions, not technical interfaces.

-Unified closing of parameter verification, permission, approval and audit.

-The same action can replace the underlying implementation without affecting the Agent and the application.

-Actions can be reused by people, agents, workflows, low-code applications.

8.2 Prompt Asset should be a Ontology asset

If the Prompt Library is only a Prompt text warehouse, its value will be relatively limited. What can really settle down should be the Prompt Asset System.

PromptAsset recommendations for inclusion in Ontology management:

-Prompt types: Architecture Prompt, Security Prompt, Domain Prompt, Review Prompt, and Operation Prompt.

-Applicable objects: Bind to Object Type, Action Type, Agent Role, and business scenario.

-Version governance: draft, review, release, discard, rollback.

-Quality indicators: hit rate, satisfaction, error rate, tool call success rate, manual correction rate.

-Security policy: whether it can be used for sensitive data, whether to allow outgoing, whether to allow automatic execution of actions.

-Optimization of closed loop: Combined with SkillOpt / PromptOpt ideas, continuous optimization based on evaluation sets and real running logs.

The core of the Prompt Governance is not "who writes Prompt fast", but who can turn Prompt into an enterprise-level asset that can be governed, evaluated, reused, audited, and continuously optimized.

8.3 Skill management should also be object-based

Skill is the reusable capability unit of Agent, which can include:

-Domain analysis skills.

-Tool calling skills.

-Review skills.

-Summary skills.

-Planning skills.

-Report generation skills.

-Code generation skills.

-Safety inspection skills.

SkillAsset need to record:

-Input/output Schema.

-Callable tools.

-Dependent on Prompt.

-Reliance on knowledge assets.

-Applicable Agent.

-Permission boundaries.

-Evaluation results.

-Version and release status.

In this way, Skill can precipitate and reuse like SDK, component library and rule library.

8.4 Memory Should Also Enter Ontology Governance

The memory of an enterprise agent cannot be just fragments of a vector library. My suggestion is to split the memory into four categories and then include object management:

Session ID isolation can be embodied on Session objects:

-Each session creates a separate Session ID.

-Session the user, organization, agent, task, and permission context.

-Working Memory, tool call, temporary file, context summary are bound to Session ID.

-Information that is multiplexed across Session must be summarized, desensitized, validated and assetized.

-In high-risk scenarios, only the audit summary is retained after the Session, not the complete context.

9. TAOS Landing Route Recommendations

9.1 Phase 1: Read-Only Business Object Layer

In the first stage, don't rush to do complex actions, let the Agent and application "understand the enterprise" first ".

Key work:

-Select 2 to 3 core business domains, such as customer, product, work order or store, order, member.

-Create Object Type, Property Type, Link Type.

-Access to core data sources to complete Mapping Profile.

-Establish object query API, graph traversal API, search API.

-Access basic permissions and audits.

-Let the Agent answer business questions through object queries.

Deliverable:

-Business object model.

-Data mapping table.

-Object Query Service.

-Object graph visualization.

-Agent Read-only Q & A Demo.

9.2 Phase II: Controlled Action and MCP Writeback

In the second stage, the Agent is pushed from "question and answer assistant" to "executable assistant", but the action should start from the low-risk scene.

Key work:

-Select low-risk actions, such as create work orders, generate reports, initiate approvals, query inventory, send notifications.

-Encapsulate the internal interface as an MCP tool.

-Bind the MCP tool to the Ontology Action.

-Added Action parameter verification, permission, approval, and audit.

-Support action execution results written back to the object layer and source system.

Deliverable:

-Action Registry.

-MCP Gateway.

-Action Runtime.

-Approval and audit links.

-The Agent performs the action Demo.

9.3 Phase III: Prompt / Skill / Memory Asset

The focus of the third phase is to transform Agent capabilities from personal experience to corporate assets.

Key work:

-Create PromptAsset, SkillAsset, Memory, Decision, etc.

-Establish Prompt version management, review and release, evaluation and optimization process.

-Establish Skill registration, dependency management, evaluation, and grayscale release mechanisms.

-Establish Session isolation, contextual summaries, and memory governance.

-Establish a closed loop from the running log to the optimized data set.

Deliverable:

-Prompt Asset System.

-Skill Registry.

-Agent Memory Service.

-PromptOpt/SkillOpt evaluation optimization closed loop.

9.4 Phase IV: Decision Closed Loop and Industry Scenario Replication

The fourth stage is suitable to talk about industry replication. When the first three steps do not run through, the industry template is often just a concept package.

Key work:

-Package industry objects, actions, Prompt, Skill, Workflow as industry templates.

-Establish scenario simulation, scheme comparison and selection, manual approval and execution feedback closed loop.

-Access to BI, low-code applications, mobile and business workbenches.

-Establish multi-tenant, multi-organization, multi-data domain isolation.

-Establish asset markets and reuse mechanisms.

Deliverable:

-Industry Ontology template.

-Agent Scene Pack.

-Decision closed loop workbench.

-Enterprise-level asset markets.

10. Key Design Principles

1. First business object, then technical interface

Do not let the Agent face tables, interfaces, document fragments. First abstract stable business objects such as customers, orders, stores, products, work orders, etc.

1. The object model is not equal to the database table model.

Object Type should serve the business understanding and action closed loop, and cannot simply copy the source system table structure.

1. Action is a first class citizen

The value of enterprise-class agents is not just to answer questions, but to complete actions safely, controllably, and auditable.

1. Permissions must sink to objects, attributes, relationships, actions, and memories

You cannot do only menu permissions or interface permissions. What the Agent accesses, remembers, outputs, and executes is controlled by policy.

1. The Ontology is an operational projection and does not necessarily replace the source system

The source system can still be a fact source, Ontology responsible for unifying object views, operational abstractions, writeback coordination, and audit closed loops.

1. Prompt and Skill to be governed like code assets

Version, review, release, evaluation, rollback, dependency, permission, and usage statistics are required.

1. Memory needs governance, not just storage

The memory of an enterprise Agent is bound with Session, users, permissions, tasks, sources, and life cycles.

1. From the narrow scene to do deep, do industry template

Don't start to build a whole enterprise big and all Ontology. Priority is given to high-frequency, high-value, clear boundary business closed loop.

11. Suggestions for specific enhancements to the TAOS scheme

It is recommended to add a new core chapter in the TAOS upgrade plan: Enterprise Operational Ontology: Enterprise Operation Ontology Layer.

This chapter can be used as the central ability of TAOS, and the relationship with the original ability is as follows:

It is recommended that the technical positioning of TAOS be further upgraded from an "enterprise-class intelligent body management platform":

TAOS is an Agent Operating System for enterprise production environment. with the enterprise operation ontology as the core, it unifies data, knowledge, Prompt, Skill, MCP tools, business actions, security policies and Agent Runtime to help enterprises upgrade AI from question-and-answer capability to controllable, auditable and reusable business execution capability.

12. Presales oriented

In the pre-sales scene, the following passage can be used to explain why TAOS needs Ontology:

The biggest difficulty for an enterprise to become an Agent is not how many models are connected or how many tools are encapsulated, but whether the Agent truly understands the business world of the enterprise. Through the enterprise operation ontology, TAOS models customers, products, orders, stores, work orders, contracts, knowledge, Prompt, Skill, tools, and actions in a unified way, allowing agents to obtain context, call capabilities, execute actions, and accept permissions, security, and audit constraints in the same business language. In this way, AI can change from "being able to answer" to "being able to handle affairs, doing it accurately, doing it stably, and doing it traceable".

If the customer is already working on a knowledge base, tool platform, or agent platform, you can also use the following comparison table to communicate the differences:

13. Risks and Constraints

13.1 over-modeling risk

The most easy place for Ontology to go is to make a huge and heavy enterprise model project. It is recommended to start from the scene and only build the objects, relationships, and actions that are really needed by the current business closed loop.

13.2 Data Quality Risk

If the source system master data is confused, field meanings are inconsistent, and permission tags are missing, Ontology will only expose the problem more clearly. Supporting data quality, master data, consanguinity and responsible person mechanisms are needed.

13.3 Writeback Consistency Risk

When an agent performs an action, it may affect both the Ontology object library and multiple source systems. The source of facts, transaction boundaries, compensation mechanisms, failure retries, and manual support need to be clarified.

13.4 Security Complexity Risk

Object-level, attribute-level, action-level, and Agent-level permissions significantly increase governance complexity. It is recommended to establish clear data fields, roles, security levels, and approval rules in the early stage, and gradually refine them.

13.5 Agent Illusion and Misoperation Risk

Ontology can constrain the agent's input, context, and action boundaries, but it cannot completely eliminate the model illusion. High-risk actions must be added with manual confirmation, rule checksum and rollback.

14. Minimum feasible architecture proposal

If TAOS wants to be a landing MVP, I suggest starting with the following minimum closed loop:

MVP does not need to do a complete knowledge map and full object library at the beginning. It is more important to verify a few basic questions:

-Whether the Agent can stably understand the business through the object model.

-Whether the MCP tool can be safely executed via Action.

-Whether Prompt, Skill and Memory can be managed as assets.

-Whether permissions and audits can cover a complete decision link.

-Whether business people can continuously expand the scene based on objects and actions.

15. Recommend follow-up work

1. Upgrade the knowledge governance in the TAOS solution to" enterprise operation ontology governance "

Governance not only document knowledge, but also business objects, relationships, metrics, actions, Prompt, Skill, and memory.

1. Complements the TAOS Ontology Studio Design

Includes object modeling, relational modeling, data mapping, action configuration, permission configuration, version release, and impact analysis.

1. Complementary TAOS MCP Action Gateway Design

Clarify how MCP tools are registered, how objects are bound, how permissions are included, approvals, and audits.

1. Supplemental TAOS Prompt / Skill / Memory Asset Model

The Prompt Library, Skill management, context summary, session isolation and memory management to the Ontology Asset system.

1. Choose an industry model to do PoC

For communication customers, you can choose "customer-product-tariff-work order-marketing" closed loop. For catering customers, you can choose "brand-store-order-member-inventory-evaluation" closed loop.