企业官网建设流程全解析

恒川工业的 Supply Planner 打开缺料事件SD-260808-01：订单行HC-SO-260801-10在，供应商SUP-0088在，库存仍显示 760 EA，可asOfTime已超过约定时限。

WMS 明明发出了新记录，Workshop 也没有报错。排查后发现，这条 stream record 的 Primary Key 不合规，被索引过程丢弃了。

Ontology Manager 里早就有Inventory PositionObject Type。为什么“类型已经建好”，用户仍拿不到足够新的 Object？

本篇只解决这个中间层：Object Type 定义怎样借助 datasource mapping、Funnel 与 Object Storage v2，成为可查询、可编辑、可物化的 Object data。缺口、风险和推荐由谁判断，留到第 18 篇。

一句话定义：OSv2 让本体定义成为运行中的对象状态

Object Storage v2（OSv2）是 Foundry Ontology backend 的下一代对象存储与索引架构；Object Data Funnel 把 datasource 数据和 Action edits 编排进专用 object databases，使 Object 成为可查询、可持续更新的运行状态。

官方把 OSv2 称为支撑 Ontology 的 canonical data store，但它不是 Foundry 的平级产品，也不等于整个 Ontology Engine。Engine 还包括元数据、读取、查询、Action、Function 等服务。Ontology architecture

把它放回 Palantir 架构

它的上级是 Ontology backend / Engine；相邻服务有 OMS、Object Set Service、Actions 和 Functions；基础输入是 datasource、Primary Key、mapping 与 edits；下游是 Object Set、应用和 Agent。Materialization 是可选输出，不是 OSv2 的上级。

这里不推测底层数据库品牌、分片或物理存储实现。BA 真正需要理解的是公开的输入、状态形成、失败行为和消费边界。

六个相似词，不要画成一条直线

上一篇解决数据怎样到达；本篇解决数据怎样成为可查询 Object。两步相连，却不是同一层。

Object Type 已经存在，为什么还没有 Object

Inventory Position的定义可以已经保存在 Ontology 中：它有 Primary Key、onHandQuantity、frozenQuantity、reservedQuantity、asOfTime等 Property，也 Link 到 Material 与 Warehouse。

MAT-0001042 × WH-E01这个具体对象还要经过合格 datasource、稳定且唯一的 Primary Key、兼容 Property type、Funnel indexing 和查询准备；应用需要重新读取，用户也要通过相关权限。

因此，BA 验收不能停在“Object Type 已保存”或“源表里有这一行”。还要验证具体 Object 能否在目标身份、权限和新鲜度条件下被查到。

Batch Funnel：一次 source transaction 怎样成为 Object

官方将 Funnel batch pipeline 描述为 OSv2 的内部索引作业链。它不是项目团队在 Pipeline Builder 中手工搭出的业务数据 Pipeline。Funnel batch pipelines

这些中间 Dataset 由 Funnel 管理，不是项目数据产品。建设者可在 Ontology Manager 查看 live pipeline 与 hydration，在 Data Health 监控 batch jobs 和Sync Propagation Delay。

增量、全量与 replacement pipeline

OSv2 默认只索引 datasource transaction 的差异；大量行变化、特定 schema 变化或手工 reindex 时才可能全量处理。Indexing

增加或改动 Property、替换 input datasource 时，Funnel 可后台建立 replacement pipeline；首次成功后再接管 live pipeline。因此，“定义已改”和“用户已看到新 schema/data”之间可能有时间差。

Streaming Funnel：更低延迟，也带来另一类失败

WMS 库存对时效敏感，恒川可把Inventory Position设计为 stream-backed Object Type。官方说明，streaming indexing 可以按秒或分钟把更新送入 Ontology。Funnel streaming pipelines

但 stream 不是“更快的 batch”那么简单：

恒川因此不允许计划员直接编辑 WMS 库存对象。库存仍由 WMS 拥有；处置意见和批准状态放在非 streaming 的Supply Disruption、Allocation Proposal上，通过 Action 修改。

两种失败看上去不同，业务后果同样严重

OSv2 在 indexing 时校验 Primary Key、Property type 和数据限制。OSv2 data restrictions

Geopoint、Geoshape、Array、Time Series Property 和实数类型不能作为 Primary Key。Batch 出错应阻断发布；stream 则要核对输入数、有效对象数、数据年龄和关键键，不能只看 job 仍在运行。

恒川工业：五类对象怎样在屏幕上会合

计划员打开SD-260808-01时，Workshop 查询的是已索引 Object 与 Link，不是临时 Join 五张源表。

