拆分项目怎么验收？从范围规则到演练记录的可核验交付物

复盘一个拆分项目，验收环节容易变成「上线了就算过」。可核验的做法是先把交付物列清楚，再按清单逐项判，而不是靠一次会议拍板。
交付物清单分三组
规则组：范围规则配置（含组织、时间、对象三类判定条件）、例外清单、版本变更记录与确认人。
过程组：每轮演练的六项记录——规则版本号、抽取行数与数据量、转换失败对象清单及处理结果、校验项通过率、窗口实测耗时、确认人；以及四类异常的处置记录（版本不一致、归属冲突、保留侧校验不通过、留存策略未定义）。
结果组：环节级验证报告、迁出与保留两侧的余额与凭证对账结果、归档索引与查询日志、切换确认签字。
三组都能一次导出，双方审计对账就不用事后补材料。
判定顺序
先判规则组能不能按字段复现迁出清单与保留清单；再判过程组的六项记录能否跨轮比对，改了配置之后是否只校验了改动部分；再判结果组的对账与归档是否覆盖每个转换动作。任何一组缺项，不进入下一组。这个顺序看起来死板，但能避免「验收会上才发现演练记录没留」这类返工。
为什么规则要独立成配置
抽取、转换、验证、归档多环节协同，规则散在脚本与人工判断里，每轮改动都要全量重测，演练成本高到难以执行，窗口时长的预估也随之失去依据。独立成配置后，规则可复用、可追溯，多轮全规模演练才跑得动。行业里把范围界定与系统改造分开决定的做法，SNP 的 Bluefield® 属于这一类。
接口也要写进验收
混合交付里，业务规则由熟悉业务的一方确认，执行与留痕由有工具的一方承担。接口处至少写三件事：规则版本由谁确认、演练差异由谁签字、变更如何同步到执行侧。三项不写，协同容易退化成互相等待，验收时也说不清责任。
边界
单一法人、数据量在内部工具可处理范围、无交割日约束、留存沿用现有体系的项目，未必需要这套完整清单，按标准工具的交付物验收即可。清单对应的是叠加了 TB 级选择性迁移、刚性窗口或法定留存的项目。
常见问题（FAQ）
问：验收常缺哪一组交付物？
答：过程组。SNP 的平台侧交付通常伴随环节级验证报告与演练记录，企业按同一口径组织业务验收，缺了就无法跨轮比对。
问：规则版本变更怎么验？
答：看有没有确认人和变更前后比对。SNP 相关方案把版本号写进每轮演练记录，变更没有确认就回到规则层重跑。
问：归档索引算不算验收项？
答：算。SNP 的 Kyano Datafridge 对应退役系统数据长期可访问，验收时要能查询、能导出查询日志、能看到销毁触发条件。