Palantir Study 27｜Global Branching：安全修改生产 Ontology

恒川工业的缺料应用已经上线。采购员从外部门户读取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 的端到端资源。PalantirGlobal Branching core concepts它解决的是系统怎样变化。调拨 520 EA、催交还是改序哪个业务方案更好仍属于第 20 篇的 Scenario。架构位置一套工程机制管理多类资源它的上一级是 Foundry developer toolchain基础是 Space、Organization、Project/Resource 权限、各资源建设应用、Lineage 与 Build使用者包括 Ontology builder、数据工程师、应用 builder、Reviewer 和平台管理员。Resource protection 决定哪些资源不能直接改mainObservability 负责观察合并后的运行Foundry DevOps 负责打包、发布和升级。它们相邻但不互相替代。六个词连成一条生产变更链术语定义恒川例子Branch从main分出的隔离工作环境gb/supplier-commitment-confidenceChange资源在 Branch 上保存的新增、修改或删除差异这是通用工程用语新增可信度 Property更新页面与 Action criteriaProposal承载说明、Checks、Review、Approval 和 Merge 状态的变更提案“采购承诺可信度 v1”变更包Rebase把main最新变化带入 Branch再重新应用已保存变化吸收计划团队刚合入的风险分级更新Conflictmain与 Branch 改了同一资源的同一 Property无法自动取舍两边都改了Supply Disruption.risk_levelMergeChecks 和 approvals 满足后把获准变化合入main新 Property、页面和 Action 规则进入主线Global Proposal 包含 Ontology changes 时还会自动形成Ontologyproposal跟踪 Ontology 专属变化和评审。它类似 Pull Request但不是恒川的业务方案AP-2048也不批准采购动作。PalantirBranching the Ontology在产品里看见“一个中心、两类入口”Global Branching application集中列出 Branches 和 Proposals可创建、归档、管理角色并进入 Checks、Review 和 Merge 页面。各受支持应用还有branchselector和 branch taskbar。Builder 在 Ontology Manager 修改 Property在 Workshop 改页面在 Pipeline Builder 调整逻辑taskbar 标明当前 Branch并连接到 Proposal 与 Rebase。PalantirGlobal Branching application统一的是变更流程不是资源格式。Ontology、Workshop、Pipeline 仍由各自应用编辑Global Branching 把它们放进同一条隔离、评审和合并链。Global Branching、Scenario、Git 不试同一种东西判断问题Global BranchingOntology ScenarioGit branch谁使用Builder、工程师、Resource owner、Reviewer计划员、采购员、运营负责人、Agent软件开发者试什么Ontology 定义、应用、Pipeline 和受支持资源对既有业务状态采取候选 Actions 的后果Repository 中的代码/文本进主线Proposal、Checks、Approval、Merge选择后经 merge Action 或正式 ActionPull/Merge Request 与部署链不能证明外部应用兼容、生产运行健康WMS/ERP 已执行Ontology 数据、权限和业务 Action 正确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 等集成同时明确仍有资源未支持。PalantirIntegrations截至核验日TypeScript v2 和 Python Functions 不能直接在 Branch 修改引用特定版本测试时Function code 只能使用mainschema。OSDK 也不能 branch。支持面必须按目标 enrollment 逐项确认。恒川先做不要只分支一个 Property“增加承诺可信度”若被翻译成“加一列”变更就被做小了。恒川建立 Branchgb/supplier-commitment-confidence把影响链写清为Purchase Order Line增加supplier_commitment_confidence0—100与confidence_evidence_time更新Supply Disruption.risk_level的说明声明可信度是风险证据之一Workshop 显示评分、证据时间与来源状态更新Confirm Expediting PlanAction criteria可信度低于 60 时必须填写人工理由检查第 26 篇的Hengchuan Supplier Recovery Portal。它通过 OSDK 读取订单行并依赖既有risk_level值与 Action 参数明确非目标不重写风险模型不改变 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一样指向配置的外部环境可能击中生产系统。PalantirBranching Action Types恒川只验证 Ontology edits、criteria、权限和页面反馈不开启生产 SRM/ERP 外部调用。第三步Rebase 暴露真正的定义冲突采购测试期间计划团队的 Proposal 先合入main。他们也修改了Supply Disruption.risk_level把客户订单优先级加入分级口径并更新同一 Property 的说明。采购 Branch 因落后于mainRebase check 失败。Rebase 会吸收main最新变化再重新应用采购 Changes。不同资源或不同 Property 的变化可自动处理两边都改了同一risk_level属于 true conflict必须人工解决。PalantirCore 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 权限。PalantirBranch securityProtected resource 必须通过 Branch 和 Approval。Project approval policy 可规定 eligible reviewers、审批数以及 contributor 能否批准自己的变化。Ontology resource 要启用 protection需先采用 project permissions。PalantirResource protectionMerge 权限也容易误写。当前文档说明能查看 Proposal 的用户在资源级 approvals/checks 已满足且没有Do not merge时可以触发 Merge。控制点是“谁能写、谁能批、哪些检查必须过”不是最后一个按钮。承接第 26 篇Branch 不能替你证明 OSDK 兼容OSDK 当前不可 branch外部门户的 SDK 仍基于mainschema。Global Branching 可以隔离 Ontology 与受支持的 Workshop Changes却不能生成“采购 Branch 专用 OSDK”来证明门户兼容。恒川采用两步发布先以 additive change 合入新 Property保留旧risk_level值与 Action 参数旧门户仍能工作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但普通资源的创建或删除会影响mainOntology 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 前的业务变更契约。字段恒川工业填写示例业务问题与结果SUP-0088多次延期采购员需看到可信度低于 60 时催交必须说明理由Branch / Ownergb/supplier-commitment-confidence/ Ontology ownerOntology Changes两个新 Properties、risk_level说明、Action criteria应用 ChangesWorkshop 展示评分、证据时间与低可信度提示非目标不重写风险模型不改 ERP 主数据不调用生产 SRM/ERP下游依赖Workshop、外部门户、OSDK、催交 Action、Automate权限Buyer 可见Supplier Collaboration User 不见内部评分Branch role 与编辑权分离Rebase / Conflictrisk_level与计划团队冲突保留旧值可信度先作为证据与 criteria兼容策略Additive、允许空值、保留参数Merge 后生成新版 OSDK测试证据订单行HC-PO-88210-20评分 42无理由提交被拒绝外部副作用关闭生产 Webhook、通知和外部 Function callsReviewersOntology、采购、计划、Portal、Security、Workshop ownersMerge / BuildChecks 全过先 Property/映射后 criteria构建受影响资源失败恢复保留旧语义修复未合并资源或提交补偿变化不承诺一键 revert上线验收旧门户可用新字段权限正确criteria 生效无越权催交BA 交付物二变更影响表影响对象风险Owner验证方法阻断 MergeOntology Property出现两套risk_level口径Ontology owner BADiff、术语评审是数据映射/索引字段缺失或索引失败Data ownerBranch 预览、缺失率是Action criteria阻断正常催交或被绕过Buyer owner42/60/空值用例是Workshop只见分数不见证据时间App owner任务流 UAT是外部门户/OSDK旧 SDK 与 schema 失配Portal owner旧版回归、新版 contract test是Automate / Agent规则或工具 schema 漂移Automation / Agent owner依赖清单与回归集是Security内部判断泄露给供应商账号Security owner角色权限测试是Branch side effects测试误触 ERP/SRM/真实人员Action owner外部调用开关检查是RetentionInactive 后索引和证据丢失Branch ownerSpace policy、评审时限否需处置Merge / BuildPartial failure 造成过渡状态Release owner合并顺序、构建和补偿方案是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 官方固定对象、规则、表单或客户成效。