企业官网建设流程全解析

恒川工业的缺料应用已经上线。采购员从外部门户读取SD-260808-01，门户通过 OSDK 依赖risk_level和催交 Action。Buyer 此时提出：“给采购订单行增加供应商承诺可信度。”

同一天，计划团队也在修改risk_level的分级口径。

如果两边都直接保存到正在运行的 Ontology，后保存的人可能覆盖先保存的人；即使没有覆盖，Workshop、Action 和外部门户也可能分别理解三种“高风险”。

本篇回答：怎样隔离修改、看见依赖、处理冲突、完成评审，再把获准变化带回main？

一句话定义：把跨资源修改变成可评审的变更

Global Branching 是 Foundry developer toolchain 中的跨资源变更管理能力：建设者在隔离 Branch 中修改与测试受支持的Ontology、Pipeline、应用和逻辑，再通过 Proposal、Checks、Review、Rebase 和 Merge，把获准变化带回main。

它不是 Ontology 的 Property，也不是与 Foundry、AIP 平级的产品。它借鉴软件版本控制方法，把 branch workflow 扩展到 Palantir 的端到端资源。Palantir：Global Branching core concepts

它解决的是系统怎样变化。调拨 520 EA、催交还是改序哪个业务方案更好，仍属于第 20 篇的 Scenario。

架构位置：一套工程机制，管理多类资源

它的上一级是 Foundry developer toolchain；基础是 Space、Organization、Project/Resource 权限、各资源建设应用、Lineage 与 Build；使用者包括 Ontology builder、数据工程师、应用 builder、Reviewer 和平台管理员。

Resource protection 决定哪些资源不能直接改main；Observability 负责观察合并后的运行；Foundry DevOps 负责打包、发布和升级。它们相邻，但不互相替代。

六个词，连成一条生产变更链

Global Proposal 包含 Ontology changes 时，还会自动形成Ontologyproposal，跟踪 Ontology 专属变化和评审。它类似 Pull Request，但不是恒川的业务方案AP-2048，也不批准采购动作。Palantir：Branching the Ontology

在产品里，看见“一个中心、两类入口”

Global Branching application集中列出 Branches 和 Proposals，可创建、归档、管理角色，并进入 Checks、Review 和 Merge 页面。

各受支持应用还有branchselector和 branch taskbar。Builder 在 Ontology Manager 修改 Property，在 Workshop 改页面，在 Pipeline Builder 调整逻辑；taskbar 标明当前 Branch，并连接到 Proposal 与 Rebase。Palantir：Global Branching application

统一的是变更流程，不是资源格式。Ontology、Workshop、Pipeline 仍由各自应用编辑，Global Branching 把它们放进同一条隔离、评审和合并链。

Global Branching、Scenario、Git 不试同一种东西

Global Branching 借鉴 Git，却不是“Foundry 里的 Git”。它跨多类 Palantir resources，并叠加 Space/Organization、资源权限、审批政策、Build 和数据保留行为。

它也不是无差别支持。当前 Integrations 页面列出 Workshop、AIP Logic、Ontology、Actions、Materializations、Object Views、Code Repositories、Pipeline Builder、Automate 与 Lineage 等集成，同时明确仍有资源未支持。Palantir：Integrations

截至核验日，TypeScript v2 和 Python Functions 不能直接在 Branch 修改；引用特定版本测试时，Function code 只能使用mainschema。OSDK 也不能 branch。支持面必须按目标 enrollment 逐项确认。

恒川先做：不要只分支一个 Property

“增加承诺可信度”若被翻译成“加一列”，变更就被做小了。恒川建立 Branchgb/supplier-commitment-confidence，把影响链写清：

1. 为Purchase Order Line增加supplier_commitment_confidence（0—100）与confidence_evidence_time；

2. 更新Supply Disruption.risk_level的说明，声明可信度是风险证据之一；

3. Workshop 显示评分、证据时间与来源状态；

4. 更新Confirm Expediting PlanAction criteria：可信度低于 60 时必须填写人工理由；

5. 检查第 26 篇的Hengchuan Supplier Recovery Portal。它通过 OSDK 读取订单行，并依赖既有risk_level值与 Action 参数；

6. 明确非目标：不重写风险模型，不改变 ERP 主数据，不从 Branch 调用生产 SRM/ERP。

字段、0—100 与 60 分阈值都是恒川教学设定，不是 Palantir 预置规则。BA 的价值在于把 Property 展开为语义、数据、展示、Action、权限和外部契约问题。

第二步：测试 Branch，但不要误触真实世界

团队用HC-PO-88210-20测试：供应商SUP-0088两次延期，可信度暂设 42，证据时间为 2026-08-09 09:30。页面应显示“低可信度”，采购员无理由提交催交方案时，Action 应被拒绝。

相关 Object Types 需要在 Branch 上可用并完成所需索引。Action 测试 edits 只留在 Branch，不会自动进入main。

但 Branch 不是外部世界的撤销键。官方当前行为是：Action Webhook 和通知默认不执行；有外部调用的 Function-backed Action 默认失败。若建设者显式打开，调用会像main一样指向配置的外部环境，可能击中生产系统。Palantir：Branching Action Types

