企业官网建设流程全解析

本篇在系列中的任务：讲清 Foundry 里的工作成果放在哪里、怎样被找到和治理。至于这些资源怎样共同表达 Material、Order 和 Action，留到下一篇 Ontology。

同一份“可用库存”，团队找出了三个版本

周一 8:40，恒川工业的计划员要处理M-1042缺料。WMS 明细算出可用库存 760 EA，分析师的临时表是 780 EA，Workshop 页面却仍显示 800 EA。

数据工程师说：“正确的 Dataset 在供应链项目里。”

应用开发者说：“我引用的是别人共享给我的那份。”

计划员只想知道三件事：哪一份是权威资源？谁负责？缺料工作台到底依赖了哪一份？

如果答案只能靠问人、翻聊天记录和辨认文件名，那么 Foundry 即使接入了数据，也还没有形成可运营的工作空间。

本篇要回答什么

这一篇回答三个基础问题：

1. Compass、Space、Project、Folder、Resource 与 RID 分别是什么，处在哪一层？

2. 它们与 Ontology、Object、Dataset 有什么关系，哪些绝不能混为一谈？

3. BA 应怎样为恒川缺料处置划定一个可协作、可授权、可追溯的 Project 边界？

一句话定义

Foundry 的资源世界，是由 Compass 组织的一套工作成果体系：Space 划高层范围，Project 划协作与主要权限边界，Folder 负责整理，Resource 表示可管理的工作成果，RID 则让平台和 API 精确指向它。

这套体系回答“工作成果放在哪里、谁可以使用、机器怎样引用”。它不负责定义“现实中哪一条记录是物料MAT-0001042”——那属于 Ontology 的业务对象身份。

把它放回 Palantir 产品架构

先把本篇六个词放回前两篇建立的地图：

Palantir 标准集成架构 ├─ AIP ├─ Foundry │ ├─ Compass：平台文件系统与资源管理入口 │ │ └─ Space：高层 Project 容器，关联共同 Ontology │ │ └─ Project：协作与主要自主权限边界 │ │ └─ Folder：Project 内的组织结构 │ │ └─ Resource：Dataset、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. Compass：Foundry 的“资源文件系统”

在传统电脑里，文件系统帮助你找到文档、代码和图片；在 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：不止 Dataset

Resource 是 Foundry 中可保存、授权、移动、分享和引用的工作成果。常见例子包括：

• ERP 订单同步产生的 Dataset；

• 计算可用库存的 Pipeline 或 Repository；

• 验证缺料规律的 Quiver 分析；

• 计划员使用的 Workshop application；

• Object 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。两者回答完全不同的问题：

如果 BA 把 Dataset 名称拿来当业务对象身份，一旦数据源改名、拆分或合并，Ontology 里的“物料”就会跟着漂移。

Project 不等于业务部门

Project 应围绕共同目的、依赖和大体一致的访问范围设计，而不是机械执行“一部门一个 Project”。

恒川缺料处置同时涉及计划、采购、仓储和供应链经理。如果按部门各建一套 Project、各复制一份物料和库存，应用会再次面对三个版本的“真相”。反过来，把整个供应链所有数据塞进一个万能 Project，也会扩大权限面并让 Owner 失焦。

Reference 不等于 Copy

Project 是安全边界，构建逻辑及其输出通常应放在同一个 Project。需要使用其他 Project 的 Dataset 时，官方建议使用 Reference。

Reference 是对上游资源的受控引用，不是偷偷复制一份数据，也不会替你获得上游权限。它让依赖关系更可读：恒川的缺料项目可以引用 ERP 主数据项目中的权威 Material Dataset，而不是建立一份无人维护的副本。

在产品里，它们做成什么样

站在不同角色面前，这套资源体系呈现为不同操作。

对计划员，入口可能只是一个被置顶的 Workshop 应用；他不需要浏览全部工程资源。

对 BA，Project cover page、说明、关键资源、Owner、References 和活动记录让用例边界可读。他应能沿着 Workshop 追到依赖的 Object Type、Function 和 Dataset，而不是只记住一个页面链接。

对工程师，RID、Project references、资源权限和 lineage 支撑稳定依赖与变更分析。

对治理者，Space、Organization、Project roles、Markings 和资源状态共同决定哪些工作可被发现、访问、编辑和推广。

因此，一个“做成了”的 Project 不是文件已经上传，而是至少具备：可识别的目的、明确 Owner、受控输入、可追溯产出、最小权限、验证材料和使用入口。

恒川工业：把缺料处置放进一个可运营的 Project

下面是恒川首期的建议形态：

Space：hengchuan-operations └─ 共同 Ontology：恒川工业运营本体 └─ Project：supply-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 强制目录模板。它体现了四条设计决定：

1. ERP、WMS、SRM 的权威数据继续由相应团队维护，缺料 Project 用 Reference 明示依赖。

2. 物料身份映射和可用库存计算属于本用例的数据产品，并有清楚 Owner。

3. Function、Workshop 与验证报告和它们的输出放在共同协作边界内，便于变更和验收。

4. 运营用户只获得完成任务所需的入口和权限，不因为进入该 Project 就自动获得所有底层敏感数据。

回到开头三个库存数：

• 800 EA 是 WMS 的现存库存原始事实；

• 冻结 20 EA、预留 20 EA 后，可用库存是 760 EA；

• available-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 Canvas

BA 在创建 Project 或接受项目边界前，可以完成下面这张表。

这张表的价值，是把“建一个项目文件夹”的技术请求升级为可讨论的协作、权限、依赖与责任契约。

回到开头的问题

恒川团队不应通过“谁发的表最新”来决定使用哪个库存数。

在 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 官方固定产品模型。产品能力可能变化，请以官方文档和具体环境为准。