⌕ ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← 返回速读报告 Drizzle Digest · NO.211 · 全文

The Palantir Impact: Ontology Strategy Connecting Data and AI

频道: GitHub · Leading AI（Satoshi Yamauchi）
原文: https://github.com/Leading-AI-IO/palantir-ontology-strategy
原文语言: en
统计: 共 69 轮

[¶1]

The Palantir Impact: Ontology Strategy Connecting Data and AI

他の言語で読む: 日本語

Definition

This book is a structural analysis by Satoshi Yamauchi (山内怜史), AI Strategist, explaining Palantir Foundry's "Ontology" — not as an IT technology, but as an operational layer that models the world as nouns (objects, properties, links) and verbs (actions, functions, dynamic security), enabling AI to act safely on real-world operations through a branch-and-review governance process. As stated in the book: this is a shift "from data you only look at, to data that directly drives the business."

Author & full catalog: github.com/Leading-AI-IO

Palantir 冲击：连接数据与 AI 的本体（Ontology）战略

以其他语言阅读：日文

定义

本书是 AI 战略师 Satoshi Yamauchi（山内怜史）撰写的一部结构性分析著作。它讲解 Palantir Foundry 的「本体」，但并不把它当作一项 IT 技术，而是视之为一个运营层（operational layer）：以名词（object、property、link）和动词（action、function、dynamic security）为世界建模，并通过「分支与审查」的治理流程，让 AI 能够安全地作用于现实世界的业务运营。正如书中所言，这是一场「从只供查看的数据，到直接驱动业务的数据」的转变。

作者及全部作品目录：github.com/Leading-AI-IO

[¶2]

🏛️ Core Tenets: Three Philosophies of Ontology

While conventional data infrastructure (data lakes and DWHs) has devolved into "dead data swamps built only for viewing," Palantir's paradigm shift is founded on these principles:

  1. The Operational Layer: Data as a Driver of Reality Data is not meant for humans to manually move reality after analysis. Ontology is a "digital twin" that replicates real-world business on a system, serving as the layer where data directly drives business operations.
  2. Convergence of Noun and Verb Systems are understood as the integration of "Objects (nouns)" and "Actions (verbs)." The model encompasses not only states such as customers and parts (semantics), but also kinetic elements such as orders and status changes (kinetics).
  3. Governance of Reality: Version Control for the Real World The immense power to rewrite real-world operations demands absolute governance. Even in an era where AI autonomously makes proposals, Ontology achieves both extreme speed and governance through "branching" and "review."

🏛️ 核心信条：本体的三大理念

传统的数据基础设施（数据湖与 DWH）已经沦为「只供查看的死数据沼泽」，而 Palantir 带来的范式转变，建立在以下原则之上：

  1. 运营层：让数据驱动现实 数据的意义，不在于让人分析之后再手动去推动现实。本体是在系统上复刻现实业务的「数字孪生」，是让数据直接驱动业务运营的那一层。
  2. 名词与动词的融合 系统被理解为「Object（名词）」与「Action（动词）」的整合。这一模型不仅涵盖客户、零部件这类状态（语义，Semantics），也涵盖订单、状态变更这类动力要素（Kinetics）。
  3. 现实的治理：面向现实世界的版本控制 足以改写现实世界业务运营的巨大力量，必然要求绝对的治理。即便在 AI 自主提出方案的时代，本体也能借助「分支」与「审查」，兼顾极致的速度与治理。

[¶3]

📖 Read the Book

You can read the full text from the links below.

👉 Read the full book in English (the-palantir-impact_en.md)

Table of Contents

📖 阅读本书

可通过以下链接阅读全文。

👉 阅读英文版全书（the-palantir-impact_en.md）

目录

[¶4]

Author & Maintainer Satoshi Yamauchi

作者与维护者 Satoshi Yamauchi

[¶5]

Related Projects

This book is part of a series of open-source research projects:

相关项目

本书是一系列开源研究项目中的一部分：

[¶6]

Project Overview Link
The AI Strategist Defining the AI Strategist role with practical frameworks for the BTC intersection GitHub
Depth & Velocity A methodology for new business development in the generative AI era GitHub
The Silence of Intelligence Systematizing Anthropic CEO Dario Amodei's philosophy — Industry Anatomy Series #2 GitHub
The Anatomy of Anthropic A comprehensive dissection of Anthropic's strategy, products, research, and safety GitHub
What They Won't Teach You What the AI-advantaged generation won't teach you about AI and the "Thinking OS" GitHub
The Edge of Intelligence When AI runs on your device: the end of cloud, the beginning of edge GitHub
The Redesign of Design Strategy Redefining design strategy, including a structural analysis of IDEO's decline GitHub
The Orchestrator The first-ever definition of the rarest role in the AI era GitHub
Advertising, Redesigned Why AI will transform advertising from intrusion to a gentle, welcome proposal GitHub
The AI Organization The root cause of AI failure is not technology. Organizational theory for the AI era GitHub
The Structural Shift from SaaS SaaS Is Dead: The Structural Shift from SaaS to Service-as-a-Software GitHub
The 10:80:10 Principle The optimal balance for human-AI synergy:「10:80:10」in the AI era. GitHub
A Trillion Dollars and a Firebomb The Parallel Realities of the AI Era GitHub
The End of the Attention Economy The End of the Attention Economy. What Should the Next SNS Look Like? GitHub
The Growth Engine of Anthropic Decoding the $1T Trajectory GitHub
The Agentic Commerce Economy When AI Agents Buy, the Advertising Model Paradigm Shift GitHub
Will ai break the planet The AI Infrastructure Boom and the Race Against the Climate's Point of No Return GitHub
The-forward-deployed-shift The Forward Deployed Shift — Where Value Survives When "Building" Is Over GitHub
Frontier-Grade Open Weights They Matched the Frontier. But No One Can Hold Them GitHub
Earned-ai-model-optionality AI Models Are Switchable. But Only for Companies That Made Them So GitHub
Us-china-ai-competition The Layers of US-China AI Competition — What is being decided is not who is stronger, but who writes the terms GitHub
The China AI Registry The five Chinese AI models you can name are under 1% of the ones China counts GitHub
项目 概述 链接
The AI Strategist（AI 战略师） 定义 AI 战略师这一角色，并提供面向 BTC 交叉领域的实践框架 GitHub
Depth & Velocity（深度与速度） 生成式 AI 时代的新业务开发方法论 GitHub
The Silence of Intelligence（智能的沉默） 系统梳理 Anthropic CEO Dario Amodei 的思想——「行业解剖」系列第 2 部 GitHub
The Anatomy of Anthropic（解剖 Anthropic） 全面剖析 Anthropic 的战略、产品、研究与安全 GitHub
What They Won't Teach You（他们不会教你的事） 占尽 AI 优势的一代人不会教给你的：AI 与「思考 OS」 GitHub
The Edge of Intelligence（智能的边缘） 当 AI 在你的设备上运行：云端的终结，边缘的开端 GitHub
The Redesign of Design Strategy（设计战略的再设计） 重新定义设计战略，包括对 IDEO 衰落的结构性分析 GitHub
The Orchestrator（编排者） 首次为 AI 时代最稀缺的角色下定义 GitHub
Advertising, Redesigned（广告的再设计） 为什么 AI 会把广告从一种侵扰，转变为温和而受欢迎的提议 GitHub
The AI Organization（AI 组织） AI 失败的根本原因不在技术。面向 AI 时代的组织理论 GitHub
The Structural Shift from SaaS（告别 SaaS 的结构性转变） SaaS 已死：从 SaaS 到 Service-as-a-Software 的结构性转变 GitHub
The 10:80:10 Principle（10:80:10 原则） AI 时代人机协同的最佳平衡：「10:80:10」。 GitHub
A Trillion Dollars and a Firebomb（万亿美元与燃烧弹） AI 时代的平行现实 GitHub
The End of the Attention Economy（注意力经济的终结） 注意力经济的终结。下一代 SNS 应该是什么样子？ GitHub
The Growth Engine of Anthropic（Anthropic 的增长引擎） 解码迈向 1 万亿美元的增长轨迹 GitHub
The Agentic Commerce Economy（智能体商务经济） 当 AI 智能体开始购物：广告模式的范式转移 GitHub
Will ai break the planet（AI 会毁掉地球吗） AI 基础设施热潮，以及与气候不可逆临界点之间的赛跑 GitHub
The-forward-deployed-shift（前置部署转向） 前置部署转向——当「构建」告一段落，价值将在何处存续 GitHub
Frontier-Grade Open Weights（前沿级开放权重） 它们追平了前沿水平。但无人能将其握在手中 GitHub
Earned-ai-model-optionality（挣来的 AI 模型可选性） AI 模型是可以切换的。但只对那些亲手让它们变得可切换的公司成立 GitHub
Us-china-ai-competition（中美 AI 竞争） 中美 AI 竞争的层次——正在决出的不是谁更强，而是由谁来书写规则 GitHub
The China AI Registry（中国 AI 登记名录） 你叫得出名字的那五个中国 AI 模型，还不到中国自己统计在册数量的 1% GitHub

