恒川工业的团队已经把缺料项目整理得井井有条WMS 库存、ERP 订单、MES 工单、计算逻辑和 Workshop 应用都有明确的 Project、Owner 与 RID。可计划员打开缺料事件SD-260808-01时仍然无法直接回答M-1042影响哪张客户订单谁能批准超过 500 EA 的调拨批准后又怎样进入执行。资源有了位置不等于业务有了共同语言数据能够被找到也不等于决定能够被执行。把 Supplier、Material、Plant 和 Customer Order 连成一张图我们是不是已经拥有了 Ontology还没有。本篇要说清什么本篇只回答 Ontology 的本质它在 Palantir 架构中究竟是什么、在哪里Object、Property、Link、Function、Action 与 Security 怎样共同表达并改变业务世界它为什么不是数据库模型、主数据、知识图谱或一张“数字孪生大图”。一句话定义PalantirOntology是位于 Palantir 架构核心的运营系统与组织运营层它把企业数字资产连接成现实业务对象和关系并把判断逻辑、受控 Action 与安全规则放进同一个可运行的决策世界。上述定义包含两个不可拆开的部分Ontology 既描述“世界现在是什么样”也定义“谁能在什么条件下把它变成什么样”。先把 Ontology 放回 Palantir 架构前几篇已经区分了产品平台与 Foundry 资源。这里再做一次最小定位Ontology 不是与 Foundry、AIP、Apollo 并列的平台也不是 Compass 中某个普通文件的名字。Palantir Architecture Center 把 Ontology 称为其架构核心的系统负责表达企业中相互连接的决定而不只是数据。Foundry 提供建设和使用 Ontology 所需的数据、逻辑、分析、应用与工作流能力AIP 中的人机协作也可以通过受权的 Ontology 对象、逻辑和操作进入业务。PalantirThe Ontology systemPalantir 标准架构 ├─ Foundry数据运营、逻辑、本体建设、分析与工作流 ├─ AIP生成式 AI 与 Agent 工作流 └─ Apollo持续交付与运行管理 其中的核心运营系统Ontology ├─ 向下连接Dataset、Virtual Table、Model以及 ERP/WMS/MES 等系统事实 ├─ 内部表达Object、Property、Link、Function、Action、Automation、Security └─ 向上供给Object Explorer、Workshop、Quiver、AIP Agent、OSDK 应用等这张图表达的是产品位置不是部署拓扑。Ontology 的上一级语境是 Palantir 架构与 Foundry 平台能力它的基础是数据、逻辑和外部业务系统下游是人、应用、Automation 与受控 Agent。MMDP 等开放架构能力与它相邻但不同类不能拿来充当“同层组件”。在产品中建设者通常通过 Ontology Manager 配置 Object Type、Property、Link Type、Action Type 等定义并把它们连接到数据源与逻辑用户则在 Object Explorer、Workshop 等基于 Ontology 的应用中搜索对象、沿关系导航、比较方案并提交 Action。PalantirOntology overview因此Ontology 既不是某一张关系图也不是某一个应用页面。定义、运行状态、操作与消费界面共同让它成为系统。不是一种“更漂亮的数据模型”Ontology 与传统技术概念有相似处但差别决定了项目会从哪里开始、最终能交付什么。容易混淆的概念主要回答什么与 Palantir Ontology 的关系缺少什么时不能互换数据库 Schema / ER 模型数据怎样存、字段怎样关联可成为数据基础Object/Property/Link 也能与表行列类比业务身份、可复用操作、动态权限与决策记录语义层指标和业务含义怎样统一Ontology 包含语义但官方明确说它不只是薄语义层可写运行时、Action、事务、外部系统编排与完整安全主数据管理哪个编码和定义是权威的为 Material、Supplier 等提供身份和治理基础缺料事件、方案判断、Action 与运营状态变化知识图谱实体及其关系怎样连接、推理Object 与 Link 可以形成图状业务世界不能因为“有图”就默认具备 Palantir 的 Action、运行时和权限体系数字孪生怎样数字化表达现实系统及其变化官方说 Ontology 在许多场景中充当组织数字孪生不是要求首期完整复制企业也不是 Ontology 的唯一等式类比能帮助入门却不能替代边界判断。比如官方 Core concepts 用 Dataset、Row、Column、Join 类比 Object Type、Object、Property、Link Type但它称这是 analogous——相似而非相等。PalantirOntology core conceptsObject 还要有业务身份、可被关系引用、可被权限约束并参与 Action。Link 有业务方向和语义。Action 不是数据库UPDATE的别名而是面向业务目标的一次受控操作。用三个观察面理解 Ontology旧稿中最值得保留的是把复杂概念整理成三个观察面Semantic这个业务世界里有什么 Kinetic这个世界允许怎样变化 Governance谁可以在什么条件下看见和改变它这是本系列的教学组织不是 Palantir 官方固定的“三层产品架构”。官方使用 semantic elements、kinetic elements 与 dynamic security 等表述并进一步用 Data、Logic、Action、Security 解释决定如何被建模。Semantic让事实成为业务语言语义面回答的是我们正在谈论什么它们怎样相关Object Type 与 Object。Material、Customer Order Line、Production Order、Supplier、Warehouse和Supply Disruption都可以是 Object TypeMAT-0001042、HC-SO-260801-10和SD-260808-01是具体 Object。Object 不只是表里的一行。它需要稳定身份、业务含义和生命周期。例如M-1042是 ERP 来源编码跨系统归并后的 Material 身份是MAT-0001042WMS 的MAT1042-SH与供应商门户的P-8821不能只因名称相似就自动合并。Property。Property 是对象有类型的业务特征。例如 Material 有基本计量单位库存上下文中有现存、冻结、预留和可用数量Supply Disruption 有发生时间、风险状态和责任人。Property 设计不等于把源表字段全部搬过来。BA 要问这个属性支持哪个筛选、判断或 Action它的口径、来源、更新时间和缺失处理是什么恒川的available_quantity 760 EA是由800 - 20 - 20得出的业务值不能与“现存库存 800 EA”混写。Link Type 与 Link。Link 表达业务关系的类型和实例客户订单行requiresMaterial生产订单fulfills客户订单行供应商通过采购与供料关系支持 Material仓库持有相应库存位置。Link 也不能只写“关联”。它应说明方向、业务名称、基数和所有权。否则同一个“受影响订单”会被不同应用沿不同 Join 路径算出不同答案。Semantic 让数据变成可理解、可导航的业务世界但只做到这里仍然是一套静态描述。Kinetic把业务动词放进模型缺料处置真正需要的是动词确认事件、准备方案、发起催交、提交调拨、批准替代、调整排产。Function负责可复用的判断和计算。它可以读取 Object、Object Set、Property 和 Link计算缺口、验证替代约束或比较候选方案。Function 输出建议或判断不天然拥有业务批准权。Action Type定义一组可以同时作用于 Object、Property value 和 Link 的变更也可以包含提交时的 side effect。用户真正提交一次操作时发生的是 Action submission。PalantirAction types overview“批准调拨方案”因而不是一个普通按钮。它至少要明确目标对象、参数、提交条件、权限、状态变化、外部效果和审计证据。Action 让业务动词成为可复用、可校验的操作契约而不是留在界面代码或会议纪要中。Semantic 与 Kinetic 要合成完整业务语句供应链经理在排产冻结前基于M-1042的可用库存、受影响订单和调拨约束批准方案AP-2048并让处置进入受控执行状态。没有名词动作找不到目标没有动作名词只能被观看。Governance安全不是建模后的附件在同一条缺料链上计划员需要查看订单和库存采购员需要处理供应商承诺财务可以看到成本仓储协调员可以执行仓储操作。但“能看订单”不等于“能改订单”“能运行 Function”不等于“能批准 Action”。Security 横切语义和动作谁能查看某类 Object 及其敏感 Property谁能沿某条 Link 看到下游对象谁能运行 Function 或模型谁能提交、批准或执行 Action操作怎样留痕失败时谁负责人工接管。资源定义权限与对象数据权限也不能混为一谈。建设者能看见某个 Object Type 的定义不表示他能看到该类型的全部 Object 实例某角色能使用一个应用也不表示能调用其中所有 Action。权限模型的具体层级和产品配置将在第 7 篇展开。恒川工业从一张库存表到一个可运行世界把M-1042缺料案例放进 Ontology可以看到六个环节依次接上。1. 数据成为有身份的对象ERP、WMS、MES 与供应商门户提供订单、库存、工单和承诺数据。经过身份规则系统把多套物料编码归到MAT-0001042并建立Supply Disruption SD-260808-01、客户订单行HC-SO-260801-10和生产订单HC-PO-260815等对象。2. 关系形成影响路径缺料事件影响 Material生产订单消耗 Material生产订单履行客户订单采购订单行连接供应商与 Material仓库库存为候选调拨提供来源。计划员不再只看“缺 多少”而能沿关系回答“缺料会在什么时间影响哪张客户订单”。3. Logic 形成可解释判断Function 计算可用库存 760 EA验证调拨量、运输时效和替代资格。调拨超过 500 EA 必须经理复核这是恒川教学场景中的业务规则不是 Palantir 内置阈值。4. Action 把方案交给责任人计划员比较调拨、催交、替代料和生产改序后提交AP-2048。供应链经理看到同一组对象、证据与候选方案再决定批准或拒绝。批准只代表业务决定通过不等于 ERP、WMS、MES 已经全部执行。Ontology 要保留批准状态、执行状态与失败信息的区别具体写回机制属于后续专题。5. Security 约束每一次交互Supply Planner 可以比较方案和提交建议但不能单独批准高影响调拨Buyer 可以更新采购承诺不能改仓储执行状态Warehouse Coordinator 可以处理仓储 ActionAgent 即使能解释方案也不能绕过调用者和工具权限。6. 结果回到下一次决策实际调拨量、执行时长、订单影响和失败原因成为新的运营事实。团队才能比较方案预期与真实结果审计当时基于什么证据作了什么决定并改进后续处置。这就是 Ontology“既描述世界也改变世界”的含义世界不是一张静态大图而是一组持续变化、可查询、可操作、受治理的业务状态。在底层它为什么真能运行讲到这里会自然出现一个技术疑问这些定义为什么不只是文档对象怎样被查询Action 怎样变成事务应用又怎样获得一致接口官方把 Ontology 这一多模态系统的底层组件概念性地归为三部分Language表达 Object、Property、Link、Action、Automation、Logic 及其系统交互Engine让这些定义成为可扩展的读写运行时承担查询、订阅、物化、事务和数据变化同步Toolchain让开发者和产品团队把 Language 与 Engine 交付成应用、SDK 与可治理的生产能力。这不是另一套与 Data、Logic、Action、Security 平行的业务分类。前者回答“Ontology 怎样成为系统”后者回答“企业决定由什么组成”两组视角彼此交叉。PalantirThe Ontology system本篇只作定位。下一篇会把这三部分逐层拆开。约束四种“看起来像完成了”的失败只有对象没有 Action。团队建了精美关系图但计划员仍要去 ERP、WMS 和邮件里操作。它可以支持理解却没有形成运营闭环。有 Action没有明确状态所有权。应用显示ApprovedERP 仍无单据WMS 也没有执行。Ontology 不会自动替企业决定哪个系统是每类事实的 System of Record。把所有字段都映射进来。Object Type 变成源表镜像大量 Property 没有业务口径、Owner 和使用场景。模型看似完整任何变更都牵一发动全身。把权限放到最后。关系一旦连通敏感信息可能沿 Link 暴露Action 如果没有角色、校验和审计边界就不应进入生产。成熟度不由 Object Type 数量决定而由一项真实决定能否在正确的对象、逻辑、权限和操作上稳定运行来决定。BA 工作台业务语义—行动契约卡这张卡在需求澄清和 Ontology 设计评审阶段使用。它把旧稿的“业务语句检验法”固化成一份跨业务、数据和工程团队可以共同签认的交付物。一张卡的字段区块必填字段恒川M-1042填写样例验收问题业务语句角色、时刻、判断、Action、Outcome供应链经理在排产冻结前批准AP-2048降低HC-SO-260801延期影响一句话能否说清谁基于什么作出什么改变Object类型、实例、业务身份、OwnerMaterialMAT-0001042事件SD-260808-01订单行HC-SO-260801-10对象是实体、事件还是临时计算结果Property名称、口径、来源、刷新、缺失处理available_quantity760 EAWMS扣除冻结与预留760 与 800 的口径差异能否复现Link两端、方向、业务语义、基数Production OrderconsumesMaterial订单行requiresMaterial关系能否支撑“受影响订单”查询Logic输入、规则/Function、输出、Owner库存计算、调拨阈值、替代资格 → 候选方案建议是否可解释过期输入怎样处理Action目标、参数、criteria、效果、失败批准AP-2048数量、来源仓、理由进入执行状态Action 是否被误写成按钮或任意字段更新Security查看、运行、提交、批准、执行Planner 提交Manager 复核Warehouse 执行“能看”与“能做”是否分开状态与账本当前状态、目标状态、System of Record、审计Pending Approval → Approved外部执行另行跟踪批准与执行失败能否区分Outcome基线、目标、指标 Owner、观察周期冻结前形成可执行方案跟踪处置周期与延期影响结果能否用业务指标而非对象数量验收使用顺序先让业务人员写出“谁在何时作什么决定”不要先贴源表字段再逐项识别 Object、Property、Link 与 Logic用 Action 和 Security 检查它能否进入真实运营最后才确认数据来源、System of Record、写回和验收样本。任何一格写不实都是设计风险。比如available_quantity没有口径Function 就无法验收Action 没有失败状态批准就会被误当成执行成功Security 只写“供应链团队可用”角色边界就无法测试。回到开头Ontology 到底是什么恒川并不缺少资源目录也不缺一张 Material—Order 关系图。它缺少的是一个可运行的业务世界对象有稳定身份关系能够传播影响Logic 能解释候选方案Action 能在权限约束下改变状态执行结果能够被追踪并进入下一次判断。所以Ontology 不是把现实世界“画”进系统而是把企业的名词、关系、判断、动词和责任边界组织成共同运营模型。它描述世界是为了让人和受控系统能理解当前情形它允许改变世界是因为改变经过校验、授权、执行和审计。追问定义为什么能够成为运行中的系统但新的问题也出现了在 Ontology Manager 里定义一个 Object Type为什么用户能实时查询它一次 Action 为什么能够安全改变状态同一套对象又怎样被 Workshop、SDK 和 Agent 使用本文依据 Palantir 公开资料与实施研究整理与 Palantir Technologies 无官方关联。恒川工业及其编号和数据均为虚构教学案例“Semantic / Kinetic / Governance”和“业务语义—行动契约卡”不是 Palantir 官方固定架构或模板。产品能力可能变化请以官方文档和具体环境为准。