这条链有四个时间：源事件、datasource arrival、最近成功 indexing、应用刷新。页面显示 760 EA，不代表四者都满足行动要求。

恒川沿用第 15 篇的教学口径：高影响调拨使用的库存年龄不超过 20 分钟。超时可展示旧值与年龄，但不生成确定建议；超过 500 EA 仍由 Supply Chain Manager 复核。

Source refresh 与 user edits：同一个 Property 谁说了算

OSv2 的 user edit 只通过 Action 产生；提交后立即作用于 index，随后的 Ontology read 应包含该 edit。Funnel 再合并并持久化 changes。

默认Apply user edits：已编辑 Property 不被 source refresh 覆盖，未编辑 Property 继续更新。Apply most recent value比较 datasource UTC Timestamp 与 edit 时间。How user edits are applied

恒川不把 WMS 的availableQuantity和人工的responseStatus放在同一所有权逻辑里：

• availableQuantity是 WMS source-owned，Inventory Position 不接受 user edit；

• responseStatus、assessmentReason是本文候选的 edit-only Property，只由受控 Action 修改；

• 若某 Property 确实允许来源与人工共同更新，BA 才评审 most-recent 策略、Timestamp 可信度与冲突体验。

删除不是普通 edit；对象删除后重建不会继承旧 edits。业务纠错应通过新的 Action 表达。

Materialization：把当前对象态交给下游，不是写回 ERP

若下游 Pipeline 需要读取Supply Disruption的来源事实、人工评估和批准状态，团队可以创建 Materialization。它把 input datasource 与 user edits 合并后的最新 Object state 输出为 Dataset 或受支持的 Restricted View。Materializations

OSv2 开启 Edits 不要求 Materialization。只有下游 Pipeline 或批量下载确实需要当前对象快照时才创建；运营应用直接查 Object，不必绕到物化 Dataset。

Materialization 仍有延迟：自动传播通常需数分钟，周期模式在 source 更新或六小时节奏构建。它只提供最新 snapshot，retention 不可自定义；历史需另建下游 Transform。它也不调用 ERP/WMS API。

把AP-2048.status=Approved物化到 Dataset，只能证明 Ontology 当前态为 Approved。ERP 单据是否创建、WMS 是否出库，仍属于 Writeback、对账与外部 System of Record 的责任。

产品里在哪里配置和排查

建设者在Ontology Manager / Datasources配置 mapping、Edits、conflict strategy 与 batch/stream datasource，在Materializations配置输出；Data Health 和 Builds 用于查 batch Funnel 健康与失败。业务验收则回到 Object Explorer / Workshop，用具体 Object、权限和时间戳验证结果。

OSv1 仍在官方文档中作为 legacy backend 出现。既有项目先确认 Object Type 使用的 backend、迁移和 edits 机制；新设计不要把 OSv1 writeback dataset 的做法直接套到 OSv2 Materialization。

BA 工作台一：Object Type Data Source Card

Object Type Data Source Card是本系列 BA 模板，不是 Palantir 官方固定表单。它用于 Ontology mapping 评审和 UAT 前签核。

这张卡迫使团队同时回答来源、身份、刷新、编辑、权限、失败和消费，而不是只写“WMS 每五分钟同步一次”。

BA 工作台二：索引与物化决策表

BA 先问“多旧的数据允许做什么决定”，再选 batch 或 stream；先问“谁需要合并后的 Dataset”，再决定是否 Materialize。

回到开头：760 EA 为什么看起来对，仍不能行动

Inventory Position定义和 760 EA 公式都没错。问题是 WMS 新 record 未进入 Object 当前态。Object Type definition、source data、indexed state 和 application view 是四件事。

恒川要纠正 Primary Key、监控 invalid record 和数据年龄，并在 SLA 失守时阻断确定建议。responseStatus仍由 Action edit 管理；仅在下游确有需要时建立 Materialization。

OSv2 解决了 Object 怎样成为可查询、可编辑的运行状态。对象已经到位后，下一道问题才有意义：760 EA 怎样计算，替代资格怎样判，风险由 Function 还是 Model 给出，Action 和 Automation 又该负责什么？

本文依据 Palantir 公开文档、本地 Obsidian 阅读笔记和实施研究整理，与 Palantir Technologies 无官方关联。Object Type Data Source Card、20 分钟 freshness SLA 和索引/物化决策表是本系列教学资产，不是官方固定模板或客户绩效主张。恒川工业及编号均为虚构案例。产品能力可能变化，请以目标 enrollment 和官方文档为准。