[¶7]

Contribution Issues and Pull Requests are welcome.
If you find any typos or have updated information about Palantir's architecture or Ontology, please feel free to contribute.

License This project is licensed under the CC BY 4.0 License - see the LICENSE file for details.

© 2026 Satoshi Yamauchi / Leading AI — Licensed under CC BY 4.0

参与贡献 欢迎提交 Issue 和 Pull Request。
如果你发现任何错别字，或掌握关于 Palantir 架构或本体的最新信息，欢迎随时参与贡献。

许可证 本项目采用 CC BY 4.0 许可证 授权——详情请参阅 LICENSE 文件。

© 2026 Satoshi Yamauchi / Leading AI —— 依据 CC BY 4.0 授权

[¶8]

正文｜The Palantir Impact（docs/the-palantir-impact_en.md）

正文｜Palantir 冲击（docs/the-palantir-impact_en.md）

[¶9]

The Palantir Impact: Ontology Strategy Connecting Data and AI

Palantir 冲击：连接数据与 AI 的本体战略

[¶10]

Part I: The Problem and the Paradigm

第一部分：问题与范式

[¶11]

Prologue: Why "Data Integration" Fails in the AI Era

Think about your company's data infrastructure (Data Lakes or Data Warehouses).
Huge budgets have been spent to suck data from every system in the company into this infrastructure.
On top of that, BI (Business Intelligence) tools are layered, and beautiful dashboards for executives are updated daily.

However, if you look at the front lines of the business, an unbelievable scene unfolds.
"The sales forecast on this dashboard is wrong. Where is the raw data?" asks a manager passing Excel files around.
"We built a demand forecasting model with AI, but it can't link to the daily ordering system, so I end up typing it in manually while looking at the screen," sighs an operations staff member.
Despite implementing a data infrastructure, business processes remain fragmented.

序章：为什么「数据整合」在 AI 时代会失败

请想一想你所在公司的数据基础设施（数据湖或数据仓库）。
为了把公司内所有系统的数据都抽取到这套基础设施中，公司已经投入了巨额预算。
在此之上又叠加了 BI（商业智能）工具，面向高管的精美仪表盘每天都在更新。

然而，只要去业务一线看一看，就会看到令人难以置信的景象。
「这个仪表盘上的销售预测不对。原始数据在哪里？」一位忙着到处传递 Excel 文件的经理问道。
「我们用 AI 做了需求预测模型，可它没法和日常的订货系统打通，最后我只能一边看着屏幕一边手动录入。」一位运营人员叹息道。
尽管已经建成了数据基础设施，业务流程依然是割裂的。

[¶12]

Why does this tragedy repeat itself in enterprise companies worldwide?
The root cause is that we have historically treated data only as "static snapshots for analysis (data just for viewing)."

为什么这样的悲剧会在全球的大型企业中反复上演？
根本原因在于，长期以来我们一直只把数据当作「供分析用的静态快照（只供查看的数据）」。

[¶13]

flowchart LR
    A[Business Systems: ERP / CRM] -->|Extract via Nightly Batch| B(Data Lake / DWH)
    B --> C{BI Tools / AI Models}
    C -.->|Humans look at screens to decide| D((Frontline Staff))
    D -.->|Manual Re-entry| A

flowchart LR
    A[Business Systems: ERP / CRM] -->|Extract via Nightly Batch| B(Data Lake / DWH)
    B --> C{BI Tools / AI Models}
    C -.->|Humans look at screens to decide| D((Frontline Staff))
    D -.->|Manual Re-entry| A

[¶14]

As the diagram above shows, in traditional system architectures, the "place to store and show data (DWH/BI)" and the "place to execute business and write changes (Business Systems)" are completely disconnected.

As long as this structural disconnect exists, no matter how advanced the AI models introduced are, the final action relies on human "manual work (re-entry)" and cannot scale.

如上图所示，在传统的系统架构中，「存储与展示数据的地方（DWH/BI）」和「执行业务、写入变更的地方（业务系统）」是完全割裂的。

只要这种结构性的割裂依然存在，无论引入的 AI 模型多么先进，最终的行动都要依赖人的「手工作业（重新录入）」，因而无法规模化。

[¶15]

The Paradigm Shift Brought by Palantir: Ontology as an Operational Layer

The "Ontology" strategy by Palantir, explained in this book, is a paradigm shift that fundamentally breaks this deep-rooted disease of silos.

In the context of knowledge engineering and the semantic web, the widely cited academic definition of "ontology" is an "explicit specification of a conceptualization" by Gruber (1993).

Furthermore, Studer et al. (1998) expanded on this, proposing the definition of a "formal, explicit specification of a shared conceptualization."

Palantir 带来的范式转变：作为运营层的本体

本书所讲解的 Palantir「本体」战略，是一场从根本上打破这种根深蒂固的孤岛顽疾的范式转变。

在知识工程与语义网的语境中，被广泛引用的「本体」学术定义，是 Gruber（1993）提出的「对概念化的明确规范说明」。

此外，Studer 等人（1998）在此基础上加以扩展，提出了「对共享概念化的形式化、明确的规范说明」这一定义。

[¶16]

