本篇在系列中的任务讲清 Foundry 里的工作成果放在哪里、怎样被找到和治理。至于这些资源怎样共同表达 Material、Order 和 Action留到下一篇 Ontology。同一份“可用库存”团队找出了三个版本周一 8:40恒川工业的计划员要处理M-1042缺料。WMS 明细算出可用库存 760 EA分析师的临时表是 780 EAWorkshop 页面却仍显示 800 EA。数据工程师说“正确的 Dataset 在供应链项目里。”应用开发者说“我引用的是别人共享给我的那份。”计划员只想知道三件事哪一份是权威资源谁负责缺料工作台到底依赖了哪一份如果答案只能靠问人、翻聊天记录和辨认文件名那么 Foundry 即使接入了数据也还没有形成可运营的工作空间。本篇要回答什么这一篇回答三个基础问题Compass、Space、Project、Folder、Resource 与 RID 分别是什么处在哪一层它们与 Ontology、Object、Dataset 有什么关系哪些绝不能混为一谈BA 应怎样为恒川缺料处置划定一个可协作、可授权、可追溯的 Project 边界一句话定义Foundry 的资源世界是由 Compass 组织的一套工作成果体系Space 划高层范围Project 划协作与主要权限边界Folder 负责整理Resource 表示可管理的工作成果RID 则让平台和 API 精确指向它。这套体系回答“工作成果放在哪里、谁可以使用、机器怎样引用”。它不负责定义“现实中哪一条记录是物料MAT-0001042”——那属于 Ontology 的业务对象身份。把它放回 Palantir 产品架构先把本篇六个词放回前两篇建立的地图Palantir 标准集成架构 ├─ AIP ├─ Foundry │ ├─ Compass平台文件系统与资源管理入口 │ │ └─ Space高层 Project 容器关联共同 Ontology │ │ └─ Project协作与主要自主权限边界 │ │ └─ FolderProject 内的组织结构 │ │ └─ ResourceDataset、Repository、Analysis、Application…… │ │ └─ RID该资源的唯一机器标识 │ └─ Ontology把数字资产连接成业务对象、关系、逻辑和 Action └─ Apollo这里有三个判断尤其重要。首先Compass 不是 Foundry 的上一级。Palantir 官方把它称为平台的 filesystem。用户通常从工作区的 Files 页面进入用它浏览、搜索、分享和组织 Project 与 Resource。第二Space、Project、Folder 是容器层级Resource 是工作成果类型的总称。它们不是和 Foundry 平级的产品。第三Ontology与 Project 不是简单的父子关系。按当前官方文档Space 是多个 Project 的高层容器并关联一个共同 Ontology而 Object Type、Link Type、Action Type 等 Ontology resources 又可以保存进 Project借助 Compass 的项目化权限管理配置资源。Ontology 的运行数据访问还要经过另一套对象与数据安全检查不能只看目录权限。六个词分别管什么1. CompassFoundry 的“资源文件系统”在传统电脑里文件系统帮助你找到文档、代码和图片在 Foundry 中Resource 可能是 Dataset、代码仓库、分析、报告或应用它自己还可能包含文件、版本、依赖和运行状态因此官方使用 Resource而不是把一切都叫 file。Compass 提供统一的资源视图。用户可以在 Files 页面按 Project、Organization、Tag、Resource type 等条件查找资源也可以查看 Project 的 Files、Autosaved、References 和 Trash 等区域。对 BA 而言Compass 的意义不在于“会点文件夹”而在于能回答权威资产在哪里、谁拥有它、它被谁引用、哪一份应进入运营应用。2. Space高层范围也决定共同 Ontology 的边界Space 过去曾称 namespace。当前官方定义是一组 Projects 的高层容器用于具有共同目的、由一组 Organizations 共享的工作并关联一个共同 Ontology。资源显示路径的起始段通常就是 Space例如hengchuan-operations / supply-disruption-pilot / 10-data-products / available-inventory多数组织可能只需要一个 Space跨组织协作则可以设专用 Space并应用一个或多个 Organization 限制。Space 因而不是“为了目录好看再加的一层”但 BA 也不应动辄为每个用例创建新 Space。它涉及 Ontology 范围和组织隔离需要平台治理者参与。3. Project共同工作的容器也是主要安全边界官方把 Project 描述为组织 Foundry 工作的主要方式也是主要安全边界。Project 把一组目标相关的人员、逻辑和产出放在一起成员通常获得 Owner、Editor、Viewer、Discoverer 等角色角色可按环境配置并向子资源继承。“主要安全边界”不等于“唯一安全机制”。Project role 属于自主访问控制Organization、Marking、classification 等强制控制仍可阻止访问。到了 Ontology用户还要满足 Object Type 定义、对象实例、属性值以及 Action 的相应权限。所以“他是这个 Project 的 Editor”不能直接推出“他能看到所有采购价格更能批准所有采购变更”。4. Folder整理资源不替代边界设计Folder 帮助团队在一个 Project 内组织资源例如按 Source References、Data Products、Logic、Applications、Validation 分类。Folder 可以参与角色继承但不能用一串深层文件夹掩盖错误的 Project 边界。如果两个团队本来就不应互相发现或访问大部分资源问题通常不是“再套一层 Folder”而是要重新评估 Project、Organization 或 Marking 的设计。5. Resource不止 DatasetResource 是 Foundry 中可保存、授权、移动、分享和引用的工作成果。常见例子包括ERP 订单同步产生的 Dataset计算可用库存的 Pipeline 或 Repository验证缺料规律的 Quiver 分析计划员使用的 Workshop applicationObject Type、Action Type 等项目化管理的 Ontology resource。“Resource 是类似文件的基本单元”只是导航类比。一个代码仓库或应用拥有自己的内容、版本和运行行为不应被理解成磁盘上的单个静态文件。6. RID给机器用的稳定资源身份每个 Resource 都有 Resource Identifier简称 RID。它是平台跨应用标准化的唯一标识API、依赖和自动化可以用 RID 精确指向资源。显示名称和路径主要帮助人理解RID 帮助机器避免“同名异物”。但 RID 也不是万能业务主键。它标识的是 Foundry Resource而不是供应链现实中的 Material、Customer Order 或 Supplier。最容易混淆的三组概念Resource 不等于 Object假设available-inventory是一个 Dataset Resource其中有一行MAT-0001042。两者回答完全不同的问题项目Dataset ResourceMaterial Object它是什么Foundry 中的一项数据资产Ontology 中一个现实业务对象它的身份Resource RIDObject Type primary keyMAT-0001042它在哪里某个 Project/Folder由 Ontology Engine 服务给应用和逻辑移动后怎样路径可变化仍是同一 Resource具体操作需按平台规则不应因为 Dataset 改名就变成另一个 Material主要消费者Pipeline、分析、Ontology mapping 等人、Function、Action、Agent、应用如果 BA 把 Dataset 名称拿来当业务对象身份一旦数据源改名、拆分或合并Ontology 里的“物料”就会跟着漂移。Project 不等于业务部门Project 应围绕共同目的、依赖和大体一致的访问范围设计而不是机械执行“一部门一个 Project”。恒川缺料处置同时涉及计划、采购、仓储和供应链经理。如果按部门各建一套 Project、各复制一份物料和库存应用会再次面对三个版本的“真相”。反过来把整个供应链所有数据塞进一个万能 Project也会扩大权限面并让 Owner 失焦。Reference 不等于 CopyProject 是安全边界构建逻辑及其输出通常应放在同一个 Project。需要使用其他 Project 的 Dataset 时官方建议使用 Reference。Reference 是对上游资源的受控引用不是偷偷复制一份数据也不会替你获得上游权限。它让依赖关系更可读恒川的缺料项目可以引用 ERP 主数据项目中的权威 Material Dataset而不是建立一份无人维护的副本。在产品里它们做成什么样站在不同角色面前这套资源体系呈现为不同操作。对计划员入口可能只是一个被置顶的 Workshop 应用他不需要浏览全部工程资源。对 BAProject cover page、说明、关键资源、Owner、References 和活动记录让用例边界可读。他应能沿着 Workshop 追到依赖的 Object Type、Function 和 Dataset而不是只记住一个页面链接。对工程师RID、Project references、资源权限和 lineage 支撑稳定依赖与变更分析。对治理者Space、Organization、Project roles、Markings 和资源状态共同决定哪些工作可被发现、访问、编辑和推广。因此一个“做成了”的 Project 不是文件已经上传而是至少具备可识别的目的、明确 Owner、受控输入、可追溯产出、最小权限、验证材料和使用入口。恒川工业把缺料处置放进一个可运营的 Project下面是恒川首期的建议形态Spacehengchuan-operations └─ 共同 Ontology恒川工业运营本体 └─ Projectsupply-disruption-pilot ├─ 00-source-references/ │ ├─ ERP Material 与 Customer Order Reference │ ├─ WMS Inventory Reference │ └─ SRM Supplier Commitment Reference ├─ 10-data-products/ │ ├─ material-identity-map Dataset │ └─ available-inventory Dataset ├─ 20-logic/ │ └─ shortage-assessment Repository ├─ 30-applications/ │ └─ supply-disruption-workbench Workshop └─ 90-validation/ ├─ action-test-report └─ writeback-reconciliation-report这是一项实施建议不是 Palantir 强制目录模板。它体现了四条设计决定ERP、WMS、SRM 的权威数据继续由相应团队维护缺料 Project 用 Reference 明示依赖。物料身份映射和可用库存计算属于本用例的数据产品并有清楚 Owner。Function、Workshop 与验证报告和它们的输出放在共同协作边界内便于变更和验收。运营用户只获得完成任务所需的入口和权限不因为进入该 Project 就自动获得所有底层敏感数据。回到开头三个库存数800 EA 是 WMS 的现存库存原始事实冻结 20 EA、预留 20 EA 后可用库存是 760 EAavailable-inventory是进入 Ontology 映射的权威用例资源Workshop 显示 800 EA说明它可能仍指向旧 Resource、旧 transaction或其上游未刷新。BA 不应直接拍板“删掉另外两份”。他先记录每个数字的 Resource RID、路径、Owner、更新时间、上游依赖和消费方再决定哪一份被降级、修复或停止使用。约束、失败和不适用场景失败一万能 Project所有人、所有源数据、所有应用都进一个 Project。短期查找方便长期会出现权限扩大、Owner 不清、变更相互影响和资源不可发现。失败二部门各建一套权威资源采购、仓储、计划分别复制 Material 和库存。Project 看似整齐业务身份和计算口径却发生分裂。失败三只记名称和路径不记 RID自动化用显示名称寻找资源。资源改名或同名出现后依赖指错。机器集成应使用合适的 RID/API人类文档同时保留可读路径。失败四把 Project role 当全部数据权限用户能打开 Workshop 或查看 Object Type 定义不代表能看到所有对象和属性更不代表能 Apply Action。资源权限、对象数据安全和 Action 权限必须分别验收。失败五用 Folder 修补错误安全边界本应隔离的供应商协作和恒川内部采购信息只靠两个 Folder 区分。若用户访问范围根本不同应重新评估 Project、Space/Organization 与强制控制。失败六把目录规范当作业务设计文件夹排得很漂亮却没有统一MAT-0001042也没有 Action、权限和结果指标。Compass 解决资源秩序不会自动生成业务语义和运营闭环。BA 工作台Project Boundary CanvasBA 在创建 Project 或接受项目边界前可以完成下面这张表。决策项要回答的问题恒川填写样例共同目的这组资源共同服务哪一个运营结果在排产冻结前完成关键物料缺料处置决策范围哪些选择在本 Project 内被支持调拨、催交、替代料、改序不含供应链全部规划协作人群哪些角色需要大体一致的资源可见范围计划、采购、仓储、供应链经理和交付团队强制边界哪些人/数据必须严格隔离外部供应商不进入内部 Project采购价受强制控制上游 Reference哪些权威资产只引用、不复制ERP Material/Order、WMS Inventory、SRM Commitment本项目产出哪些资源由本团队负责身份映射、可用库存、shortage Function、Workshop、测试报告Resource Owner谁对每项资源的质量和变更负责Dataset数据工程Function逻辑 OwnerApp产品 Owner业务身份哪个字段标识现实对象Material primary keyMAT-0001042资源身份怎样让 API 精确指向资产记录每个 Dataset/App 的 RID不用文件名代替完成证据怎样证明 Project 已可运营760 EA 口径一致计划员能处置未授权用户看不到敏感字段这张表的价值是把“建一个项目文件夹”的技术请求升级为可讨论的协作、权限、依赖与责任契约。回到开头的问题恒川团队不应通过“谁发的表最新”来决定使用哪个库存数。在 Foundry 中他们应该能从 Workshop 找到其依赖的 Ontology 和 Resource凭 RID 精确定位资产沿 Reference 和 lineage 找到 WMS 输入看到 Owner 和更新时间并按 Project 与数据权限判断谁能修复、谁能使用。所以Compass、Space、Project、Folder、Resource 与 RID 不是一组文件管理名词。它们共同把分散工作成果变成可找到、可授权、可引用、可负责的平台资产。但这还只回答了“资产放在哪里”。即使 Dataset、Function 和 Workshop 都有了正确位置它们仍可能各说各话一边叫物料号一边叫零件编码一边只有库存行一边需要理解客户订单为什么受影响。资源有了位置业务怎样有共同语言当 Foundry 已经能管理 Dataset、逻辑和应用什么机制把它们连接成 Material、Customer Order、Supply Disruption 和可执行 Action下一篇进入 Palantir 架构的核心Ontology 为什么既描述世界也能改变世界。本文依据 Palantir 公开资料与实施研究整理与 Palantir Technologies 无官方关联。恒川工业及其编号和数据均为虚构教学案例实施性模板不是 Palantir 官方固定产品模型。产品能力可能变化请以官方文档和具体环境为准。