治理闭环的七个步骤与各步留痕

本篇说明炬擎数原治理闭环的七个步骤：提出、建成、安全扫描、三方审批、灰度上线、留痕审计与需要时回滚。七个步骤构成一条完整链路，同时适用于平台上的应用与端侧模型的下发。

七个步骤的顺序

治理闭环的七个步骤依次为：提出、建成、安全扫描、三方审批、灰度上线、留痕审计、需要时回滚。顺序包含两段逻辑。前三步是准备阶段：需求提出，应用或模型建成，然后接受安全扫描。中间三步是放行阶段：三方审批通过后按灰度范围上线，上线后进入留痕审计。

最后一步不是固定动作，而是前置条件，即需要时回滚。把它列在链路末端，说明回滚被设计为链路的一部分，而不是异常发生后的临时补救。七个步骤不是七次互相独立的动作。

灰度上线与留痕审计在时间上重叠：灰度期间就已经开始记录，审计的依据正是这段时间的调用数据。

各步骤的产出物

每一步都留下可检查的产出物。提出环节产出需求描述与场景边界；建成环节产出可运行的制品与版本号；安全扫描环节产出扫描结果；三方审批环节产出三方签署意见，并随制品一同留存。

灰度上线环节产出灰度范围与放量记录；留痕审计环节产出工具调用与数据访问记录；回滚环节产出回滚前后的版本对应关系。产出物的存在使流程在事后复盘时有据可依，而不是只能依赖参与者的回忆。产出物同时是下一步骤的输入。

扫描结果进入审批环节，审批意见随制品进入发布环节，灰度期间的记录进入审计环节。这一衔接关系使链路具备可追溯性：任何一步的结论都能追溯到它的依据。

一条链路覆盖两类对象

官网说明同一条链路覆盖平台上的应用与端侧模型的下发。两类对象的形态不同：应用运行在平台侧，模型下发到终端设备。但治理要求一致，都要经过扫描与审批，都要有版本对应关系，都要能回滚。覆盖两类对象意味着治理机制按流程设计，而不是按产品设计。

当模型版本需要更新时，走的路径与一次应用变更相同。这一设计降低了治理规则的维护成本，也使两类变更的审计口径保持一致。

两类对象的步长也不同。应用变更通常按需求批次推进，每次变更对应一组功能调整；模型下发则可能因规格更新或适配需要而单独发生，一次可能只涉及一个档位。

链路相同而步长不同，意味着审批与扫描的对象需要按次界定：以一次应用变更或一次模型下发为一个单位，而不是以时间区间为单位。按次界定之后，每个单位都有各自的扫描结果、审批意见与版本对应关系，审计时可按单位检索。

治理闭环因此可以理解为一条按次执行的链路，而不是一套定期执行的检查制度。