flowchart LR
    A2[Various Data Sources] -->|Indexing| B2{Ontology / Operational Layer}
    B2 -->|Utilize Nouns and Verbs| C2[Decision Apps & AI Models]
    C2 -->|Human Judgment & Automation| D2((Business Actions))
    D2 -->|Write-back results immediately| B2

flowchart LR
    A2[Various Data Sources] -->|Indexing| B2{Ontology / Operational Layer}
    B2 -->|Utilize Nouns and Verbs| C2[Decision Apps & AI Models]
    C2 -->|Human Judgment & Automation| D2((Business Actions))
    D2 -->|Write-back results immediately| B2

[¶17]

This transition from "data just for viewing" to "data that directly drives the business" is the key to true digital transformation in the AI era.

从「只供查看的数据」转向「直接驱动业务的数据」，正是 AI 时代实现真正数字化转型的关键。

[¶18]

Chapter 1: The True Identity of the Mysterious Unicorn "Palantir" and True Data Integration

Before touching the depths of the technology called ontology (from Chapter 2 onwards), we must first understand who "Palantir" is.

They possess a completely different DNA from general cloud vendors like AWS or Snowflake, or SaaS companies like Salesforce.

第 1 章：神秘独角兽「Palantir」的真面目与真正的数据整合

在深入本体这项技术的深层内容（第 2 章起）之前，我们首先必须弄清楚「Palantir」究竟是谁。

他们拥有与 AWS、Snowflake 等通用云厂商，或 Salesforce 等 SaaS 企业截然不同的基因。

[¶19]

1-1. A DNA Born from the CIA and the Battlefield

Palantir Technologies was founded in 2003 by Peter Thiel (co-founder of PayPal) and Alexander Karp, who currently serves as CEO.

Early major investors included In-Q-Tel, the venture capital arm of the CIA (Central Intelligence Agency).

The first platform they developed, "Palantir Gotham," was built for top-secret missions for the U.S. Department of Defense and intelligence agencies, such as tracking terrorist networks and cybersecurity.

On the front lines of battlefields and intelligence, "data silos" and "lack of system integration" are not mere inefficiencies; they are fatal flaws directly leading to "loss of life" and "national crises."

1-1. 诞生于 CIA 与战场的基因

Palantir Technologies 由 Peter Thiel（PayPal 联合创始人）与现任 CEO Alexander Karp 于 2003 年创立。

早期的主要投资方包括 CIA（美国中央情报局）旗下的风险投资机构 In-Q-Tel。

他们开发的第一个平台「Palantir Gotham」，是为美国国防部与情报机构的绝密任务而打造的，例如追踪恐怖分子网络、网络安全等。

在战场与情报工作的第一线，「数据孤岛」和「系统缺乏整合」不只是效率低下的问题，而是直接导致「人命损失」与「国家危机」的致命缺陷。

[¶20]

Connecting fragmented data of all formats, grasping the big picture instantly, and immediately transitioning to the next operation (action)—Palantir's intense obsession with "operations" and "governance" was forged in these extreme environments.

把各种格式的碎片化数据连接起来，瞬间把握全局，并立即转入下一步行动（action）——Palantir 对「运营」与「治理」的强烈执着，正是在这样的极端环境中锻造出来的。

[¶21]

1-2. Not a "Data Box" but an "Organizational OS"

Palantir has established a unique position within the general IT ecosystem.

However, how to use the data in that box to drive the business is left to the customer.

Palantir does not replace these boxes; it sits on top of them, functioning as a "layer that converts data into decision-making and action."

1-2. 不是「数据盒子」，而是「组织 OS」

在整个 IT 生态体系中，Palantir 确立了独树一帜的定位。

然而，如何利用盒子里的数据来驱动业务，则被留给了客户自己。

Palantir 并不取代这些盒子，而是架设在它们之上，充当「把数据转化为决策与行动的层」。

[¶22]

However, the more department-optimized SaaS an enterprise uses, the more siloed the company's data becomes overall.

Palantir integrates data from these scattered SaaS and legacy systems to provide a "single OS" that oversees the entire organization.

然而，企业采用的针对单个部门优化的 SaaS 越多，公司整体的数据就越趋于孤岛化。

Palantir 将分散在这些 SaaS 与遗留系统中的数据整合起来，提供一个统揽整个组织的「单一 OS」。

[¶23]

1-3. From the Battlefield to the Enterprise: The Birth of Foundry and AIP

The protagonist of this book, "Palantir Foundry," was created to apply this overwhelming data integration and analysis expertise cultivated in defense and intelligence agencies to the complex operations of private enterprises (manufacturing, finance, healthcare, supply chains, etc.).

In the Architecture Center documentation, it is stated that the ontology is the core of the Palantir architecture, designed not simply to organize data, but to represent "the complex, interconnected decision-making of an enterprise."

Today, built upon this robust ontology foundation of Foundry, the "AIP (AI Platform)" is deployed to safely integrate the latest Large Language Models (LLMs).

1-3. 从战场走向企业：Foundry 与 AIP 的诞生

本书的主角 「Palantir Foundry」，正是为了把在国防与情报机构中锤炼出的压倒性数据整合与分析能力，应用到商业企业（制造、金融、医疗、供应链等）的复杂业务中而诞生的。

Architecture Center 文档指出，本体是 Palantir 架构的核心，其设计目的并不仅仅是整理数据，而是要表达「企业内部复杂且相互交织的决策」。

如今，在 Foundry 这一稳固的本体基础之上，又部署了 「AIP（AI Platform）」，用于安全地集成最新的大语言模型（LLM）。

[¶24]

AIP functions within the customer's private network, providing an environment where AI can safely execute real-world business tasks.

AIP 在客户的私有网络内运行，提供了一个让 AI 能够安全执行现实世界业务任务的环境。

[¶25]

1-4. Confronting Enterprise Complexity: The Unique "FDE" Organizational Model

Data integration in giant corporations is an extremely difficult project tangled with inter-departmental conflicts and countless legacy systems.

The biggest reason Palantir is supported lies in its implementation approach even more than its excellent software.

According to external analysis (Everest Group), Palantir embeds its own engineers directly into the customer's operational environment, building production workflows on the Palantir stack.

FDSEs (Forward Deployed Software Engineers) focus on a single customer to collaboratively build production-quality workflows.

1-4. 直面企业的复杂性：独特的「FDE」组织模式

在巨型企业中推进数据整合，是一项极其艰巨的工程，其中交织着部门之间的冲突与数不胜数的遗留系统。

比起出色的软件，Palantir 广受支持的最大原因更在于它的实施方式。

据外部机构（Everest Group）分析，Palantir 会将自家工程师直接嵌入客户的运营环境，在 Palantir 技术栈上构建生产级工作流。

FDSE（Forward Deployed Software Engineer，前置部署软件工程师）专注于服务单一客户，与客户协同构建达到生产质量的工作流。

[¶26]

While rapidly building systems on the front lines, the Foundry platform inherently incorporates a design philosophy that maintains governance.

Specifically, Ontology Proposals are explained as a mechanism to make changes in a branch derived from the main version, merging it back to main only after review/approval (similar to a pull request).

Furthermore, Foundry Branching dictates that branches are tied to a "single ontology," and the lifecycle from proposal creation to review and merge is strictly enforced.

