全局待决事项登记册
待决事项用于记录尚未完成正式裁决、但可能影响 PHITE 业务规则、系统设计或跨 Foundation 治理的问题。“当前倾向”只是一项工作假设，既不代表正式批准，也不得被 AI 代理当作已经生效的企业规则。
- “可选方案”列出当前仍可讨论的路径，不表示所有方案均已获认可。
- “当前倾向”说明团队现阶段的工作位置，不授予任何批准或执行权限。
- “决策责任人”显示“待明确”时，表示责任归属本身仍是待决事实。
- 状态“待决”对应机器状态
Open；中文显示不会改变底层状态。
待决事项登记
Section titled “待决事项登记”| 编号 | 待决问题 | 为什么重要 | 关联 Foundation | 可选方案 | 当前倾向 | 决策责任人 | 状态 |
|---|---|---|---|---|---|---|---|
| OD-ENT-001 | 哪一治理主体负责批准、冻结、评审和废止 Foundation 标准？ | 如果没有明确的问责主体，权威性元数据就无法形成可执行的治理约束。 | 企业基础、知识体系 | 企业级负责人；跨职能治理委员会；获授权的各 Foundation 负责人 | 由各 Foundation 负责人承担，并进行跨 Foundation 评审 | 待明确 | 待决 |
| OD-ENT-002 | PHITE 应如何统一管理 Workflow 的标识与编号、责任归属、版本、校验、批准及金标晋级？ | 如无企业级治理，临时 Workflow ID 或成熟度标签可能被误认为已经批准的标准。 | 企业基础、知识体系、全部 Foundation | 保留临时 ID；建立企业统一标准；按 Foundation 分域管理 | 临时 ID 继续保留，统一规则由有权治理主体裁定 | 待明确 | 待决 |
| OD-PRJ-001 | 范围、范围分解、WBS、工作包、交付物、责任边界与接口之间应如何关联？ | 这套分解关系连接合同范围与设计、采购、计划、成本和移交，是跨领域控制的共同基础。 | 项目管理、商务管理、设计管理、采购管理、成本控制、计划与控制 | 以 WBS 为主；以范围为主；采用混合分解 | 采用混合模式，待业务研讨确认 | 待明确 | 待决 |
| OD-DES-001 | MEC、EIA 等专业代码及其显示名称，哪一套应作为正式标准？ |
已冻结来源中的代码一致，但显示名称互相冲突；直接选择名称会造成无依据的标准变更。 | 设计管理、企业基础、采购管理、文档控制 | 保留现有代码并选定一套显示名；扩充主数据后再统一 | 在正式变更获批前保留稳定代码 | 待明确 | 待决 — 需完成 Foundation 变更 |
| OD-DES-002 | 设计交付物发布的触发条件、强制评审范围、最终人工授权及委托、根对象与版本状态协同、证据集和验收规则是什么？ | 如果这些规则缺失，发布可能越权、证据不完整，或把设计发布与受控文档签发混为一谈。 | 设计管理、文档控制、项目管理、工程变更 | 保持试点为草案并在人工关口默认阻断；由有权负责人先制定发布标准 | 在有权负责人批准发布标准前维持草案并默认阻断 | 待明确 | 待决 |
| OD-DES-003 | 哪一层证据定义 PHITE 当前的设计交付物目录，历史项目条目、自由文本 deliverable_type 与受控 document_type 应如何映射？ |
109 项项目清单、14 个设计代码、21 个文档枚举和三专业主数据并非一一对应；强行选取单一层级会遗漏证据或混淆交付物与文档。 | 设计管理、项目管理、文档控制、采购管理 | 采用单一统一目录；保留企业级交付物类别、项目交付物条目与受控文档类型三层 | 保留三层并用实际项目逐项验证映射 | 待明确 | 待决 — 有权负责人作出决定后方可启动 OS-DES-015 |
| OD-PROC-001 | 在目标采购链中，PL、PIV、付款申请、发票与 PAY 的正式身份和边界分别是什么？ | 目标链超出了已批准的 87 个集合对象；未经决定直接扩展会制造虚假的企业规则。 | 采购管理、商务管理、成本控制 | 扩展现有根对象；接入财务拥有的事实；经批准后新增根对象 | 先映射现有事实，再决定是否扩展 | 待明确 | 待决 |
| OD-DOC-001 | PHITE 的 MDR、签发目的、文档传递单、客户回复代码、重新提交、替代、竣工版和最终移交规则是什么？ | 正式文档交付不能仅根据工程版本规则推导，否则会混淆版本控制与对外交付责任。 | 文档控制、设计管理、项目管理、质量管理 | 建立企业统一文档控制生命周期；在企业最低要求上允许项目裁剪 | 采用企业最低要求，并允许项目裁剪 | 待明确 | 待决 |
| OD-COST-001 | PHITE 的正式项目成本模型是什么，成本代码由谁负责治理？ | 预算、承诺、实际或应计、预测、EAC 与利润必须可以对账，同时不能把采购事实与会计事实混为一体。 | 成本控制、采购管理、商务管理、项目管理 | ERP 主导；财务主导；项目控制主导的联邦模型 | 采用联邦模型 | 待明确 | 待决 |
| OD-CHG-001 | 哪些角色、关口和阈值负责工程变更影响评估与处置？ | 技术、文档、采购、进度、成本和商务影响需要协同授权，任何单一领域都不应越权裁决。 | 工程变更、设计管理、文档控制、采购管理、计划与控制、成本控制、商务管理 | 中央变更委员会；分级授权；按项目授权 | 采用分级授权 | 待明确 | 待决 |
| OD-QLT-001 | 从 ITP 到放行和质量档案，PHITE 的质量证据链应如何定义？ | 停检点、见证点、NCR、纠正措施、FAT、未完项和放行必须具有可审计且连续的语义。 | 质量管理、采购管理、施工与调试、文档控制 | 扩展现有证据模板；建立专用质量根对象；采用混合模式 | 采用混合模式，待流程映射确认 | 待明确 | 待决 |
| OD-CC-001 | 机械完工、调试、性能试验、移交、PAC、FAC 与质保的正式关口和含义是什么？ | 合同、项目、现场、质量和服务状态必须相互协调，但不能被压缩成同一个状态。 | 施工与调试、项目管理、商务管理、质量管理 | 企业统一关口；合同专属关口；混合模式 | 采用企业最低要求，并叠加合同专属关口 | 待明确 | 待决 |
| OD-COM-001 | 商务变更、索赔、付款条款、应收款、质保义务和商务风险应如何与合同及工程变更关联？ | 商务权利必须能够追溯到证据及其成本和进度影响，否则索赔与变更无法可靠评估。 | 商务管理、工程变更、成本控制、项目管理 | 以合同为中心；以工程变更为中心；采用混合模式 | 以合同为中心，并使用有类型的工程变更关联 | 待明确 | 待决 |
| OD-PLAN-001 | PHITE 的计划控制边界与 Primavera 或客户进度计划之间如何划分？ | PHITE 需要管理正式基准、里程碑、进度、预测和赶工方案，但不应重新开发专业计划引擎。 | 计划与控制、项目管理、工程变更、成本控制 | 仅做外部集成；维护内部摘要；采用混合模式 | 建立内部控制层，并引用外部进度计划 | 待明确 | 待决 |
| OD-KNW-001 | 经验教训、供应商经验、技术参考和历史背景分别由哪个系统负责，内容冲突时如何呈现？ | 知识检索必须保留来源，并避免复制运营事实；否则检索结果可能掩盖权威差异。 | 知识体系、企业基础、全部 Foundation | 由 GBrain 集中管理；由代码仓库集中管理；采用联邦模式 | 采用联邦模式，并以 Handbook 权威顺序处理冲突 | 待明确 | 待决 |
已知但尚未逐项建档的问题
Section titled “已知但尚未逐项建档的问题”现有仓库还记录了若干依赖有权负责人的缺口，包括启动会编号、部分合同编号、非项目采购申请、项目月度序列溢出、生产 UI 与 ACL、Workflow、审批与通知、已存 UI 蓝图的当前状态，以及运行时、物理外键、并发和插件状态验证。
这些问题仍保留在来源索引中。本次金标样例只改善现有登记内容，不新建决定、不改变其状态，也不替有权负责人作出裁决。
只有具备相应权责的负责人记录正式决定、理由、影响、状态和证据后，待决事项才可关闭。先修改数据模式、UI 或代码，不能替代决定，也不能把“当前倾向”升级为已批准规则。