恒川只验证 Ontology edits、criteria、权限和页面反馈，不开启生产 SRM/ERP 外部调用。

第三步：Rebase 暴露真正的定义冲突

采购测试期间，计划团队的 Proposal 先合入main。他们也修改了Supply Disruption.risk_level：把客户订单优先级加入分级口径，并更新同一 Property 的说明。

采购 Branch 因落后于main，Rebase check 失败。Rebase 会吸收main最新变化，再重新应用采购 Changes。不同资源或不同 Property 的变化可自动处理；两边都改了同一risk_level，属于 true conflict，必须人工解决。Palantir：Core concepts

此时不能用“保留我的版本”代替业务判断。BA 召集 Supply Planner、Buyer、Ontology owner 和 Portal owner，形成统一口径：

• 保留High / Medium / Low值集合，避免外部门户立即失配；

• risk_level仍由缺口与订单优先级决定；可信度先作为解释证据和催交 Action 条件；

• 新 Property 初期允许空值，但必须同时展示证据时间；

• 可信度若要进入风险算法，另开一次包含规则验收和迁移计划的 Proposal。

冲突解决的标志不是哪一方“赢”，而是同一业务概念重新有了唯一 Owner、定义和迁移顺序。

权限：Branch 管理权不等于资源修改权

恒川让 Ontology、采购、计划、Portal、Security 与 Workshop owners 分别评审。官方当前说明，创建 Proposal 需要 BranchOwner或 SpaceAdministrator；但 Branch Owner 不会自动取得资源编辑权，修改仍需 Project/Resource 权限。Palantir：Branch security

Protected resource 必须通过 Branch 和 Approval。Project approval policy 可规定 eligible reviewers、审批数，以及 contributor 能否批准自己的变化。Ontology resource 要启用 protection，需先采用 project permissions。Palantir：Resource protection

Merge 权限也容易误写。当前文档说明：能查看 Proposal 的用户，在资源级 approvals/checks 已满足且没有Do not merge时，可以触发 Merge。控制点是“谁能写、谁能批、哪些检查必须过”，不是最后一个按钮。

承接第 26 篇：Branch 不能替你证明 OSDK 兼容

OSDK 当前不可 branch，外部门户的 SDK 仍基于mainschema。Global Branching 可以隔离 Ontology 与受支持的 Workshop Changes，却不能生成“采购 Branch 专用 OSDK”来证明门户兼容。

恒川采用两步发布：

1. 先以 additive change 合入新 Property，保留旧risk_level值与 Action 参数；旧门户仍能工作；

2. Merge 后生成新版 OSDK，在应用发布链中升级门户并运行 contract test，再展示新字段。

如果直接重命名risk_level、改变类型或删除 Action 参数，Global Branching checks 未必发现外部调用者。Proposal 必须把 OSDK 应用、MCP tools、Automate 和报表列为显式依赖。

三种“删除”和一种 Merge 风险

1. 从 Branch 移除资源

这会把资源恢复成main版本，不会删除main。但其他 branched resources 可能依赖它，移除前要检查 Lineage。

2. 在 Branch 创建或删除资源

官方当前区分：普通 Foundry resource 在 Branch 的修改不影响main，但普通资源的创建或删除会影响main；Ontology entities 是例外，其创建、修改、删除可以隔离。不同应用还可能有专属行为，不能把 Ontology 语义泛化到全部资源。

3. Branch 进入 Inactive 或 Archived

默认无活动 35 天后转为 Inactive，默认再过 7 天触发 Branch data deletion；周期可由 Space retention policy 配置。Inactive/Archived 可能导致 Ontology de-index、Build 失败和数据/逻辑删除，恢复后要重新索引或构建。Archived 可恢复；Merged 是终态。Metadata 保留不等于数据和 Job specs 仍在。

4. Merge 不是“一键回滚”

Merge 可选择构建全部受影响资源、仅修改资源或不构建。它也可能部分失败；当前不能直接 revert 已成功部分，只能修复后继续 Merge，或提交补偿性变化。

恒川因此先合入兼容 Property 与数据映射，再启用强制 Action criteria，最后升级门户。这个顺序是实施建议，不是平台自动生成的回退方案。

BA 交付物一：Ontology Change Proposal

这不是 Palantir 官方固定表单，而是创建 Proposal 前的业务变更契约。

BA 交付物二：变更影响表

BA 不必亲自解决每个技术问题，但要确保每项影响都有 Owner、验证方法和阻断判断。没有责任人的依赖，就没有被管理。

结论：安全变更是一条责任链

Global Branching 把 Branch、Change、Proposal、Checks、Review、Rebase、Conflict 和 Merge 连成生产变更责任链。对 BA 来说，重点不是会点 “Create branch”，而是把 Property 需求展开成语义、数据、Action、权限、外部应用、兼容、保留和恢复问题。

恒川现在可以把供应商承诺可信度带进main。但 Proposal 合并只证明变化完成了治理流程。如果采购页面已有新值，Action 却一直处理中；或者 Pipeline 成功，ERP 却没有单据，团队怎样判断失败在哪一层、由谁接管？

【声明】恒川工业、Branch、评分、阈值、冲突方案和两张 BA 表均为虚构教学案例或本系列实施模板，不代表 Palantir 官方固定对象、规则、表单或客户成效。