在一线快速构建系统的同时，Foundry 平台本身就融入了确保治理的设计理念。

具体来说，Ontology Proposals 被解释为这样一种机制：在从主版本（main）派生出的分支上进行变更，只有经过审查 / 批准后才合并回 main（类似于 pull request）。

此外，Foundry Branching 规定分支与「单一本体」绑定，并严格执行从创建提案到审查、合并的整个生命周期。

[¶27]

1-5. The Day AI Becomes an Engineer: The Impact of AI FDE

Surprisingly, this concept of "Forward Deployed" is extending beyond humans to AI.

Palantir provides an interactive agent called AI FDE (AI-powered forward deployed engineer), which translates natural language requests into Foundry operations, taking over tasks like creating data transformation pipelines, repository management, and ontology construction/maintenance. However, the ontology in Palantir Foundry, while building on the general concept of "ontology as knowledge representation," is designed as an "Operational Layer / Digital Twin" to drive the operations of an organization.

1-5. AI 成为工程师的那一天：AI FDE 带来的冲击

令人惊讶的是，「前置部署（Forward Deployed）」这一理念正在从人类延伸到 AI 身上。

Palantir 提供了一款名为 AI FDE（AI 驱动的前置部署工程师） 的交互式 agent，它能把自然语言请求转化为 Foundry 中的操作，接手创建数据转换管道、管理代码仓库、构建与维护本体等工作。 不过，Palantir Foundry 中的本体虽然建立在「作为知识表示的本体」这一通用概念之上，却被设计为驱动组织运营的 「运营层（Operational Layer）/ 数字孪生（Digital Twin）」。

[¶28]

Foundry's official backend documentation positions the Foundry Ontology as an "Operational Layer for the organization," binding digital assets like datasets to real-world assets and concepts to "function as a digital twin."

Foundry 官方后端文档将 Foundry Ontology 定位为「组织的运营层」，它把数据集等数字资产与现实世界中的资产和概念绑定起来，从而「作为数字孪生发挥作用」。

[¶29]

sequenceDiagram
    participant User as Business Expert
    participant AIFDE as AI FDE
    participant Ontology as Ontology
    participant Admin as Reviewer
    
    User->>AIFDE: "Build an ontology from new data"
    Note over AIFDE: Strictly respects user's existing permissions
    AIFDE->>Ontology: Create & build a working branch
    AIFDE->>User: Present branch proposal for review
    User->>Admin: Request review of the proposal
    Admin-->>Ontology: Merge to main after human approval

sequenceDiagram
    participant User as Business Expert
    participant AIFDE as AI FDE
    participant Ontology as Ontology
    participant Admin as Reviewer
    
    User->>AIFDE: "Build an ontology from new data"
    Note over AIFDE: Strictly respects user's existing permissions
    AIFDE->>Ontology: Create & build a working branch
    AIFDE->>User: Present branch proposal for review
    User->>Admin: Request review of the proposal
    Admin-->>Ontology: Merge to main after human approval

[¶30]

Hearing that AI builds systems automatically might raise fears of it running out of control, but this operation is designed to "respect the user's existing permissions" and "always present a branch proposal for review."

This significantly reduces the risk of misuse or excessive exposure of sensitive data, allowing humans and AI to collaborate safely.

听到 AI 会自动构建系统，有人或许会担心它失控；但这项操作在设计上就要求「尊重用户现有的权限」，并且「始终提交分支提案以供审查」。

这大大降低了敏感数据被滥用或过度暴露的风险，使人类与 AI 能够安全地协作。

[¶31]

Chapter 2: What is "Ontology", the Heart of Palantir?

To truly understand Palantir Foundry and revolutionize your business, you need a deep understanding of the paradigm shift brought by the "Ontology" concept.

This chapter delves into the unique architecture that models the world using "Nouns and Verbs."

第 2 章：Palantir 的核心——「本体」究竟是什么？

要真正理解 Palantir Foundry 并借此变革你的业务，就必须深入理解「本体」这一概念所带来的范式转移。

本章将详细解析这种以「名词与动词」为世界建模的独特架构。

[¶32]

2-1. Modeling the Data World with "Nouns" and "Verbs"

The biggest reason Palantir's ontology outperforms others is that it defines the system as an integration of Semantics (objects, properties, links) and Kinetics (actions, functions, dynamic security).

Usually, database design ends with the design of "nouns (data)," while "verbs (business logic and update processes)" are separated into another application layer.

However, in Foundry, the necessary elements are explicitly divided into semantic elements and kinetic elements and defined together.

1. Semantic Elements (The World of Nouns: Meaning)

2-1. 用「名词」与「动词」为数据世界建模

Palantir 的本体之所以优于其他方案，最大的原因在于：它把系统定义为 语义（Semantics）（object、property、link）与 动力（Kinetics）（action、function、dynamic security）的整合。

通常，数据库设计止步于「名词（数据）」的设计，而「动词（业务逻辑与更新流程）」则被剥离到另一个应用层中。

然而在 Foundry 中，所需的要素被明确划分为语义要素与动力要素，并放在一起统一定义。

1. 语义要素（名词的世界：含义）

[¶33]

2. Kinetic Elements (The World of Verbs: Movement)

2. 动力要素（动词的世界：运动）

[¶34]

flowchart LR
    subgraph Semantics [World of Nouns: Semantics]
        O[Object] ---|has| P[Property]
        O ---|connects| L[Link]
    end
    subgraph Kinetics [World of Verbs: Kinetics]
        A[Action] -->|Modifies property| O
        F[Function] -->|Calculates logic| O
    end

flowchart LR
    subgraph Semantics [World of Nouns: Semantics]
        O[Object] ---|has| P[Property]
        O ---|connects| L[Link]
    end
    subgraph Kinetics [World of Verbs: Kinetics]
        A[Action] -->|Modifies property| O
        F[Function] -->|Calculates logic| O
    end

[¶35]

By creating a "model for viewing" and a "model for changing" simultaneously—closing the data model to include update pathways—AI and applications can execute safe actions against the real world without hesitation.

通过同时构建「用于查看的模型」与「用于变更的模型」——也就是让数据模型把更新路径一并纳入、形成闭环——AI 与应用程序便能毫不迟疑地对现实世界执行安全的操作。

[¶36]

Part II: The Architecture of Action

第二部分：行动的架构

[¶37]

Chapter 3: [Visualized] Architecture Supporting the Ontology

The ontology is not merely a conceptual idea; it is physically supported by extremely robust microservices.

To model the real world on a system, a powerful backend that processes "semantics (definition)" and "kinetics (execution)" is essential.

第 3 章：【图解】支撑本体的架构

本体并不只是一个概念层面的构想，它在物理上由极其稳健的微服务支撑。

要在系统上为现实世界建模，一个能够处理「语义（定义）」与「动力（执行）」的强大后端必不可少。

[¶38]

3-1. Five Pillars of the Architecture

In Foundry's official backend documentation, the architecture centers around Object Storage V2, with the following services sharing distinct responsibilities:

3-1. 架构的五大支柱

根据 Foundry 官方后端文档，该架构以 Object Storage V2 为中心，由以下服务分担各自不同的职责：

[¶39]

