工程级推演：Mini-Palantir 架构蓝图
本文对 Palantir Ontology 体系做一次工程级架构推演：从 Object、ObjectType、Property、Link、Action、Function、ObjectSet、Interface 八个核心概念出发，逐步推出 Declarative / Imperative 双核结构、数据库 Schema、ObjectSet / Query、Action Gateway、Function Runtime，以及作为收尾的 OMS / Meta-Ontology。
推演严格区分「已知事实」与「工程推演」：前者来自 Palantir 官方公开资料并附引用，后者是对未公开部分基于工程常识的合理重建。
文中示例使用虚构的 Game / AdNetwork / AdPlacement 广告对象模型作为教学占位，不代表任何真实业务。
先说明边界：本文不是对 Palantir 内部源码实现的声称——Palantir 未公开其全部内部实现。文中把官方公开的 Ontology Language、Ontology Backend、Object Set Service、Actions、Functions、Interfaces 等资料作为「已知事实」，对未公开部分做工程级推演，并明确区分「已知事实」与「推演」。
Palantir 官方目前把 Object Type、Property、Link Type、Action Type、Function、Interface、Object View 等作为 Ontology 的核心概念；后端由 OMS、Object Database、Object Set Service、Actions、Object Data Funnel、Functions on Objects 等服务共同支撑。（Palantir 核心概念）
一、逆向工程方法：五层连续追问
切入方式不是直接发问：
Palantir 的 Object 是什么？
而是沿五个层面连续追问：
1. Semantic Definition
↓
2. Database Schema
↓
3. API Contract
↓
4. Runtime Behavior
↓
5. Security / Transaction / Event
最终落地为：
Ontology Language
↓
Metadata Model
↓
Runtime Model
↓
API Model
↓
Mini-Palantir
二、结论先行：8 个概念并不平级
这是第一处非常重要的发现。
表面上：
Object
ObjectType
Property
Link
Action
Function
ObjectSet
Interface
呈现为 8 个并列概念。
实际结构更接近：
Ontology
│
┌────────┴────────┐
│ │
Type System Runtime System
│ │
┌───────┼───────┐ ┌───┼────┐
│ │ │ │ │ │
Object Link Interface ObjectSet
│ │ │
└───────┼───────┘
│
Action / Function
│
↓
Mutation
换句话说：
Semantic
ObjectType
Property
Link
Interface
负责描述：
世界是什么。
Runtime
Object
ObjectSet
Function
Action
负责：
读取世界、计算世界、改变世界。
这与 Palantir 官方的表述已经非常接近：
semantic elements + kinetic elements
其中 objects/properties/links 属于 semantic，actions/functions 属于 kinetic。(Palantir)
三、第一件事：ObjectType
1. 它到底是什么？
官方定义：
Object Type 是现实世界实体或事件的 schema definition。Object 是这个 Object Type 的一个实例。(Palantir)
所以：
ObjectType
↓
Object
↓
现实世界实体
例如：
Game
是 ObjectType。
Game#com.example.game.123
是 Object。
四、ObjectType 数据库设计
以 Mini-Palantir 为例，第一步是建表：
CREATE TABLE object_types (
id UUID PRIMARY KEY,
api_name VARCHAR(255) UNIQUE NOT NULL,
display_name VARCHAR(255) NOT NULL,
description TEXT,
primary_key VARCHAR(255) NOT NULL,
status VARCHAR(50) NOT NULL DEFAULT 'ACTIVE',
version BIGINT NOT NULL DEFAULT 1,
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL
);
但这里立刻出现一个问题：
Property 不应该塞进
object_types。
因为 Property 本身也是 metadata。
所以：
CREATE TABLE properties (
id UUID PRIMARY KEY,
object_type_id UUID NOT NULL,
api_name VARCHAR(255) NOT NULL,
display_name VARCHAR(255),
data_type VARCHAR(100) NOT NULL,
nullable BOOLEAN DEFAULT TRUE,
array BOOLEAN DEFAULT FALSE,
searchable BOOLEAN DEFAULT FALSE,
sortable BOOLEAN DEFAULT FALSE,
description TEXT,
UNIQUE(object_type_id, api_name)
);
于是：
ObjectType
│
├── Property
├── Property
└── Property
五、ObjectType ≠ Object
这是 Mini-Palantir 的第一个核心原则。
ObjectType
────────────
Game
Properties:
id
name
platform
country
接着：
Object
────────────
id = game_001
name = "Puzzle Master"
platform = Android
country = US
数据库里可以：
CREATE TABLE ontology_objects (
object_type_id UUID NOT NULL,
object_id VARCHAR(255) NOT NULL,
data JSONB NOT NULL,
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL,
PRIMARY KEY(object_type_id, object_id)
);
这里有意采用：
data JSONB
而不是：
name VARCHAR
country VARCHAR
platform VARCHAR
原因在于目标不是为单一业务写死的数据库，而是构建：
Generic Ontology Engine
而不是给某一个业务写死的数据库。
六、但是 JSONB 还不够
如果只有：
ontology_objects.data
将无法高效支持：
search
filter
sort
aggregate
permission
index
真正的 Object Database 因此必须在存储之外进一步提供：
Object
│
├── Primary Storage
│
├── Property Index
│
├── Search Index
│
└── Permission Index
这和 Palantir 官方描述的 Object Database 职责是吻合的：它不仅存储 indexed object data，还负责 indexing、querying，以及用户编辑的协调。(Palantir)
Mini-Palantir 第一版因此可以落在：
PostgreSQL
│
├── JSONB
├── B-Tree indexes
└── GIN indexes
后续演进再拆为：
Postgres
+
OpenSearch
+
Redis
+
Columnar Engine
七、第二件事：Property
Property 的重要性常被低估。
很多人会认为：
Property = database column
这并不完全成立。
更准确地说：
Property
=
Semantic Field
+
Type
+
Metadata
+
Security
+
Indexing
+
Validation
例如：
Game.eCPM
不仅仅意味着：
FLOAT
还可以有：
displayName = "eCPM"
unit = "USD"
precision = 4
description = "Effective CPM"
searchable = true
aggregation = AVG
visibility = PRIVATE
所以：
Property Definition
和：
Property Value
必须分离。
八、Property 的 Runtime
读取：
GET /ontology/objects/Game/game_001
返回：
{
"type": "Game",
"id": "game_001",
"properties": {
"name": "Puzzle Master",
"platform": "Android",
"ecpm": 4.82
}
}
注意：
API 返回的是 Object，不是数据库 Row。
这就是 Ontology API 与数据库 API 的第一个区别。
九、第三件事：Link
这是 Ontology 开始真正脱离普通 CRUD 的地方。
Palantir把 Link Type 定义为两个 Object Type 之间关系的 schema definition，而 Link 是具体两个 Object 之间关系的实例。(Palantir)
例如：
Game
│
│ monetized_by
↓
AdNetwork
定义：
Game → AdNetwork
不是具体关系。
具体：
game_001 → admob
才是 Link。
十、LinkType Schema
CREATE TABLE link_types (
id UUID PRIMARY KEY,
api_name VARCHAR(255) UNIQUE NOT NULL,
display_name VARCHAR(255),
source_object_type UUID NOT NULL,
target_object_type UUID NOT NULL,
cardinality VARCHAR(50),
directionality VARCHAR(50),
created_at TIMESTAMP NOT NULL,
updated_at TIMESTAMP NOT NULL
);
Link 实例：
CREATE TABLE object_links (
link_type_id UUID NOT NULL,
source_object_type UUID NOT NULL,
source_object_id VARCHAR(255) NOT NULL,
target_object_type UUID NOT NULL,
target_object_id VARCHAR(255) NOT NULL,
properties JSONB,
created_at TIMESTAMP NOT NULL,
PRIMARY KEY (
link_type_id,
source_object_id,
target_object_id
)
);
十一、Link 真正厉害的地方
现在：
Game
│
├── monetized_by → AdMob
│
├── monetized_by → MAX
│
└── monetized_by → Unity Ads
于是获得了：
Graph Traversal
例如：
GET /objects/Game/game_001/links/monetized_by
得到：
AdMob
MAX
Unity Ads
再进一步：
Game
↓
AdNetwork
↓
Country
↓
Revenue
↓
Experiment
于是 Object Set 查询可以开始做真正的：
Ontology Graph Query
十二、第四件事：Interface
这个概念很容易被低估。
Palantir目前把 Interface 定义为描述 Object Type 的 shape 和 capabilities，并提供 polymorphism；一个 Interface 可以被多个 Object Type 实现。(Palantir)
比如：
Interface
MonetizableAsset
定义：
properties:
id
name
status
actions:
activate()
deactivate()
接着：
Game implements MonetizableAsset
Website implements MonetizableAsset
App implements MonetizableAsset
于是：
MonetizableAsset
│
┌─────┼─────┐
↓ ↓ ↓
Game App Website
这就是典型：
Ontology Polymorphism
十三、Interface 数据库
CREATE TABLE interfaces (
id UUID PRIMARY KEY,
api_name VARCHAR(255) UNIQUE NOT NULL,
display_name VARCHAR(255),
description TEXT
);
Interface Property：
CREATE TABLE interface_properties (
interface_id UUID NOT NULL,
property_id UUID NOT NULL,
required BOOLEAN DEFAULT FALSE,
PRIMARY KEY(interface_id, property_id)
);
Implementation：
CREATE TABLE interface_implementations (
interface_id UUID NOT NULL,
object_type_id UUID NOT NULL,
PRIMARY KEY(interface_id, object_type_id)
);
十四、Interface 真正的意义
不是为了代码漂亮。
而是：
Agent
↓
MonetizableAsset
↓
Game
App
Website
Agent 不需要知道：
目标对象到底是 Game 还是 Website。
它只需要知道：
MonetizableAsset
支持：
name
status
activate
deactivate
这就开始出现一个非常重要的概念：
Capability-based Ontology
这一点将直接衔接后续对 Agent 的研究。
十五、第五件事：Function
Function 与普通函数的本质区别是：
它生活在 Ontology 里。
Palantir官方定义 Function 为接受输入参数并返回输出的代码逻辑，而且 Function 可以接受 Object / Object Set 作为输入，也可以被 Action 和应用使用。(Palantir)
例如：
calculateGameHealth(Game)
输入：
Game
读取：
Revenue
Retention
ARPDAU
eCPM
DAU
输出：
HealthScore
十六、Function Metadata
CREATE TABLE functions (
id UUID PRIMARY KEY,
api_name VARCHAR(255) UNIQUE NOT NULL,
runtime VARCHAR(50),
language VARCHAR(50),
input_schema JSONB NOT NULL,
output_schema JSONB NOT NULL,
code_ref TEXT NOT NULL,
timeout_ms INTEGER,
version BIGINT DEFAULT 1,
created_at TIMESTAMP NOT NULL
);
注意：
Function 本身不应该直接存在数据库里。
数据库保存的是：
metadata
+
code reference
+
runtime configuration
真正执行：
Function Runtime
十七、Function Runtime
在 Mini-Palantir 中：
POST /functions/calculateGameHealth
请求：
{
"game": {
"type": "Game",
"id": "game_001"
}
}
Runtime：
Function Gateway
↓
Authorization
↓
Load Function
↓
Resolve Object
↓
Execute
↓
Return Result
也就是说：
Function
↓
Ontology-aware Compute
而不是：
Function
↓
普通 Lambda
十八、第六件事：ObjectSet
这个概念是整个系统的关键之一。
官方定义里：
Object Set 是一组现实世界实体；可以是 static/dynamic，也可以是 temporary/permanent。(Palantir)
所以：
Object
是：
一个现实世界实体。
而：
ObjectSet
是：
一个现实世界实体集合。
十九、ObjectSet 不是数组
错误设计：
{
"objects": [
"game_001",
"game_002",
"game_003"
]
}
这只能叫：
List
真正的 ObjectSet 应该支持：
Game
WHERE
country = "US"
AND
ecpm > 5
AND
status = "ACTIVE"
所以：
ObjectSet
=
Query Definition
+
Execution Context
+
Result
二十、ObjectSet Schema
CREATE TABLE object_sets (
id UUID PRIMARY KEY,
api_name VARCHAR(255),
object_type_id UUID NOT NULL,
set_type VARCHAR(50),
definition JSONB NOT NULL,
owner_id UUID,
expires_at TIMESTAMP,
created_at TIMESTAMP NOT NULL
);
例如：
{
"objectType": "Game",
"filter": {
"and": [
{
"property": "country",
"operator": "=",
"value": "US"
},
{
"property": "ecpm",
"operator": ">",
"value": 5
}
]
}
}
这就是 Dynamic ObjectSet。
二十一、ObjectSet Runtime
ObjectSet
│
▼
Query Planner
│
├── Filter
├── Search
├── Link Traversal
├── Aggregate
└── Permission
│
▼
Object Database
│
▼
Result
所以：
ObjectSet ≠ Array
而是：
Ontology Query Plan / Materialized Resource
这和 Palantir Object Set Service 的职责高度对应：它负责搜索、过滤、聚合和加载 Ontology 对象；动态 Object Set 保存的是生成它的过滤定义，而不是固定对象列表。(Palantir)
二十二、第七件事：Action
这里开始真正进入 Palantir 的“动力学”。
Action 不是：
POST /game/update
这么简单。
官方定义是：
Action Type 是一组可以一次执行的 Object、Property、Link 修改，以及提交时发生的 side effects。(Palantir)
所以：
ActionType
描述：
可以做什么。
而：
ActionExecution
表示：
刚才做了什么。
二十三、Action Schema
CREATE TABLE action_types (
id UUID PRIMARY KEY,
api_name VARCHAR(255) UNIQUE NOT NULL,
display_name VARCHAR(255),
input_schema JSONB NOT NULL,
rules JSONB NOT NULL,
side_effects JSONB,
version BIGINT DEFAULT 1,
created_at TIMESTAMP NOT NULL
);
例如：
ActionType:
IncreaseTrafficAllocation
Input：
{
"game": "game_001",
"network": "admob",
"country": "US",
"percentage": 10
}
二十四、Action 真正的执行过程
这是 Mini-Palantir 最值得实现的一块：
Action Request
│
▼
Action Gateway
│
▼
Authorization
│
▼
Validate Input
│
▼
Resolve Objects
│
▼
Evaluate Rules
│
▼
Begin Transaction
│
┌──────┴──────┐
↓ ↓
Modify Object Modify Link
│ │
└──────┬──────┘
↓
Commit Changes
│
┌──────┴──────┐
↓ ↓
Audit Log Event Bus
│ │
│ ↓
│ Side Effects
│
▼
Result
所以：
Action
=
Command
+
Authorization
+
Validation
+
Transaction
+
Mutation
+
SideEffect
+
Audit
这正是把 Action 视为 Mini-Palantir 核心的原因：
Action 是 Mini-Palantir 的核心。
Palantir 的 Actions 服务本身负责把用户编辑应用到 Object Database，同时提供复杂权限和条件，并可形成历史 Action Log。(Palantir)
二十五、第八件事：Object
回到 Object 本身。
Object 实际上是：
Object
=
ObjectType
+
PrimaryKey
+
Property Values
+
Links
+
Security Context
+
Version
+
Metadata
因此：
Game#001
不仅仅是：
{
"name": "Puzzle Master"
}
而应该是：
{
"type": "Game",
"id": "001",
"properties": {
"name": "Puzzle Master",
"platform": "Android",
"ecpm": 5.27
},
"links": {
"monetizedBy": [
"AdMob",
"MAX"
]
},
"metadata": {
"version": 18,
"updatedAt": "..."
}
}
二十六、把 8 个概念连成一条链路
ONTOLOGY
│
▼
ObjectType
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Property LinkType Interface
│ │ │
│ │ │
▼ ▼ ▼
Object ←────── Link ─────→ Object
│
│
▼
ObjectSet
│
│
▼
Function
│
│
▼
Decision
│
▼
Action
│
▼
Object Mutation
│
▼
External Systems
此时已经可以看到：
Ontology Language 实际上是一个“世界建模 + 计算 + 变化”的语言。
二十七、Mini-Palantir 内部类图（第一版）
这是整个推演中最重要的产物之一。
第一版：
┌──────────────────────────────┐
│ Ontology │
├──────────────────────────────┤
│ id │
│ name │
│ version │
└──────────────┬───────────────┘
│
┌────────┼───────────────┐
│ │ │
▼ ▼ ▼
ObjectType Interface ActionType
│ │ │
│ │ ├──────────────┐
│ │ │ │
▼ ▼ ▼ ▼
Property InterfaceImpl ActionRule SideEffect
│
│
▼
Object
│
┌────┴─────────────┐
│ │
▼ ▼
PropertyValue Link
│
▼
Object
ObjectSet
│
├── ObjectType
├── QueryDefinition
└── QueryResult
Function
│
├── InputSchema
├── OutputSchema
└── Runtime
ActionExecution
│
├── ActionType
├── Actor
├── Inputs
├── Mutations
├── SideEffects
└── Audit
二十八、用真正的 OOP 表达
可以写成：
Ontology
│
├── ObjectType[]
│ │
│ ├── PropertyDefinition[]
│ └── LinkType[]
│
├── Interface[]
│
├── ActionType[]
│
├── Function[]
│
└── SecurityPolicy[]
Runtime：
OntologyRuntime
│
├── ObjectStore
├── ObjectSetService
├── QueryEngine
├── ActionEngine
├── FunctionRuntime
├── LinkResolver
├── PermissionEngine
├── EventBus
└── AuditService
一个重要的架构分界由此显现：
┌───────────────────────┐
│ Ontology Model │
│ │
│ ObjectType │
│ Property │
│ LinkType │
│ Interface │
│ ActionType │
│ Function │
└───────────┬───────────┘
│
▼
┌───────────────────────┐
│ Ontology Runtime │
│ │
│ Query │
│ ObjectSet │
│ Action │
│ Function Execution │
│ Security │
│ Event │
└───────────────────────┘
二十九、Mini-Palantir 第一版 API
第一版 API 全集可以由此定义。
Metadata API
POST /ontology/object-types
GET /ontology/object-types
GET /ontology/object-types/{type}
PUT /ontology/object-types/{type}
Property：
POST /ontology/object-types/{type}/properties
Link：
POST /ontology/link-types
GET /ontology/link-types/{type}
Interface：
POST /ontology/interfaces
POST /ontology/interfaces/{interface}/implementations
Function：
POST /ontology/functions
POST /functions/{function}/execute
Action：
POST /ontology/action-types
POST /actions/{action}
GET /actions/{executionId}
三十、Object API
GET /objects/Game/game_001
查询：
POST /object-sets/query
例如：
{
"objectType": "Game",
"filter": {
"and": [
{
"property": "ecpm",
"operator": ">",
"value": 5
}
]
}
}
Link：
GET /objects/Game/game_001/links/monetizedBy
三十一、接入「现实世界」模型
这是 Mini-Palantir 与普通 ORM 最本质的区别。
例如：
Ad Monetization OS
定义：
Game
AdNetwork
Country
AdPlacement
UserSegment
Experiment
TrafficAllocation
Revenue
关系：
Game
│
├── has → AdPlacement
│
├── monetizedBy → AdNetwork
│
├── targets → Country
│
└── runs → Experiment
Experiment
│
├── tests → TrafficAllocation
│
└── measures → Revenue
三十二、在现实模型中加入 Function
例如：
calculateOptimizationScore(Game)
计算：
score =
0.30 × eCPM
+ 0.20 × ARPDAU
+ 0.15 × FillRate
+ 0.15 × Retention
+ 0.20 × ROI
注：此为教学占位示例，非真实业务公式。
Function 返回：
{
"game": "game_001",
"score": 87.4,
"recommendation": "increase_us_rewarded_traffic"
}
三十三、让 Action 真正落地
IncreaseTrafficAllocation
Action：
Game#001
↓
US
↓
Rewarded
↓
AdMob
↓
+10%
真正执行：
AI Recommendation
↓
Action
↓
Authorization
↓
Validation
↓
Transaction
↓
TrafficAllocation changed
↓
Event
↓
Real Ad System
三十四、最后接入 AI Agent
至此，Mini-Palantir 的威力才开始显现。
Agent：
“找出最近 7 天美国市场 eCPM 下降超过 20%，但 ROI 仍然大于 100% 的游戏。”
Agent 调用：
ObjectSet
得到：
Game A
Game B
Game C
接着：
Function
计算：
OptimizationScore
Agent 决定：
Game B
然后调用：
Action
执行：
IncreaseTrafficAllocation
最终：
AI
↓
ObjectSet
↓
Function
↓
Decision
↓
Action
↓
Ontology Mutation
↓
Event
↓
External Ad System
↓
Revenue
↓
Data
↓
Ontology
这时候，一个 Mini-Palantir 的雏形才真正形成。
三十五、一个关键的「隐藏结构」
最初展开研究的是：
Object
ObjectType
Property
Link
Action
Function
ObjectSet
Interface
研究完成后应升级为：
Ontology
│
┌────────────┴────────────┐
│ │
DECLARATIVE IMPERATIVE
│ │
▼ ▼
ObjectType Function
Property ActionType
LinkType │
Interface ▼
│ Mutation
│ │
▼ ▼
Object ←────────────── Object
│
▼
ObjectSet
可以称之为：
Ontology Language 的“双核结构”
Declarative Core
描述：
世界是什么？
ObjectType
Property
LinkType
Interface
Imperative Core
描述：
世界如何计算、如何变化？
Function
ActionType
而：
ObjectSet
恰好位于两者之间：
它是对现实世界的可计算集合。
三十六、这比 Knowledge Graph 多了什么？
传统 Knowledge Graph：
Entity
↓
Relation
↓
Entity
Mini-Palantir：
Object
↓
Link
↓
Object
↓
ObjectSet
↓
Function
↓
Decision
↓
Action
↓
Object Mutation
↓
External World
由此可以得到一个重要的阶段性判断：
Knowledge Graph 主要解决“世界如何被表示”；Palantir Ontology 进一步解决“世界如何被计算、决策和改变”。
这也是 Palantir把 Ontology称为 operational layer，而不仅仅是 semantic layer 的根本原因。(Palantir)
三十七、Object View：Ontology → UX 的投影层
「Object View」不在上述 8 个核心概念之列，但应从一开始就放进架构图。
因为它不是 Ontology Language 的核心 primitive，更像：
Ontology → User Experience 的投影层。
Palantir官方把 Object View 定义成某个 Object 相关信息和工作流的中心入口，包括关键属性、Linked Objects、指标、分析、Dashboard 和应用。(Palantir)
所以：
Ontology
↓
Object
↓
Object View
↓
Human
也就是：
Semantic Model
↓
Operational Model
↓
Experience Model
这三层以后也应该拆开。
三十八、Mini-Palantir 架构 v0.1 总图
把以上全部推演收敛为一张总架构图：
┌──────────────────────┐
│ AI AGENT │
└──────────┬───────────┘
│
Query / Function
Decision / Action
│
════════════════════════════════════╪════════════════════════════════════
│
ONTOLOGY API LAYER
│
┌─────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
Object API ObjectSet API Action API
│ │ │
══════════════╪═════════════════════╪════════════════════╪══════════════
│ │ │
└─────────────┬───────┴────────────┬───────┘
│ │
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ Ontology Model │ │ Runtime Engine │
│ │ │ │
│ ObjectType │ │ ObjectStore │
│ Property │ │ QueryEngine │
│ LinkType │ │ ObjectSetEngine │
│ Interface │ │ ActionEngine │
│ ActionType │ │ FunctionRuntime │
│ Function │ │ LinkResolver │
└────────┬─────────┘ │ PermissionEngine │
│ │ EventBus │
│ │ AuditService │
│ └────────┬─────────┘
│ │
═══════════════════════════╪══════════════════════╪══════════════════════
│ │
┌──────▼──────────────────────▼──────┐
│ DATA LAYER │
│ │
│ PostgreSQL │
│ JSONB / Index │
│ Search │
│ Event Store │
└──────────────────┬──────────────────┘
│
═══════════════════════════════════════╪════════════════════════════════
│
EXTERNAL BUSINESS WORLD
│
┌───────────────────────┼───────────────────────┐
▼ ▼ ▼
AdMob MAX Game
│ │ │
└───────────────────────┼───────────────────────┘
│
Events
│
▼
Ontology
三十九、下一步：逆向 Ontology Metadata Model
这里反而建议先完成一个关键的理论动作——在写任何代码之前。
这一动作是专门逆向：
Ontology Metadata Model
也就是：
Palantir 到底如何描述“ObjectType / Property / LinkType / ActionType / Function / Interface”这些东西本身？
因为目前只停留在「知道」层面：
Game
├── name
├── country
└── eCPM
但一个真正的 Ontology Engine 必须知道：
Game 是什么？
name 是什么？
country 的类型是什么？
eCPM 能不能搜索？
谁能看 eCPM？
Game 和 AdNetwork 怎么连接？
哪个 Action 能修改 Game？
Action 谁可以执行？
Function 能访问哪些 Object？
因此实际上需要第二层 Ontology：
META-ONTOLOGY
│
▼
ObjectType
│
┌──────────┼──────────┐
▼ ▼ ▼
Property LinkType ActionType
│ │ │
└──────────┼──────────┘
▼
Ontology Runtime
│
▼
REAL WORLD
这是至关重要的一步。
因为一旦把 Meta-Ontology 搞清楚，Mini-Palantir 就不再是“写几个 CRUD API”，而是真正开始成为一个可动态定义 Ontology 的 Ontology Engine。
而这恰恰是 Palantir OMS 的核心职责：它不是保存业务 Object，而是定义“Ontology 中到底存在什么类型、什么关系、什么 Action”等元数据。(Palantir)
下一步直接拆解 OMS（Ontology Metadata Service）。
OMS 的目标是做到非常硬核的一层：
OMS
├── Type Registry
├── Property Registry
├── Link Registry
├── Interface Registry
├── Action Registry
├── Function Registry
├── Schema Versioning
├── Dependency Graph
├── Validation
└── Ontology Compiler
随后设计出：
ontology_meta 数据库完整 Schema + Type System + Schema DSL + REST API + Ontology Compiler。
做到这里，推演才真正开始接近“自己造一个 Palantir Ontology”，而不是停留在概念学习阶段。