上午 8:15，恒川工业的计划员在 Object Explorer 找到缺料事件SD-260808-01。他沿 Link 看见物料MAT-0001042、受影响订单、库存和候选方案，又打开 Quiver 核对库存趋势。
8:40，没办完。
因为第二天，他还得重新搜索、筛选、排序、打开同一组关系，再把方案编号抄进审批消息。Ontology 里对象、关系、Function、Action 都有了，但“每天怎么工作”还只存在于熟练计划员的脑子里。
这就是本篇要解决的问题：怎样把一个已经能查、能分析、能执行 Action 的 Ontology，交付成运营人员每天用得起来、办得完、出了错接得住的应用？
上一篇讨论 Automate 如何消除等待。自动化把任务送到人面前之后，人仍需要一个明确入口接住任务、理解证据、作出决定并追踪结果。本篇进入第六单元，先讲面向人的交付界面。
一句话定义：运营应用把 Ontology 变成一条可完成的用户任务流
Ontology-aware application（本体感知应用）是在 Foundry 中直接使用 Ontology 的对象、关系、逻辑、Action 和权限，为发现、分析或运营任务提供用户界面的应用。
其中，Object Explorer 让用户自由寻找和调查对象；Workshop 让 Builder 把已经稳定的决策路径固化成角色化应用。它们不是 Ontology 本身，也不是两个前后串联的技术层，而是消费同一 Ontology 的不同应用工具。Palantir：Ontology-aware applications
“本体可以被查询”不等于“运营产品已经交付”。用户还要知道先处理什么、依据什么、执行什么 Action，以及失败后谁接手。
先把五个工具放回产品架构
初学者最容易把 Ontology Manager、Object Explorer、Quiver、Workshop、Contour 当成五个功能相近的页面。其实它们分别面对建设、发现、对象分析、运营应用和表格分析。
这张图有三个判断。
先看建设端：Ontology Manager 是建设和治理工具。建设者在这里创建 Object Type、定义 Link 和 Action、连接数据，并调查数据是否更新到了用户应用。计划员不应在 Ontology Manager 里完成日常缺料处置。Palantir：Ontology Manager
再看使用端：Object Explorer、Quiver 和 Workshop 是平行的消费工具。Object Explorer 保留探索自由，Quiver 深化对象和时间序列分析，Workshop 把固定路径交付为应用。
最后看表格端：Contour 主要站在表格/Dataset 一侧。数据尚未映射 Ontology、只是一次性文件，或需要大规模表格操作时，Contour 可能更合适；但它不是对象运营应用，也不是 Workshop 的下一级。Palantir：Contour overview
同样是“看数据”，五个工具到底怎样选
工具 | 核心对象 | 工作方式 | 恒川工业里的任务 | 主要产出 |
Ontology Manager | Ontology 定义、映射与运行状态 | 建设、维护、调查 | 定义 | 可被应用消费的 Ontology |
Object Explorer | Object / Object Set | 用户自己搜索、过滤、沿 Link 调查 | 找到七日内高风险未处置缺料 | Exploration、Object Set、调查路径 |
Quiver | Ontology Object 与 Time Series | 点击式分析、下钻、参数化 | 比较库存、需求和安全库存趋势 | Analysis、可嵌入 Dashboard |
Workshop | Object、Object Set、Function、Action | Builder 预先配置角色化任务流 | 从 Inbox 完成方案、审批和异常处理 | Workshop Module / 运营应用 |
Contour | 表格/Dataset | 表格分析、转换、聚合 | 检查尚未治理入 Ontology 的临时供应商文件 | Analysis、Dashboard、新 Dataset |
不知道怎样找，先用 Object Explorer；要解释风险，进入 Quiver；要每天按同一路径办完，用 Workshop；数据还只是临时表格，先在 Contour 处理。
工具的选择不是成熟度排行榜。判断标准是：用户面对未知问题还是稳定任务，输入是业务对象还是表格数据，结果只需解释还是必须执行 Action？
Object Explorer：让用户先找到对象和问题
Object Explorer 是面向 Ontology 的搜索和分析工具。用户可从关键词或 Object Type 出发，用 Property Filter 和 Search Around 逐步形成 Object Set，再查看探索视图、结果表格或单个对象的 Object View；也可以比较集合、保存 Exploration、执行允许的批量 Action，或把结果打开到兼容应用。Palantir：Object Explorer overview
它的价值不只是“搜索框好用”，而是把业务语言变成可操作的调查路径：
Supply Disruption → status = Open → severity = High → shortage_date <= 未来 7 天 → Search Around：Material → Search Around：Production Order / Customer Order → 排除已有开放处置任务的对象
恒川计划员由此得到一个 Object Set：七日内、高风险、影响确认任务、尚未处置的缺料事件。SD-260808-01位于其中。他保存的 Exploration 记录搜索参数、过滤和布局；它不是静态导出，因此再次打开时会基于当前对象状态重新求值。
新用例早期，BA 可以观察计划员从哪个对象出发、反复打开哪些 Link、靠哪些 Property 排序、在哪一步需要 Action。探索行为本身就是应用需求证据。
但要守住两个边界。
分享 Exploration 不会自动授予底层 Object 或 Action 权限；每个用户仍按自己的权限看到结果。
全局可发现 Object Type 超过 250 时，关键词搜索会限制在前 250 个类型；需要指定 Object Type 或类型组继续探索。Palantir：Object Explorer getting started
所以，Object Explorer 是“无需 Builder 先做专用页面即可走上来用”的探索应用，却不是无治理的全库搜索。
Object View：让同一个对象跨工具保持一致上下文
当计划员点开SD-260808-01，他看到的不是一行表，而是 Object View：核心 Properties、Linked Objects、相关分析与应用入口围绕同一对象组织。
每个 Object Type 默认都有 Standard Object View；团队也可用 Workshop 构建 Configured Object View。Full View 适合完整调查，Panel View 适合嵌入当前任务上下文。Palantir：Object Views
恒川把 Panel View 控制在决策所需的最小信息：风险、缺料日、物料、工厂、Owner 和当前方案；Full View 再展开受影响订单、Action history 与WR-2048-*写回记录。
Object View 保持对象上下文一致；它回答“对象现在是什么”，Workshop 回答“角色接下来怎么做”。
Quiver 与 Contour：别把两种分析混成一个词
Quiver 对 Ontology 中的 Object 和 Time Series 做点击式分析。Links 已经表达对象关系，用户无需重新解释主外键；分析可以参数化、保存和分享，Dashboard 还可以嵌入 Workshop。Quiver 也能通过 Action 把分析决定写回 Ontology，但是否允许执行仍由 Action 权限和规则决定。Palantir：Quiver overview
恒川用 Quiver 复核MAT-0001042的证据：账面 800 EA，冻结 20 EA、预留 20 EA，当时可用量为 760 EA；再把需求、到货承诺和安全库存放到同一时间轴，解释为什么SD-260808-01进入高风险集合。
Contour 则面向表格。假设供应商临时发来一份两万行承诺清单，团队还没决定它是否值得治理成长期对象，分析人员可先用 Contour 清洗、聚合和检查异常。只有当它需要稳定身份、Link、权限、Action 和持续运营时，才把相应数据产品映射进 Ontology。
实施边界是：不是所有分析都要先造对象，但进入稳定决策和行动的核心信息不能永远留在临时表格里。
Workshop：把反复发生的路径做成运营应用
Workshop 让应用 Builder 为运营用户创建交互式应用。它以 Object layer 为主要构件，从 Object Data Layer 读取数据，使用 Links 组织上下文，Functions 提供业务逻辑，Actions 执行受控写回。Palantir：Workshop overview
在产品里，Builder 创建的是 Workshop Module。Module 不是一张漂亮 Dashboard，而是一组共同工作的构件：
构件 | 负责什么 | 恒川示例 |
Layout | 组织页面、区块和 Overlay | 待办、详情、方案、写回四个区域 |
Widget | 展示信息、接收输入、触发操作 | Object Table、Filter List、Metric、Button Group |
Variable | 保存对象集、当前对象、参数和界面状态 |
|
Event | 响应点击、选择和导航 | 选中一行后设置当前对象并打开详情 |
Function | 计算复杂对象集或业务逻辑 | 计算缺口、候选方案与优先级 |
Action | 提交受权限和规则控制的业务变化 | 接管、提交方案、批准、转人工复核 |
Module interface | 定义嵌入或 URL 初始化时可传递的变量 | 从 Material View 传入当前缺料事件 |
Workshop Widget 通过输入和输出 Variables 连接；Variable Lineage 可以追踪页面依赖。这里的 Module interface 是模块的输入/输出契约，不是第 13 篇讲的 Ontology Interface，二者只是英文同名。Palantir：Workshop widgets、Palantir：Workshop module interface
恒川工业：一条运营任务流怎样真正跑完
恒川没有直接把初版搜索条件抄成页面。BA 跟随计划员完成三轮处置，确认入队条件、上下文、角色、Action 和退出状态，再设计 Module。
步骤一：进入 Inbox，不让用户自己重建范围
v_inbox是一个 Object Set，定义为：High、未解决、七日内、证据新鲜、没有开放处置任务，并且当前用户有权处理。计划员打开应用即可看到SD-260808-01，同时看到它为何入队，而不是从几十个过滤器开始。
第二步：选择对象，让上下文跟着走
Object Table 的行选择 Event 把SD-260808-01写入v_selected_disruption。Panel Object View 显示核心状态，Links 拉出MAT-0001042、客户订单、生产订单、Plant、Warehouse 和 Owner。
嵌入的 Quiver Dashboard 使用同一当前对象，显示库存、需求与安全库存趋势。用户无需复制编号到另一个分析文件。
第三步：形成方案，但不把建议伪装成事实
计划员调整时间窗口，Function 重新计算缺口和候选方案。AP-2048仍是候选 Allocation Proposal，而不是已批准事实。页面明确显示证据时间、规则结果和负责审批的供应链经理。
第四步：通过 Action 改变状态
计划员可提交方案，经理可批准或拒绝。按钮只负责发起 Action；真正的权限、submission criteria、状态编辑和副作用仍定义在 Ontology Action 层。把批准按钮隐藏起来不能构成安全控制。
第五步：追踪 Writeback 与退出条件
批准后，应用展示WR-2048-*的 Pending、Applied、Failed 或需要人工复核的状态。只有写回完成并对账，或缺料事件被 Closed/Cancelled，对象才离开 Inbox。
这样，“看见成功提示”与“ERP/WMS 已形成业务事实”被明确分开。Workshop 交付的是操作路径，不会替团队消除第 21 篇讨论的幂等、补偿和 System of Record 责任。
BA 交付物：恒川工业运营应用蓝图
这张蓝图不是页面线框图，而是业务任务、Ontology 构件、权限、异常和 Outcome 的共同契约。
设计项 | 恒川工业填写样例 | 验收标准 |
业务事件 | 高风险缺料进入待办 | 能解释入队与退出原因 |
主要用户 | 供应计划员；审批人为供应链经理 | 角色与实际职责一致 |
Inbox Object Set | High + unresolved + no open task + fresh evidence | 与 Object Explorer 样本逐项核对 |
当前对象 |
| 所有页面稳定指向同一对象身份 |
决策上下文 | Material、Orders、Plant、Warehouse、Owner | 每条 Link 服务明确判断 |
分析证据 | Quiver 库存、需求、安全库存趋势 | 数值可复算，时间语义可解释 |
方案 |
| 候选与已批准事实清楚分离 |
Actions | 接管、提交、批准/拒绝、转人工复核 | 权限和 criteria 在 Action 层生效 |
Writeback |
| 不以页面反馈替代源系统对账 |
退出条件 | Applied，或 Disruption Closed/Cancelled | 完成条件可机读、可审计 |
异常状态 | empty、loading、stale、unauthorized、conflict、partial failure | 每种状态都有责任人和下一步 |
Outcome | 首响时间、决策周期、人工覆盖率、返工率 | 指标能追到对象与 Action 记录 |
BA 可以用它主持三场对齐：先与运营角色确认任务流，再与 Ontology/Data 团队确认对象和证据，最后与 Security/Integration 团队确认权限、Action 和失败恢复。页面只是这些契约的呈现结果。
产品约束：应用能打开，不代表任务能完成
权限是依赖链，不是 Module 的一个开关
用户能打开 Workshop Module，只说明他满足 Module 的 Organization、Marking 和角色要求。Module 里的 Object、Link、Action 和 Function 各自有权限；官方提供 Check access 面板检查这些依赖。Palantir：Workshop permissions
验收必须用真实角色测试“看见什么、为何看不见、能执行什么”。计划员可建议不可批准；经理可批准；敏感价格仍按属性策略控制。
Event 有顺序，但不会等待所有下游计算完成
Workshop Events 按配置顺序触发，却不会等待前一个 Event 引起的全部下游 Variables 重新计算完成。若“先改时间窗口，再基于新窗口提交 Action”，不应把两步藏进一次点击并假定传播已经完成；应拆成可见步骤，或增加明确的重算和确认。Palantir：Workshop events
Variables 懒加载，隐藏页面不是预计算区
未显示页面、Tab 或 Overlay 中使用的 Variables 会懒加载。Builder 应通过 Variable Lineage 检查依赖，不要假定所有隐藏内容已经计算完毕。Palantir：Workshop variables
运营应用必须设计失败态
空集合、数据陈旧、Function 超时、Action 冲突、无权限、Writeback 部分失败都应有页面反馈、责任人和恢复动作。只画 Happy Path 的 Workshop 是演示，不是生产应用。
什么时候应该从 Object Explorer 升级到 Workshop
可以观察五个信号：
同一角色反复打开同一 Exploration；
总是沿相同 Link 路径补齐上下文；
同一组排序、阈值和证据已经稳定；
决策最终落到明确 Action；
任务需要入队、分派、退出、异常和 Outcome。
五项中多数成立，就值得固化为 Workshop。若问题仍不断变化，先保留 Object Explorer 和 Quiver 的探索自由；若输入主要是一次性表格，Contour 可能更经济。
真正的“升级”不是页面更漂亮，而是把个人经验转成了团队可执行、可授权、可观察的任务契约。
结论：本体只有进入工作，才成为运营产品
Ontology Manager 负责建设和维护业务世界；Object Explorer 让用户找到对象和新问题；Quiver 把对象及时间序列变成可解释证据；Contour处理仍处于表格世界的分析；Workshop 把已经稳定的对象范围、上下文、判断和 Action 固化为运营应用。
恒川工业的交付路径因此不再是“做一个缺料看板”，而是：从SD-260808-01入队开始，围绕MAT-0001042汇集证据，形成AP-2048，经授权 Action 处理，再追踪WR-2048-*直到对账或人工接管。
现在，人已经有了可完成任务的工具面。但下一步会出现一个新问题：如果使用界面的不只是计划员，而是一个需要读取对象、调用逻辑、提出建议甚至使用 Action 的 AI，怎样让它理解同一个业务世界，又不越过人的责任边界？
【声明】恒川工业及其编号、页面、角色、阈值和应用蓝图均为虚构教学设计，不代表 Palantir 官方模板或真实客户实施；具体功能、权限与限制应在目标 enrollment 发布前重核。