flowchart LR
    subgraph backend ["Foundry Ontology Backend"]
        F["Funnel<br>(Reads Data & Indexing)"]
        OMS["OMS<br>(Metadata & Schema Definition)"]
        ODB[("Object databases<br>(Store Index Data & Edit Mediation)")]
        OSS["OSS<br>(Search, Filter, Aggregate, Load)"]
        ACT["Actions<br>(Apply User Edits & Transactions)"]
        
        F -->|"Indexing"| ODB
        OMS -.->|"Schema Reference"| ODB
        ODB -->|"Provide Data"| OSS
        ACT -->|"Apply Edits (Writes)"| ODB
    end
    style ODB fill:#e6e6fa,stroke:#333,stroke-width:2px

flowchart LR
    subgraph backend ["Foundry Ontology Backend"]
        F["Funnel<br>(Reads Data & Indexing)"]
        OMS["OMS<br>(Metadata & Schema Definition)"]
        ODB[("Object databases<br>(Store Index Data & Edit Mediation)")]
        OSS["OSS<br>(Search, Filter, Aggregate, Load)"]
        ACT["Actions<br>(Apply User Edits & Transactions)"]
        
        F -->|"Indexing"| ODB
        OMS -.->|"Schema Reference"| ODB
        ODB -->|"Provide Data"| OSS
        ACT -->|"Apply Edits (Writes)"| ODB
    end
    style ODB fill:#e6e6fa,stroke:#333,stroke-width:2px

[¶40]

3-2. Indexing the Real World and Physical Constraints

"Indexing" converts data into ontology-ready indexes. Funnel oversees this, utilizing either batch (Funnel batch) or streaming (Funnel streaming) pipelines depending on the use case.

Indexing targets Object Storage V2, and Funnel coordinates the pipelines to create and modify object instances, keeping data and metadata up-to-date.

However, architects must also understand physical constraints.

3-2. 现实世界的索引化与物理约束

「索引化（Indexing）」是指将数据转换为本体可用的索引。这一过程由 Funnel 统筹，并根据用例选用批处理（Funnel batch）或流式（Funnel streaming）管道。

索引化以 Object Storage V2 为目标，Funnel 通过协调各条管道来创建和修改对象实例，使数据与元数据始终保持最新。

不过，架构师也必须了解其中的物理约束。

[¶41]

Streaming object types currently have limitations, such as not supporting user edits or MDOs (Multi-Dataset Objects), which are officially listed.

流式 object type 目前存在一些限制，例如不支持用户编辑、不支持 MDO（Multi-Dataset Objects，多数据集对象），官方文档已明确列出这些限制。

[¶42]

Chapter 4: "Governance and Security" Supporting the Enterprise

When data becomes an "operational layer," system changes immediately drive the real-world business.

For an analytical dashboard, if the data is wrong, the worst that happens is "the graph looks weird." However, in an environment where ordering and status changes are automated through the ontology,

a single malfunction directly leads to fatal real-world damage (incidents), such as "mistakenly ordering 10,000 unnecessary parts" or "stopping a factory production line."

Because it possesses the power to rewrite reality at overwhelming speeds, Palantir embeds robust governance and fail-safe mechanisms at the foundation of the platform, far surpassing general IT tools.

第 4 章：支撑企业的「治理与安全」

当数据成为「运营层（operational layer）」时，系统中的变更会立即驱动现实世界的业务。

如果只是分析型仪表盘，数据出错最坏也不过是「图表看起来有点怪」。然而，在通过本体实现下单与状态变更自动化的环境中，

一次故障就会直接造成致命的现实损害（事故），例如「误订 10,000 个根本不需要的零件」或「让工厂产线停摆」。

正因为具备以压倒性速度改写现实的力量，Palantir 在平台底层嵌入了远超一般 IT 工具的强健治理与故障安全（fail-safe）机制。

[¶43]

4-1. The Security Paradigm Shift: From "Hiding" to "Moving Safely"

In traditional enterprise IT, security mainly meant "hiding data (access restrictions and encryption)."

However, in an ontology-driven architecture, the definition of security elevates to "preventing erroneous changes and destruction to the real world."

Who can execute what business logic (action) based on which data?

Strict control over these "Kinetic Elements" is the true identity of the resilient governance Foundry inherited from military and intelligence agencies.

4-1. 安全范式的转变：从「隐藏」到「安全运转」

在传统企业 IT 中，安全主要意味着「隐藏数据（访问限制与加密）」。

然而，在本体驱动的架构中，安全的定义被提升为「防止对现实世界造成错误变更与破坏」。

谁能基于哪些数据、执行哪些业务逻辑（动作）？

对这些「动力要素（Kinetic Elements）」实施严格管控，正是 Foundry 从军方和情报机构继承而来的强韧治理的本质所在。

[¶44]

4-2. The Lifecycle of "Branches" and Reviews in the Data World

Palantir brought the historically proven best practices of "version control" and "peer review" in software engineering directly into data modeling and real-world operational processes.

The core of this is the Branching and Proposal mechanism.

Changes are safely made on a "working branch" derived from the main version, tested, and only merged into the main environment after review and approval.

4-2. 数据世界里「分支」与评审的生命周期

Palantir 把软件工程中久经检验的「版本控制」与「同行评审」最佳实践，直接带入了数据建模和现实世界的运营流程。

其核心在于 分支（Branching） 与 提案（Proposal） 机制。

变更会在从主版本派生出的「工作分支」上安全地进行并完成测试，只有经过评审与审批，才会合并进主环境。

[¶45]

This applies the concept of Pull Requests, commonly used in development, to data operations.

Because the lifecycle from proposal creation to review and merge is enforced at the platform level, shadow IT or unauthorized operational changes by specific personnel can be structurally eliminated.

这相当于把开发中常用的 Pull Request 概念应用到了数据运营上。

由于从创建提案到评审、合并的整个生命周期都在平台层面强制执行，影子 IT 以及特定人员未经授权的运营变更都能从结构上被杜绝。

[¶46]

stateDiagram-v2
    direction LR
    [*] --> Create_Working_Branch: Real-world operational needs change
    Create_Working_Branch --> Change_on_Ontology: Test & Edit Schema
    Change_on_Ontology --> Submit_Proposal: Request review
    Submit_Proposal --> Under_Review: Approvals App
    
    Under_Review --> Sent_Back: Reject
    Sent_Back --> Change_on_Ontology
    
    Under_Review --> Merge_to_Main: Approve
    Merge_to_Main --> [*]: Reflect immediately to enterprise systems

stateDiagram-v2
    direction LR
    [*] --> Create_Working_Branch: Real-world operational needs change
    Create_Working_Branch --> Change_on_Ontology: Test & Edit Schema
    Change_on_Ontology --> Submit_Proposal: Request review
    Submit_Proposal --> Under_Review: Approvals App
    
    Under_Review --> Sent_Back: Reject
    Sent_Back --> Change_on_Ontology
    
    Under_Review --> Merge_to_Main: Approve
    Merge_to_Main --> [*]: Reflect immediately to enterprise systems

[¶47]

4-3. The "Approvals App" Supporting Complex Organizations

In giant enterprise companies, "who has approval authority" is itself complex.

To support consensus building among diverse stakeholders such as department heads, compliance officers, and data owners, Foundry provides a dedicated "Approvals" app.

This app centralizes approval workflows and seamlessly integrates peer reviews and compliance checks.

This completely brings transparency to the process itself: "when, who, and for what reason the change was approved."

4-3. 支撑复杂组织的「Approvals 应用」

在大型企业中，「谁拥有审批权限」这件事本身就很复杂。

为了支持部门负责人、合规官、数据所有者等多元利益相关方达成共识，Foundry 提供了专门的「Approvals」应用。

该应用将审批工作流集中管理，并把同行评审与合规检查无缝整合在一起。

这让「变更在何时、由谁、出于何种理由获批」这一流程本身变得完全透明。

[¶48]

4-4. Precise Access Control and the Ultimate Audit Trail "Action Log"

Control over "show/hide" and recording "who did what" are implemented at a resolution incomparable to traditional DWHs.

"Column/property-level" control via Multi-Dataset Object types (MDO) is also officially supported.

This enables precise governance, such as "customer purchase history is shared company-wide, but personally identifiable names and phone numbers can only be seen by specific departments."

Furthermore, the authorization model is transitioning from data-source-dependent permissions to an ontology roles-based model.

4-4. 精细的访问控制与终极审计追踪「Action Log」

对「显示 / 隐藏」的控制和对「谁做了什么」的记录，都以传统 DWH 无法比拟的精细度实现。

通过 Multi-Dataset Object types（MDO）实现的「列级 / property 级」控制，同样获得官方支持。

这使得精细化治理成为可能，例如「客户购买记录在全公司共享，但可识别个人身份的姓名与电话号码仅限特定部门查看」。

此外，授权模型正从依赖数据源的权限，转向基于本体角色（ontology roles）的模型。

[¶49]

In Foundry, every action submission is modeled as an "object type itself" and recorded permanently.

Corresponding 1-to-1 with the Action type, a log object detailing who, when, and what data was rewritten is automatically generated for each submission and linked to the edited target object.

This ensures complete, semi-permanent traceability.

在 Foundry 中，每一次动作提交都被建模为「object type 本身」并永久记录下来。

日志对象与 Action type 一一对应：每次提交都会自动生成一个日志对象，详细记录由谁、在何时、改写了哪些数据，并关联到被编辑的目标对象上。

这确保了完整且近乎永久的可追溯性。

[¶50]

Part III: The Destiny of Intelligence

第三部分：智能的命运

[¶51]

Chapter 5: Palantir Use Cases Changing the World and Japan

How exactly does the "Operational Layer" called ontology change the dynamics of business?

Born from extreme defense environments, this platform is now solving highly realistic business challenges for global corporations and Japanese infrastructure companies alike.

We increase the resolution of its overwhelming track record based on published primary sources.

第 5 章：改变世界与日本的 Palantir 应用案例

被称为本体的「运营层」，究竟会如何改变业务的运转方式？

这个诞生于极端国防环境的平台，如今正为全球企业和日本基础设施企业解决极其现实的业务难题。

本章将依据已公开的一手资料，更细致地还原它压倒性的实绩。

[¶52]

5-1. Aviation & Manufacturing: Airbus (The 5 Million Part Digital Twin and Skywise)

The partnership between Palantir and European aviation giant Airbus is a monumental achievement in ontology utilization in manufacturing.

What they faced was the very "limit of silos."

Previously, data on part delays and quality issues was scattered, and no one could grasp the "complete picture until the aircraft was finished."

By integrating this decentralized data into Foundry's ontology and linking the relationships between all parts and schedules,

5-1. 航空与制造：Airbus（500 万个零件的数字孪生与 Skywise）

Palantir 与欧洲航空巨头 Airbus 的合作，是本体在制造业应用中具有里程碑意义的成果。

他们当时面对的，正是「数据孤岛的极限」。

过去，零件延误与质量问题的数据分散各处，谁都无法掌握「飞机完工之前的全貌」。

通过把这些分散的数据整合进 Foundry 的本体，并关联起所有零件与排程之间的关系，

[¶53]

it became possible to identify bottlenecks and prioritize tasks, successfully accelerating A350 delivery by 33%.

Currently, over 100 airlines use this foundation, processing petabytes of time-series data on the ontology—"20 to 100 data points per second" obtained from up to 20,000 sensors per aircraft.

This enables part failure prediction and preventive maintenance, dramatically reducing the risk of flight cancellations.

得以识别瓶颈、确定任务优先级，成功让 A350 的交付提速 33%。

目前已有 100 多家航空公司使用这一基础平台，在本体上处理 PB 级的时序数据——即从每架飞机多达 20,000 个传感器采集的「每秒 20 到 100 个数据点」。

这使零部件故障预测和预防性维护成为可能，大幅降低了航班取消的风险。

[¶54]

5-2. Insurance & Healthcare: SOMPO (Building a Real Data Platform)

In Japan as well, the ontology is deeply penetrating the mission of optimizing social infrastructure.

SOMPO Holdings adopted Palantir as the core of its "Real Data Platform (RDP)" concept.

Rather than just collecting data, it is utilized as decision-making support for frontline staff to determine the next optimal action (care support or emergency response).

5-2. 保险与医疗健康：SOMPO（构建 Real Data Platform）

在日本，本体同样正深度融入「优化社会基础设施」这一使命之中。

SOMPO Holdings 将 Palantir 作为其「Real Data Platform（RDP，真实数据平台）」构想的核心。

这些数据不只是被收集起来，而是用作决策支持，帮助一线员工判断下一步的最佳行动（护理支援或紧急应对）。

[¶55]

Over 8,000 people in Japan actively use this platform for their daily work, successfully replacing "manual tasks" on the front lines with "actions" on the ontology.

在日本，已有超过 8,000 人在日常工作中积极使用这一平台，成功将一线的「手工作业」替换为本体上的「动作」。

[¶56]

5-3. The Japanese Enterprise Ecosystem: Fujitsu × Palantir

Furthermore, to break through the legacy system environments unique to Japan, powerful partnerships have been formed.

In a press release (December 2023), Fujitsu emphasized that Fujitsu and Palantir Japan have expanded their global partnership.

Many large Japanese companies confine their data to on-premises or private networks due to cloud security concerns.

This is where the combination of "AIP (AI Platform)" and "Foundry"—safely utilizing LLMs within a customer's closed network—comes into play.

With this foundation connecting data, analytics, and operations, the social implementation of true data-driven business is rapidly advancing even in Japanese financial institutions, government agencies, and manufacturing industries with strict security requirements.

5-3. 日本企业生态：Fujitsu × Palantir

此外，为突破日本特有的遗留系统环境，强有力的合作伙伴关系也已建立起来。

Fujitsu 在一份新闻稿（2023 年 12 月）中强调，Fujitsu 与 Palantir Japan 已扩大双方的全球合作伙伴关系。

出于对云安全的顾虑，许多日本大企业将数据封闭在本地部署（on-premises）环境或私有网络之中。

而这正是「AIP（AI Platform）」与「Foundry」组合的用武之地——在客户的封闭网络内安全地使用 LLM。

依托这一连接数据、分析与运营的基础平台，即便在安全要求严苛的日本金融机构、政府部门和制造业，真正数据驱动型业务的社会落地也在迅速推进。

[¶57]

Chapter 6: The Future Brought by Ontology × AI

Currently, companies worldwide are rushing to "implement Generative AI (LLMs) internally."

However, most of this stops at superficial efficiencies like "internal chatbots" and "meeting summaries."

The reason is clear: AI lacks the "common language (ontology)" and "hands and feet (actions)" to drive real business.

第 6 章：本体 × AI 带来的未来

当下，全球企业都在争相「在内部引入生成式 AI（LLM）」。

然而，其中大多数都止步于「内部聊天机器人」「会议纪要总结」这类表面上的效率提升。

原因很明确：AI 缺少驱动真实业务所需的「共同语言（本体）」和「手脚（动作）」。

[¶58]

6-1. Containing Hallucinations via the Wall of "Semantics" and LLM Limits

Large Language Models (LLMs) possess exceptional reasoning and natural language processing capabilities, but they cannot directly operate real-world systems like "Company A is running out of stock, so ship 100 units from Warehouse B."

Furthermore, they cannot fully comprehend internal regulations and complex business contexts, constantly carrying the risk of causing hallucinations (plausible lies).

Here, the ontology functions as the "robust foundation" for AI.

Under Foundry's AIP (AI Platform) environment, AI does not read "raw, miscellaneous data" but an ontology strictly defined and structured as "nouns (objects)" and "verbs (actions)."

6-1. LLM 的局限与借「语义」之墙遏制幻觉

大语言模型（LLM）拥有卓越的推理与自然语言处理能力，却无法像「A 公司快缺货了，从 B 仓库发 100 件过去」这样直接操作现实世界的系统。

此外，它们无法完全理解企业内部规章与复杂的业务上下文，始终伴随着产生幻觉（看似合理的谎言）的风险。

此时，本体便成为 AI 的「坚实地基」。

在 Foundry 的 AIP（AI Platform）环境下，AI 读取的不是「未经加工的杂乱数据」，而是以「名词（对象）」和「动词（动作）」严格定义并结构化的本体。

[¶59]

Because AI can only infer and propose within the scope of "defined actions," context contamination and hallucinations are eliminated to the absolute limit, enabling safe execution of real-world actions.

由于 AI 只能在「已定义的动作」范围内进行推理和提议，上下文污染与幻觉被最大限度地排除，从而能够安全地在现实世界中执行动作。

[¶60]

flowchart LR
    subgraph standard_ai ["Traditional AI Utilization<br>(Risks and Limitations)"]
        direction LR
        A1[("Raw Siloed Data")] -->|"Direct Access / Search"| B1(("General-purpose LLM"))
        B1 -.->|"Lack of Context"| C1["Hallucination / Incorrect Inference"]
        C1 -.->|"Cannot Write Directly to Systems"| D1(("Reliance on Manual Work<br>(Does not scale)"))
    end
    style C1 fill:#fcc,stroke:#f33,stroke-width:2px

flowchart LR
    subgraph palantir_aip ["Palantir AIP + Ontology<br>(Safety and Scalability)"]
        direction LR
        A2[("Various Data Sources")] -->|"Indexing"| B2{"Ontology: Definition<br>of Nouns and Verbs"}
        B2 -->|"Provides Permissions and Structured Data"| C2(("LLM on AIP"))
        C2 -->|"Infers Only Within Defined Scope"| D2["Action Proposal"]
        D2 -->|"Human Review & Approval"| E2(("Safe Execution of Business<br>(Reflected Immediately in System)"))
    end
    style E2 fill:#cfc,stroke:#393,stroke-width:2px

flowchart LR
    subgraph standard_ai ["Traditional AI Utilization<br>(Risks and Limitations)"]
        direction LR
        A1[("Raw Siloed Data")] -->|"Direct Access / Search"| B1(("General-purpose LLM"))
        B1 -.->|"Lack of Context"| C1["Hallucination / Incorrect Inference"]
        C1 -.->|"Cannot Write Directly to Systems"| D1(("Reliance on Manual Work<br>(Does not scale)"))
    end
    style C1 fill:#fcc,stroke:#f33,stroke-width:2px

flowchart LR
    subgraph palantir_aip ["Palantir AIP + Ontology<br>(Safety and Scalability)"]
        direction LR
        A2[("Various Data Sources")] -->|"Indexing"| B2{"Ontology: Definition<br>of Nouns and Verbs"}
        B2 -->|"Provides Permissions and Structured Data"| C2(("LLM on AIP"))
        C2 -->|"Infers Only Within Defined Scope"| D2["Action Proposal"]
        D2 -->|"Human Review & Approval"| E2(("Safe Execution of Business<br>(Reflected Immediately in System)"))
    end
    style E2 fill:#cfc,stroke:#393,stroke-width:2px

[¶61]

6-2. The Elimination of Operational Build Costs via AI FDE

Furthermore, Palantir has elevated AI from a mere "user assistance tool" to an "engineer that builds systems itself (AI FDE)."

Previously, building a data integration foundation required data engineers to spend enormous amounts of time connecting data sources, mapping, and constructing pipelines.

However, with the advent of the AI-powered forward deployed engineer (interactive agent), the world completely changes.

By simply requesting in natural language, "Build a customer ontology from new CRM data," the AI translates this into Foundry operation commands, automatically acting as an agent to create data pipelines and maintain the ontology.

6-2. 借助 AI FDE 消除运营系统的构建成本

此外，Palantir 已将 AI 从单纯的「用户辅助工具」提升为「亲自构建系统的工程师（AI FDE）」。

过去，要搭建数据集成底座，数据工程师必须投入大量时间去连接数据源、做映射、构建管道。

然而，随着 AI 驱动的 forward deployed engineer（交互式智能体）问世，局面彻底改观。

只需用自然语言提出「用新的 CRM 数据构建客户本体」这样的请求，AI 就会将其转换为 Foundry 的操作指令，以智能体的身份自动创建数据管道并维护本体。

[¶62]

6-3. A Platform Supporting the "Co-evolution of Humans and AI"

Is it dangerous to let AI build systems? No, Palantir's architecture prevents this.

AI FDE strictly respects the user's existing permissions and lets them choose the tools and data exposed to the model.

When making changes, it always creates a "Branch Proposal" and presents it for human review.

Humans are freed from the tedious task of "connecting data" and shift to the advanced role of reviewing and approving the ontologies built and actions proposed by AI to ensure they "align with business intent."

It is precisely because of the common language called ontology that humans and AI can collaborate safely and equally for the first time, evolving the business scalably.

6-3. 支撑「人与 AI 协同进化」的平台

让 AI 来构建系统，会不会有危险？不会，Palantir 的架构能够防范这一点。

AI FDE 严格遵循用户既有的权限，并允许用户自行选择向模型开放哪些工具和数据。

进行变更时，它必定会创建「分支提案（Branch Proposal）」，交由人类审核。

人类由此从「连接数据」这类繁琐工作中解放出来，转而承担更高阶的角色：审核并批准 AI 构建的本体和提出的动作，确保它们「符合业务意图」。

正是因为有了本体这门共同语言，人类与 AI 才第一次能够安全、平等地协作，以可扩展的方式推动业务演进。

[¶63]

Epilogue: Design Your Organization's Data with Ontology Thinking

We are standing at a decisive turning point from the "era of viewing data" to the "era where data directly drives decision-making."

No matter how smart AI becomes, as long as a company's data remains "the wreckage of siloed systems," its intelligence will not reach the front lines of business.

Building an ontology is not merely the introduction of an IT system.

It is synonymous with redefining your own business with "nouns" and "verbs" and creating a "common language for the entire organization" for humans, AI, and systems to converse.

终章：用本体思维设计你的组织数据

我们正站在一个决定性的转折点上：从「查看数据的时代」迈向「数据直接驱动决策的时代」。

无论 AI 变得多么聪明，只要企业的数据仍是「孤岛系统的残骸」，AI 的智能就无法触达业务一线。

构建本体，并不只是引入一套 IT 系统。

它等同于用「名词」和「动词」重新定义自身业务，并打造一门供人、AI 与系统彼此对话的「全组织共同语言」。

[¶64]

Step-by-Step Curriculum for Implementation (Action Plan)

Building an ontology-driven architecture may seem grand, but it can be steadily advanced step by step.

Based on official documentation, we recommend the following step-by-step approach as a learning and implementation roadmap.

分步实施课程（行动计划）

构建本体驱动的架构看似宏大，但完全可以一步一步稳扎稳打地推进。

我们以官方文档为依据，推荐采用以下分步方法，作为学习与实施的路线图。

[¶65]

flowchart LR
    Start(("Siloed Legacy<br>IT Assets")) --> S1
    
    subgraph Roadmap ["Ontology Implementation STEP"]
        direction LR
        S1["1. Understand<br>Structure & Permissions"] --> S2["2. Minimum<br>Modeling"]
        S2 --> S3["3. Data<br>Indexing"]
        S3 --> S4["4. Design Audit<br>& Governance"]
        S4 --> S5["5. Integrate with<br>AI & Apps"]
    end
    
    S5 --> Goal(("Living Engine<br>Driving the Business"))

    style Start fill:#eee,stroke:#999
    style Goal fill:#bfdbfe,stroke:#2563eb,stroke-width:4px
    style S1 fill:#fff,stroke:#666
    style S2 fill:#fff,stroke:#666
    style S3 fill:#fff,stroke:#666
    style S4 fill:#fff,stroke:#666
    style S5 fill:#fff,stroke:#666

flowchart LR
    Start(("Siloed Legacy<br>IT Assets")) --> S1
    
    subgraph Roadmap ["Ontology Implementation STEP"]
        direction LR
        S1["1. Understand<br>Structure & Permissions"] --> S2["2. Minimum<br>Modeling"]
        S2 --> S3["3. Data<br>Indexing"]
        S3 --> S4["4. Design Audit<br>& Governance"]
        S4 --> S5["5. Integrate with<br>AI & Apps"]
    end
    
    S5 --> Goal(("Living Engine<br>Driving the Business"))

    style Start fill:#eee,stroke:#999
    style Goal fill:#bfdbfe,stroke:#2563eb,stroke-width:4px
    style S1 fill:#fff,stroke:#666
    style S2 fill:#fff,stroke:#666
    style S3 fill:#fff,stroke:#666
    style S4 fill:#fff,stroke:#666
    style S5 fill:#fff,stroke:#666

[¶66]

  1. Understand Infrastructure and Permission Models (Month 1) First, understand the roles of backend components such as OMS / OSS / Funnel / Actions / Object databases. Simultaneously, learn Palantir's unique permission models like RVs (Restricted Views) and ontology roles to solidify the foundation of governance.
  2. Minimum Modeling and Branch Operations (Month 2) Actually design Objects / Links / Actions in a specific, small domain (e.g., inventory management for a single product line). Here, it is crucial to experience the process of defining submission criteria and side effects for actions, creating a Proposal, and reviewing/approving it.
  3. Validating Data Pipelines (Month 3) Build a data flow where data from sources is indexed via Funnel into OSv2, making it searchable and aggregatable. After understanding the differences between batch and streaming processing and their respective physical limitations, validate the freshness and stability of data to ensure it can withstand actual operations.
  4. Designing Audit and Governance Rules (Month 4) Design operational rules for Action-driven updates, action log generation, and materialization (persistence). Enable the Action Log feature and check how edits made by whom are reflected and tracked in the production data, aligning with your company's compliance requirements.
  5. Integration with AI and External Applications (Month 5+) Make the completed ontology safely readable and writable from external systems, AIP, and custom applications. Generate the OSDK (Ontology SDK) in the Developer Console and drive the ontology from actual business apps under appropriate token control.
  1. 理解基础设施与权限模型（第 1 个月） 首先，理解 OMS / OSS / Funnel / Actions / Object databases 等后端组件各自承担的职责。同时学习 RVs（Restricted Views，受限视图）、本体角色（ontology roles）等 Palantir 特有的权限模型，夯实治理基础。
  2. 最小化建模与分支操作（第 2 个月） 选定一个具体的小领域（例如单一产品线的库存管理），动手设计 Objects / Links / Actions。这一步的关键，是亲身走完整个流程：为动作定义提交条件（submission criteria）与副作用（side effects），创建 Proposal，再对其进行审核与批准。
  3. 验证数据管道（第 3 个月） 搭建一条数据流：来自数据源的数据经 Funnel 索引进 OSv2，从而可被搜索、可被聚合。在理解批处理与流处理的差异及各自的物理限制之后，验证数据的新鲜度与稳定性，确保其经得起实际运营的考验。
  4. 设计审计与治理规则（第 4 个月） 为 Action 驱动的更新、动作日志（action log）的生成以及物化（持久化）设计运营规则。启用 Action Log 功能，检查由谁做出的哪些编辑是如何反映到生产数据中、又是如何被追踪的，并使之与本公司的合规要求对齐。
  5. 与 AI 及外部应用集成（第 5 个月起） 让外部系统、AIP 以及自定义应用都能安全地读写建成的本体。在 Developer Console 中生成 OSDK（Ontology SDK），并在恰当的 token 管控下，从真实的业务应用中驱动本体。

[¶67]

Data only brings "Impact" to society when it connects with the intent of the people utilizing it and is transformed into real-world action.

Break away from legacy IT assets that only let you stare at analysis results. With the ontology as your new compass, transform your organization's data from a "dead record" into a "living engine driving the business."

数据只有与使用者的意图相连、转化为现实世界中的行动，才能为社会带来「影响力（Impact）」。

告别那些只能让人盯着分析结果看的遗留 IT 资产吧。以本体为新的罗盘，把组织的数据从「僵死的记录」变成「驱动业务的鲜活引擎」。

[¶68]

References - English Version

The following sources were referenced to define technological concepts, verify architectural specifications, and document real-world impacts.

1. Academic Papers

参考文献（英文版）

为界定技术概念、核实架构规格并记录现实世界中的实际影响，本书参考了以下资料。

1. 学术论文

[¶69]

2. Palantir Official Resources

3. Case Studies and Impact Reports

2. Palantir 官方资料

3. 案例研究与影响力报告