负责人 欧阳未　·　状态 定稿　·　覆盖 24 个标书单元　·　 批注 5

1、数据治理规划和实施服务（3.2.6.1）

数据治理在本项目中要达成两重目标。一重是把天地奔牛的数据管理能力提升到数据管理能力成熟度（Data Management Capability Maturity Assessment Model，DCMM）三级所要求的水平：九大能力域的管理过程被定义、被执行，执行留有可供检查的记录。另一重是为四类高质量数据集的加工生产提供口径、规则与证据，使每一个数据子集都能回答它从哪里来、按什么标准加工、由谁批准发布。两重目标共用一套制度、一个平台与一套记录（b1218）。

建设范围分三部分。治理体系部分，覆盖九大能力域的现状诊断、规划与制度建设，输出三十七项规划成果（b1219—b1223）。治理平台部分，建设承载元数据、数据标准、质量规则、安全分级、资产目录与指标卡的管控平台，九项治理内容在平台上落地（b1224、b1336）。治理实施部分，以十七套外围应用系统为数据来源、以九个业务域为落地对象，把标准、分级与规则加载到数据汇聚与加工的各个环节上运行，同步构建决策数据指标体系（b1225、b1226）。

运行组织按三层设置。决策层是数据治理委员会，决议数据战略目标、跨部门口径争议、资源投入与考核结果。管理层是数据管理办公室与按能力域设置的九个数据治理工作组，办公室负责规划落地、制度起草、流程运行与指标采集，工作组负责本域规则的细化与会签。执行层是各业务域的数据专责、源系统的系统管理岗与我方项目组。三层之间有一条固定界线：制度与口径的审批权在甲方，规则起草、平台实现与数据加工由我方承办，业务口径由业务归口部门会签确认。

交付责任按主体分清。我方交付现状诊断报告与高质量数据集验证场景数据需求清单两份评估成果、三十七项规划成果、三份配套细则、十份标注规范、四类标准验证成果，以及一套治理平台及其运行记录。甲方承担治理组织的正式发文、业务口径的会签、源系统的授权开放与贯标评估的申报。贯标结论由具备资质的认定机构作出。治理部分的验收以三件事为准：成果物齐备、平台功能可用、执行记录可被抽查核对。

1.1 治理目标与建设范围

1.1.1 贯标与数据集建设对治理的要求不同

招标文件把治理目标写成一句话：以通过 DCMM 三级认证为目标，以满足 11 个智能化应用场景的高质量数据集建设为业务导向，构建全域数据治理体系，配套落地数据治理平台（b1218）。这句话里有两个目标。贯标认证关心的是能力域有没有被规范地管起来、管的过程有没有记录可查；数据集建设关心的是某一张图纸、某一个热处理炉次、某一段振动波形今天能不能被稳定地取到、对齐、标注并交付。

两个目标的工作量落点不同。贯标的落点在制度、流程与组织，数据集建设的落点在字段、口径与可用率。本项目的处理方式是以后者为主线组织工作，把前者所需的制度与执行记录作为主线工作的自然产物：每一条标准发布时同时留下评审记录，每一次质量稽核运行时同时留下稽核台账，每一次数据服务授权时同时留下审批留痕。这样做的理由很直接——为贯标单独攒一套文档，文档与现场脱节，评审时问到执行记录就露底；而把记录长在业务动作上，记录是跑出来的，不是补出来的。

本包承担的是数据加工生产服务。治理体系的建设、治理平台的落地、治理文档的交付与数据治理实施均在本包范围内（b1224、b1226）。11 个智能化应用场景所需的数据集与场景验证服务由本包提供，场景本身的建设由甲方另行安排。

1.1.2 治理在七项服务中的落点

招标文件 3.2.1 服务采购清单列明七项服务（b0803、b0804r01）。七项之间不是并列的七块工程，而是一条生产线上的不同工位：第 1 项把数据取进来，第 2 项提供加工手段，第 5 项是加工实施的主体并把治理作为横向管控层贯穿，第 3 项把成品挂出去运营，第 4 项把软硬件装起来，第 6、7 两项由具备资质的机构从外部核验。治理不是其中的第八项，而是落在每一项上的约束与留痕要求。表 1-1 逐项给出治理在该项服务中的具体落点。

表 1-1　治理在七项服务中的落点

清单第 5 项列了八条子要求。第 1 条数据治理规划和实施服务是本节与两个治理子节的主体内容。第 2 条技术标准验证与第 4 条数据标注规范，其依据都是治理侧的标准体系，因此与治理一并论述，分别在第 2 章与第 3 章。其余五条——数据标准专家库、约 30＋项软建设配套措施、不少于 7 份项目内部管理制度、安全合规核查与去标识化、知识产权指标——按上表所列位置论述（b0804r06）。

1.1.3 运行组织与审批权限

治理动作能不能落地，取决于每一件事有没有确定的起草方、会签方与批准方。本项目把这三者在项目启动阶段一次定清，写入数据治理组织架构与各项管理办法，不留「由相关部门协商确定」这类无主语的条款。

权限按三级分配。单域规则的发布、工作包排期、一般偏差的处理在数据管理办公室一级；跨域口径的裁定、安全分级中最高两级数据的授权、资源投入与考核结果在数据治理委员会一级；本域数据的口径确认、权属归属与对外共享范围在业务归口部门一级。三级之上有一条上报规则：办公室协调不成的事项上报委员会，委员会按季度例会或专题会裁定，裁定结论形成决议并更新到对应的制度条款中。

我方在这套组织里的位置是承办方。规则草案、平台配置、数据加工与证据归集由我方承担；审批、会签与口径确认由甲方相应层级作出。在甲方治理组织正式发文之前，各项成果物只出送审稿，以项目联合工作组形式临时议事，决议在组织设立后追认，避免因组织未定而使前期工作全部停摆。

表 1-2　治理事项的起草、会签、批准与留痕

1.1.4 治理口径的单一来源

同一个口径在两处定义，迟早会出现两个值。治理涉及的口径大多跨环节使用：一个安全分级结论既决定平台上的标签与访问权限，也决定数据集发布时的脱敏要求；一份质量规则既是业务数据稽核的判据，也是数据集质检门控的来源。这类口径若由各自使用的环节分别写一遍，差异往往要等到某次统计对不上才暴露出来，那时已经波及按旧口径产出的成果。本项目的做法是每一类口径只在一处定义，其余各处引用；凡需要修改口径的，一律回到定义处修改，不在使用处就地调整。

表 1-3 所列十类，是本项目中跨环节使用最频繁、也最容易各写一套的口径。它们的归属不按文档的先后或篇幅划分，而按规则责任：现状评估结论、组织制度、数据架构与资产的口径归两份数据治理规划，评测指标归数据集质量评测方案，分级标签的技术管控与测评归安全方案，目录与确权的功能实现归数据集运营平台，标注的实施方法归加工生产与工具链，各类报告模板归附录佐证卷——谁负责制定这件事的规则，谁所在的成果就是它的定义处。

读表时，中间一列是判据，指明该口径唯一可被修改的地方；右侧一列是用法，说明本节对它的引用方式，只作引用不另立口径。其中三十七项治理文档清单与分级标签两行最为关键，它们被引用的环节最多，也最容易在各节分头细化时走样。据此可以给出一致性的控制口径：首次交付前对表内十类口径逐项核对一次定义处与各引用处的取值，作为基线；此后随制度与成果的修订，逐步做到口径一经变更即触发各引用处的同步核对；若核对中发现同一口径出现两个取值，以定义处为准，使用处当次作废并回溯更新受影响的成果，变更过程进制度修订记录留痕。

表 1-3　治理口径的单一来源与引用关系

1.1.5 治理在项目生产逻辑中的位置

招标文件把本项目的生产逻辑写得很清楚：以数据治理为横向贯穿管控层，以知识本体与知识库为统一知识底座，以采集、预处理、标注、合成、增强、质检、验证为纵向生产链路，并以血缘追溯驱动定向回流（b1215）。治理不是生产链路上的某一个环节，而是贯穿各环节的约束与留痕机制。图 1-1 按这一关系给出治理与生产链路、三个平台之间的位置与数据流向。

图 1-1　治理作为横向管控层在项目中的位置

图 1-1　治理作为横向管控层在项目中的位置。数据来源：招标文件第五章 3.2.6 生产逻辑表述（b1215）、3.2.1 服务采购清单第 1、3 项（b0804r02、b0804r04）、3.2.6.1.2 实施要求（b1336）。

1.2 全域数据治理成熟度评估与 DCMM 三级达成路径

1.2.1 三级的判据是执行记录，不是文档数量

招标文件要求对标 DCMM 三级成熟度要求开展全域成熟度评估，形成三级现状诊断报告，明确短板与优化路径（b1219、b1220）。三级在 GB/T 36073—2018《数据管理能力成熟度评估模型》中的表述是稳健级：管理过程已被定义并形成文件，相关人员按定义的过程执行，过程的执行留有记录并可被检查。三个条件里，前两个靠编制与发布，第三个靠时间。

这一点决定了本项目贯标工作的排法。如果把制度集中在项目后期发布，发布之日距评审之日只有数月，评审时能提交的执行记录就只有几个批次，定级会被核减。因此制度与标准的发布时点在规划中被刻意提前，流程优先上线以积累记录——这与「数据治理规划（一）」把制度发布过晚列为贯标风险、以及「数据治理规划（二）」的实施路径把标准与分级排进第一阶段，是同一条考虑。两处的时点安排以本节表 1-4 的路径为准。

这里需要把「二级与三级的差别」说透，因为它决定了本项目治理工作的投入分布。二级（受管理级）要求过程在局部被管理、有人负责、有基本记录；三级（稳健级）增加的是三条：过程被定义并形成文件、相关人员按定义的过程执行、执行留有记录并可被检查。

差别不在文档的厚度，在于能否证明「不是写了一套、做了另一套」。评估师现场取证的典型动作是：随机抽一个业务域、抽一个时间段，要求调出该时段内这一过程的全部执行记录，核对记录中的责任人、时点、结论是否与制度规定一致。记录条数少、时间跨度短、责任人与制度不符，三项中任一项不过，该过程域就会被核减到二级。

由此确定本项目的两条排法。第一条是制度先行、流程随后、记录积累贯穿全程：政策与标准类文件在第一阶段发布，不等到建设后期；流程在平台上线后即刻启用，哪怕初期批次少，也让记录从第一天开始累积。

第二条是优先在有真实业务量的域上跑流程：研发设计、生产制造、质量管理三个域有持续的数据加工批次，同样的制度在这三个域上能在半年内积累出上百条执行记录，而在人力资源域可能只有十几条。评估抽样时，抽到前者能拿出完整证据链，抽到后者也能说明记录条数与该域实际业务量相称——这两点都是评估师认可的答法。

贯标评估的组织与申报由招标方主导，我方承担诊断、规划、制度编制、流程落地与证据归集五项工作，并配合评估准备与现场答疑。评估结论由认定机构作出；我方对上述五项工作的完成质量与证据的可核查性负责。责任边界在 2.5 节另有说明。

1.2.2 四段路径与证据积累

贯标路径分四段：诊断、规划、实施、送审。四段不是依次完成再交棒，规划与实施有相当长的重叠期，否则记录来不及积累。

表 1-4　DCMM 三级达成路径与各段产出

四段中第三段最长，因为记录需要在真实业务上跑够周期。本项目的安排是把第一阶段的制度与标准发布节点压在首批数据汇聚与数据集加工开始之前，使加工过程本身就在治理约束下运行，加工留下的血缘、质量评分与审批留痕同时成为贯标证据。这样记录的积累周期与项目的加工周期同步，不另占时间。

图 1-2　贯标四段路径与执行记录的积累关系

图 1-2　贯标四段路径与执行记录的积累关系。数据来源：招标文件第五章 3.2.6.1（b1219—b1226）、3.2.6.1.1（b1227）、3.2.6.1.2（b1335）；周期取招标文件第 3 章建设周期与质保期要求。

1.2.3 七个阶段的输入、活动、证据与通过条件

四段路径是时间上的粗分，排到执行层面还要再细一层。从现状调查到正式评价共七个阶段，每个阶段有自己的输入、活动与证据，也各有一条判断能否往下走的通过条件。通过条件写明了，阶段推进就是逐条核对；没写明，每到一个节点都要临时议一次，工期就是这样拖掉的。不通过时的整改口径同样事先定下，表 1-5 逐阶段列出。

表 1-5　贯标七个阶段的输入、活动、证据、负责人与通过条件

第五、第六两个阶段的结论是内部结论。这两个阶段我方出具的是自评报告与内审发现项，用途是判断送审准备是否充分、哪些能力域还不具备送审条件。自评得分不作为能力成熟度等级的结论使用，项目进度汇报与阶段验收材料中同样按此口径表述；等级结论只来自认定机构的正式评价。把内部自评写成认证结果，评审现场一对证据就会露底，代价远大于如实说明准备程度。

1.2.4 能力域数量的口径说明

招标文件两处写「DCMM 九大能力域」（b1221、b1229），并在 3.2.6.1.1.2 项下实列九个规划域：数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。GB/T 36073—2018 的能力域为八个、过程域为二十八个。

本投标文件统一按招标文件原文口径使用「九大能力域」一词，并在「数据治理规划（一）」的能力域与过程域对照表中把九个能力域逐一对照到基准模型的过程域，使评估结论既能逐条回到招标文件的规划域要求，又能直接支撑按基准模型开展的贯标送审。两套划分之间的对应关系在诊断报告中作为附表给出，评审时可双向查对。

1.2.5 贯标评估的组织分工

DCMM 贯标评估由具备资质的认定机构实施并出具结论，认证主体是甲方。我方承担的是达成三级所需的能力建设与送审支撑：开展现状诊断、编制九域规划成果、建设治理平台、推动治理实施、整理评审证据包、配合现场评审与问题整改。认证的受理时点与出证时点取决于认定机构的受理安排，本节不就出证时点作承诺。

若在送审准备中发现某一能力域的执行记录积累不足两个考核周期，我方的建议是调整送审时点而非压缩记录周期：送审被核减的代价高于延后送审。这一回退口径与「数据治理规划（一）」列出的贯标风险条一致。

1.3 数据治理规划要求（3.2.6.1.1）

1.3.1 三套九项清单，不是同一组九

招标文件在三处各出现一组九，三组的对象不同，合读时很容易混为一谈，混了以后矩阵、排期与验收口径都会错位。

第一组是九大能力域，出自治理规划要求（b1221、b1227），指数据战略、数据治理、数据架构、数据资产、数据标准、数据质量、数据安全、数据生存周期、数据应用流通。它们是规划与制度的分域，决定写哪些文件、设哪些岗位、按什么条款考核。本投标文件中「能力域」与「规划域」同义。

第二组是九项治理内容，出自治理实施要求（b1336），指数据汇聚、数据处理、元数据管理、数据资产管理、数据标准管理、数据质量管理、数据安全管理、数据指标管理、数据服务管理。它们是治理平台上的执行能力，决定用什么功能做、产生什么记录。

第三组是九个业务域，同样出自 b1336，指人力资源、研发设计、生产制造、仓储物流、财务管理、设备管理、采购管理、营销管理、质量管理。它们是治理动作的落地对象，决定在谁的数据上做。

三组的关系是一句话：能力域出规则，治理内容是平台把规则执行出来的动作，业务域是动作施加的对象。以「数据标准」为例，它在第一组里是一个能力域，产出数据元标准与参考数据码表；在第二组里对应「数据标准管理」，是平台上的标准录入、版本管理、映射对照与下发功能；在第三组的九个业务域里，表现为各域的字段分别挂到哪一条标准上、挂了多少、还差多少。名称相近而所指不同，本投标文件自本节起统一按此区分。

1.3.2 三套清单的对应关系

三组之间不是一一对应，强行对齐反而会造出不存在的格子。表 1-6 以第二组的九项治理内容为主键，向左指出规则由哪个能力域产出，向右指出在九个业务域的落地次序，中间给出平台承载的模块与产生的运行记录。这张表是后续排期、平台配置与验收核对共用的底表。

表 1-6　九项治理内容与九大能力域、九个业务域的对应

表 1-6 里没有「数据战略」与「数据治理」两行，不是遗漏。这两个能力域产出的是目标、组织、制度与考核，落在发文件、会议纪要与考核结果上，由平台的流程与审批功能留痕，不对应某一项具体的治理内容。九个业务域的逐格优先批次与各域实施重点在「数据治理规划（二）」的落地矩阵中逐格给出，本节给的是对应关系本身。

图 1-3　三套九项清单的对应关系

图 1-3　三套九项清单的对应关系。数据来源：招标文件第五章 3.2.6.1（b1221）、3.2.6.1.1.2 项下实列的九个规划域、3.2.6.1.2 九个业务域与九项治理内容（b1336）。

1.3.3 九大能力域的三层结构

九个能力域放在一张表里看像九件平行的事，实际它们是三层。最上面两域回答「谁来管、按什么方向管」：数据战略定方向与路线图，数据治理定组织、制度与考核。中间三域回答「管什么」：数据架构定数据怎么组织与怎么流动，数据标准定每个字段与每个指标的口径，数据资产定哪些数据被登记为资产、归谁、值多少。外围四域回答「管得住没有」：数据质量校验数据对不对，数据安全管住谁能看、看多少，数据生存周期管住从需求到退役的每一步有没有留痕，数据应用流通管住数据以什么形态出去。

这个分层有实际用处。诊断时若某个域评分低，分层能指出是上层缺位还是下层缺工具——战略与治理两域弱，则下面七域的规划无人审批、无人考核，先补组织；中间三域弱，则外围四域的规则无依据可写，先补标准；外围四域弱而中间三域齐备，则多半是平台能力与执行记录的问题，补工具与流程即可。「数据治理规划（一）」的整改优先级四象限就是按这一判断给出的。

图 1-4　九大能力域的三层结构与域间主要接口

图 1-4　九大能力域的三层结构与域间主要接口。数据来源：招标文件第五章 3.2.6.1.1.2 项下实列的九个规划域（b1237 以下各项）、3.2.6.1.2 九个业务域（b1336）。

1.3.4 域间接口：谁的产出是谁的输入

九域之间的衔接点须单列。各域的域内设计分别写在两个子节里，域与域之间的交接若不单列，合在一起读会出现同一个对象在两处有两套说法。表 1-7 按「产出—接口件—消费方」三栏列出主要接口，接口件是可以指着看的具体东西，不是抽象的协同关系。

表 1-7　九大能力域之间的主要接口

表中有两条接口在子节里分别出现过，合读时以本表为准。一是知识本体与数据标准的关系：知识本体引用治理侧的术语标准、参考数据标准、数据元标准与指标标准，不另立一套术语；本体先行定义的领域概念回流为标准草案，字段定义冲突时以数据元标准为准。二是业务数据质量与数据集质量的关系：治理侧的质量规则管的是九个业务域的业务数据，数据集的质量评测按《高质量数据集质量评测规范》开展，两者的关系是前者为后者供料、后者的错样归因结论回流为前者的规则修订线索。

1.3.5 九个业务域的落地不均匀

九项治理内容是横向能力，九个业务域是纵向对象，交叉形成落地矩阵。矩阵不是均匀的：研发设计、生产制造、质量管理三个域直接产出工艺设计类、制造过程类与产品质量类数据集的主体样本，治理动作排在第一批；仓储物流与设备管理支撑供需计划类数据集与设备诊断相关场景，同在第一批但元数据与安全动作可后置；采购、营销、财务、人力资源四个域主要支撑决策指标与通用场景，治理动作整体后置，但其中三个域的安全分级要前置，原因是这三个域集中了分级标准中最高两级（L4 与 L5）的数据。

人力资源域在数据集贡献上权重最低，组织与岗位主数据却须排在第一批——它是其余八域权限模型与操作留痕的前提，也是第 1.5.4 节权限撤销一条能够成立的前提。逐格的优先批次与各域实施重点在「数据治理规划（二）」的落地矩阵与逐域实施重点中给出。

矩阵不均匀带来一个实际问题：同一项治理动作在不同业务域的成熟度不同步，跨域的数据一旦汇到一起，口径就会打架。最常见的三类冲突值得先讲清处置办法。

第一类是同一业务对象在两个域有两套编码。 例如同一台刮板输送机，设备管理域按设备台账编码，生产制造域按产品编号，两者在历史上各自独立维护、互不回指。处置办法不是强行统一编码——那会要求两个域同时改造既有系统，工期不可控——而是在主数据域建立对照关系并指定权威源：设备台账为权威源，生产侧保留原编码并挂对照，汇聚到数据集时按权威源归一。对照关系的建立与维护纳入主数据管理流程，新增对象在源头即登记对照，存量对象按批次补录。

第二类是同一指标在两个域有两个口径。 例如「在制品数量」，生产制造域按工序流转口径统计，仓储物流域按实物在库口径统计，两者在数值上长期不等且各有道理。处置办法是在数据标准域把两个口径都登记为正式指标，各自给出计算逻辑、适用场景与责任部门，不做二选一；在数据集中以指标标识区分，使用方按场景选用。强行取一个口径会让另一个域的历史数据全部失效，代价远大于并存。

第三类是同一份数据在两个域有不同的密级判定。 例如客户工况资料，营销域按商业信息判为内部级，而其中含矿方的地质参数，安全域按行业要求判为更高级别。处置办法是取高不取低，并把判定依据连同判定人一并登记；后续若业务部门主张降级，须以书面依据走变更流程，不以口头协商改变密级。这一条在本项目尤其要紧——数据集一旦按较低密级发布，回收的代价极高。

三类冲突的共同处置原则是：先登记、再裁决、不静默归并。任何一次归并都在元数据中留下归并前的原值与归并依据，使后续发现判断有误时可以回退。争议从登记到裁定的完整流程、各步的时限与裁决前的数据处置口径，在第 1.5.2 节给出。

1.3.6 十七套源系统的端到端控制链

治理落到执行层面，对象是十七套外围应用系统（b0804r02）。十七套按它们在数据链上的角色分五组，纳管重点与批次各不相同。分组的意义在于：同一条控制链在不同组系统上的难点不一样，把难点提前认出来，批次才排得准。

表 1-8　十七套外围应用系统的分组、纳管重点与批次

对这十七套系统，治理落地的形式是七条控制链：数据标准、主数据、元数据、数据质量、数据安全、数据生存周期、共享流通。每条链都要讲清同样的六件事——规则从哪来、每个环节谁负责、谁有权批、平台执行什么动作、不通的时候怎么办、留下什么记录。六件事缺一件，这条链在评审现场就答不上来。表 1-9 给出前三件，表 1-10 给出后三件。

表 1-9　七条控制链的规则来源、环节责任与审批权限

表 1-10　七条控制链的平台执行动作、例外处理与留痕

七条链在同一套系统上是叠加的，顺序不能乱。以热处理群控系统为例：炉次曲线要先有数据元标准与温度量纲口径，才谈得上登记元数据；要先有设备主数据，才知道这条曲线属于哪台炉；要先判定分级，才决定取数时是否脱敏；三件齐了才进入汇聚与加工，之后由质量稽核按规则打分，由生存周期的检查点控制接口变更，最终由共享流通决定它以什么形态出去。图 1-5 给出这一顺序。

图 1-5　一套源系统从接入到出数据的控制链

图 1-5　一套源系统从接入到出数据的控制链。数据来源：招标文件第五章 3.2.1 服务采购清单第 1 项（b0804r02）、3.2.6.1.2 九项治理内容（b1336）。

1.4 数据治理平台建设与数据治理实施

1.4.1 三个平台的职责分界依据

招标文件要求依据诊断报告与治理规划开展数据治理平台建设与数据治理实施工作（b1224），并要求九项治理内容在数据治理开发工具平台上落地（b1336）。同时，服务采购清单第 1、2、3 项另有数据资源建设、工具链建设与运营服务管理平台建设（b0804r02、b0804r03、b0804r04）。这里有三个平台角色，职责必须分清，否则实施时会出现同一份元数据在两处登记、同一个口径在两处定义。

分法的依据是三者管的东西不同。治理平台管的是约束与证据——数据元长什么样、字段属于哪一级、规则怎么判、血缘往哪连、谁在什么时候批准了什么。加工生产平台管的是生产动作——采集、预处理、标注、合成、增强、质检、验证各环节的任务编排与算力调度。运营服务管理平台管的是成品的对外服务——数据集目录、版本、权限、确权、挂牌、交易与审计。三者在本项目中作为奔牛数据智能平台的治理组件、加工组件与运营组件部署，共用统一身份与统一审计，但数据对象与责任主体各自独立。

这样分的实际好处在换件时能看出来：工具链随技术演进替换，加工组件变；治理侧的数据元、分级与规则不变，已加工数据的血缘与质量档案也不作废。反过来，治理标准修订时，受影响的加工任务由血缘反查出来，重跑范围是可计算的，不必全量重做。

图 1-6　三个平台的职责分界与接口

图 1-6　三个平台的职责分界与接口。数据来源：招标文件第五章 3.2.1 服务采购清单第 1、2、3 项（b0804r02、b0804r03、b0804r04）、3.2.6.1（b1224）、3.2.6.1.2（b1336）。

1.4.2 四条接口的落地口径

四条接口在实施中各有一条可检查的放行条件，口径如下。

下行约束这一条的放行条件是：接入对象的元数据登记、数据元映射、分级标签、入口校验规则四项齐备，未齐备的对象不进入下一环节的加工。这一条是治理侧对加工侧唯一的硬门槛，也是贯标时「过程被规范执行」最直接的证据。

上行采集这一条的放行条件是血缘粒度。血缘须登记到字段级，否则质检发现错样时无法定位到源字段，错样归因就只能停在数据集层面，定向回流无从下手。血缘不完整的对象在质量溯源中标记为不可溯源并优先补齐，这与「数据治理规划（二）」的元数据验收口径一致。

资产口径下行这一条的要点是单一事实源。资源目录条目、权属登记与价值等级只在治理侧维护一份，运营平台的挂牌、确权与交易以此为据展示与校验，不在运营侧另建一套权属台账。

使用情况回流这一条是价值评估的数据来源。使用计量不足一个季度的对象暂不作价值评估，避免以偶发调用量给出等级。

表 1-11 把三个平台的职责、对应的招标文件条款与论述位置并列，便于核对。

表 1-11　三个平台的职责与论述位置对照

四条接口都有「不通」的时候，口径须事先写明，否则实施期每遇一次就要议一次。

下行约束不通的典型情形是：某一批数据的分级标签尚未判定，而加工排期已到。处置是挂起该批而不是降级放行——按最小必要原则，该批先进入落地区的待判定分区，不进入加工区；待判定分区的存放期上限为十五个工作日，超期未判定的升级至数据治理工作组裁决。这样做的代价是该批次延期，收益是不会出现「先加工后发现密级判高了」这种只能整批作废的局面。

上行采集不通的典型情形是：血缘字段级登记缺失，而质检已经发现错样。处置是按可溯源程度分档：能溯源到字段的，走定向回流；只能溯源到批次的，整批复核；连批次都溯不到的，该数据子集标记为不可溯源并暂停发布，同时倒查血缘写入环节的缺陷。第三种情形在实施期应当趋近于零，若出现即为公共层缺陷，进缺陷台账按一级处置。

横向校验与标准下发两条接口的失效处置相对简单：横向校验不通时，以治理侧的规则库版本为准、加工侧按该版本重跑受影响批次；标准下发不通时，加工侧沿用上一版标准并在数据卡中标注所用标准版本号，待标准到位后评估是否需要回溯处理。四条接口的失效处置均产生记录，记录本身就是贯标评审时「过程异常也被管理」的证据。

1.5 治理机制的运行：五类情形的处置

控制链写的是常态。机制立不立得住，要看非常态怎么办。本项目的治理与数据集交付同时进行，下面五类情形在实施期一定会出现：制度改了而数据集已经发布、两个部门对同一个口径各执一词、历史数据有错要修、人员岗位变了权限要收、某一版数据集发出去之后发现要重发。这五类情形如果没有事先定好的处置办法，每出现一次都要临时开会商量，而商量的结果往往是把问题挂起来——挂起来的问题最终会变成验收时的争议。

下面逐类给出触发条件、处置步骤、责任与审批、平台动作、时限与留痕，并以本项目可能遇到的具体情形说明。表 1-12 在末尾汇总。

1.5.1 制度变更对已发布数据集的影响分析

典型情形：热处理工艺参数中的温度字段，首版数据元标准按「设定温度」定义，现状评估后期发现工艺与质量两个部门实际使用的是「炉内实测温度」，标准需要修订；而制造过程类数据集的首批已经发布，并已被两个场景的验证用例引用。

处置分六步。第一步，变更登记：由提出方填写变更申请，写明修订内容、依据、建议生效时点，数据管理办公室受理并编号。第二步，影响反查：平台按字段级血缘向下游反查，列出受影响的物理表、加工任务、数据子集与已发布版本，反查结果是一份可以逐行核对的清单，不是估计。第三步，影响分级，分三档——一档只是口径说明变化，数据值不变；二档需要重算派生值或重跑加工任务；三档需要重新标注或重新采集。第四步，按档处置：一档更新数据卡中的标准版本号与口径说明；二档重跑受影响的加工任务并发布新版本；三档列入定向回流计划并按批次排期，排期须与数据集交付节点一并核算。第五步，评审与批准：一档由数据管理办公室批准，二档、三档涉及跨域影响的报数据治理委员会。第六步，执行与通知：已发布版本不就地覆盖，发新版本并在数据卡中标注与上一版的差异，场景验证侧据此判断是否重测。

时限：影响分析在变更申请受理后 10 个工作日内出具；二档处置在新版本发布前完成；三档处置的排期在影响分析结论中一并给出。留痕：变更申请单、血缘反查清单、影响分级结论、新旧版本对照、通知回执。

这一步里最容易被跳过的是第二步。没有字段级血缘，影响范围就只能靠人回忆，回忆不全的部分会以「漏改」的形式在验收时暴露出来。这也是本节反复把血缘粒度写成字段级的原因。

1.5.2 跨部门口径争议的裁决

典型情形：同一道备料工序，总工艺路线上称一个名称，车间工艺卡片上称另一个名称；28 道备料工序中有若干道存在这类差异。工艺部门主张以总工艺路线为准，生产管理部门主张以车间卡片为准——车间卡片是实际执行用的。

处置分五步。第一步，争议登记：由发现方或业务数据专责提出，登记内容包括两种口径的表述、各自依据、涉及的字段与数据集范围。第二步，协商：数据管理办公室在 5 个工作日内组织对口工作组与双方归口部门协商；达成一致的，形成口径确认单并更新对应标准。第三步，裁定：协商不成的提交数据治理委员会，按季度例会或专题会裁定，裁定结论为唯一口径并写入标准。第四步，裁定前的数据处置：该字段在平台上标注「口径待确认」，相关数据子集可以继续加工但不进入发布；依赖该口径的场景验证范围相应收窄，并在验证报告中记录当时的数据条件。第五步，裁定后的收口：统一更新标准、映射与已加工数据的标签，已发布版本按 5.1 的影响分析流程处理。

第 1.3.5 节列出的三类冲突——同一对象两套编码、同一指标两个口径、同一数据两种密级——都走这条流程，差别只在裁定原则：编码类建对照不强行统一，指标类两个口径并存且各自登记，密级类取高不取低。留痕：争议登记单、协商纪要、委员会决议、口径确认单、受影响对象清单。

1.5.3 历史数据的修复

典型情形：约 63 万张历史工艺样本中存在扫描件缺页、图纸与工艺卡配对错位、关键字段缺失三类问题，这批数据已经汇聚并进入预训练语料的候选池。

处置分五步。第一步，发现与归因：由质量稽核或数据集质检发现，生成问题工单，按错样归因沿血缘定位到源字段与源批次。第二步，可修复性判定，分三档——可由源系统补数、可由档案原件重新采集、不可修复。第三步，分档处置：可修复的排入修复批次，修复后重新走质检门控；不可修复的从候选池剔除，在数据卡与已知缺陷清单中登记，同时核算该数据子集的规模缺口，缺口通过扩大其他来源的采集范围补齐，补齐方案随当期交付说明一并提交。第四步，版本处置：修复不就地覆盖原始落地件，原始件只读保存，修复结果作为新版本，血缘登记两者关系。第五步，统计处置：修复批次的质量指标与首批分别统计，避免修复后的数据拉高整体基线造成对数据质量的误判。

时限与门限：修复批次在问题确认后 1 个月内排期；同一源批次经两轮修复仍未达门限的，判为源头缺陷，转入采集方案或制度层面的调整，不再在加工侧反复返工。留痕：问题工单、归因结论、修复批次记录、原始件与修复件的血缘、已知缺陷清单。

1.5.4 权限撤销

典型情形：项目期内人员岗位调整、外部评测机构的临时账号到期、某业务域数据因分级上调需要收回已经授出的访问权。

处置分五步。第一步，触发：岗位变动由人力资源域的组织与岗位主数据变更驱动，账号到期由平台按有效期自动触发，分级上调由安全岗提出。第二步，权限反查：平台按权限模型列出该主体当前持有的全部授权，包括数据集下载、接口调用、标注任务与平台功能权限，反查结果需逐项处置，不做批量勾销。第三步，撤销方式分两种：岗位变动与分级上调即时撤销；账号到期给出不超过 5 个工作日的过渡期用于交接，过渡期内的操作全部进审计。第四步，副本核查：已下载的数据集副本不随授权撤销自动失效，因此撤销同时触发副本登记核查，要求持有方在约定期限内销毁或退回并出具回执。第五步，撤销后监控：撤销后的访问尝试进入审计告警，连续出现的按安全事件处置流程办理。

这条链能够成立的前提是组织与岗位主数据先行——不知道谁在哪个岗位，就无从判断谁该被撤权。这也是人力资源域虽然在数据集贡献上权重最低、治理动作却排在第一批的原因。留痕：撤销工单、权限反查清单、过渡期说明、副本销毁或退回回执、撤销后的访问审计记录。

1.5.5 数据集版本的重发

典型情形：某数据子集发布后，发现其中一个来源批次的安全分级判定有误——判高导致部分本可使用的样本被排除，或判低导致脱敏不足。

重发的触发条件写死三条：分级判定有误、质量门限误判、口径变更达到 5.1 所述的二档以上影响。三条之外的问题走修订而不走重发，避免版本号被频繁消耗、下游无从引用。

处置分六步。第一步，冻结：确认后 1 个工作日内冻结该版本的下载与挂牌，已授权方同步收到冻结通知。第二步，范围确定：平台按血缘确定受影响样本范围。第三步，重算与出版：重算受影响样本，出具新版本，并给出与上一版的差异清单，差异按新增、剔除、字段变更三类分别计数。第四步，旧版处置：旧版本标记为「已被替代」并保留可查，不删除——评测结论与场景验证结论都引用了版本号，删除会让这些结论失去依据。第五步，通知：通知已授权方与场景验证侧，由后者判断是否重测。第六步，复测衔接：若重发涉及已出具盖章评测报告的数据集，按评测方的复测口径安排复测，复测结论并入该数据集的质量档案。

留痕：冻结通知、重发申请与批准、差异清单、新旧版本对照、复测安排与结论。

表 1-12　五类情形的处置要素对照

五类情形的共同点是三条：处置动作都落在具体岗位上，不写「由相关部门协商确定」；处置过程都产生记录，记录既用于内部复核，也是贯标评审时「过程异常也在管理之内」的证据；对已发布数据集一律发新版本而不就地覆盖，使任何一份引用了版本号的评测结论与验证结论都不会因后续修订而失去依据。

1.6 决策数据指标体系与治理规划的时点绑定

招标文件要求在治理实施的同时构建决策数据指标体系，支撑高质量数据集建设并强化数据对经营管理决策的支撑能力（b1225、b1226）。这件事有一个容易被忽略的前后关系：指标体系的口径来自数据标准中的指标标准，指标标准的覆盖范围又取决于现状评估盘出的数据元与可得字段。换句话说，指标体系不能与治理规划并行起步，它必须排在标准与资产盘点之后。

本项目把这一关系固化为三个确认时点，写进治理规划的交付节点。表 1-13 逐时点给出完成内容、前置条件与下游依赖。时点的作用是给下游一个可依赖的日期：以决策指标为输入的场景验证按这三个时点排期，不以推定口径提前出结论。

表 1-13　决策数据指标体系的三个确认时点

三个时点落在治理规划的第二阶段，与「数据治理规划（二）」的阶段划分一致：指标标准与决策指标体系首批属第二阶段件。以决策指标为数据输入的通用场景验证据此排在场景序列的后段，口径未经确认的指标不以推定口径出验证结论。指标体系的指标选取方法、分层设计与首批规模估算在「数据治理规划（二）」的指标标准一节逐项给出，问答场景的交互设计在「五个通用场景验证方案」一节给出。

指标口径的确认进度是本项目的一项外部依赖。若某业务域的口径在计划时点未能会签，我方的做法是该域指标按草案口径标注「待确认」并暂不发布，相关场景的验证范围相应收窄并在验证报告中记录数据条件，而不是以项目组的推定口径替代业务口径对外出结论。

2、技术标准验证要求（3.2.6.7）

2.1 现行标准在矿山装备制造场景下的不适配

招标文件要求结合矿山装备制造行业特点与高质量数据集建设实践经验，积极参与全国数标委标准验证和试点应用工作，持续完善标准技术指标，提升行业标准的先进性、科学性与适用性（b1846、b1847）。采购清单第 5 项的第 2 条是同一要求（b0804r06）。

标准验证不是写一份标准建议书交上去。现行的高质量数据集相关标准多数是面向通用语料与通用模态制定的，落到矿山装备制造这个场景上会遇到几类具体的不适配：工艺图纸的符号表达（粗糙度、坡口、倒角、形位公差）在通用文档结构标准里没有对应的元素定义；设备时序数据的工况分段在通用时序数据规范里没有分段依据的约定；焊接参数流与焊道标识的时间窗对齐，其对齐容差在通用多模态对齐规范里没有可引用的取值范围。

这些不适配只有在真实加工上千万级样本时才会暴露出来，而本项目恰好要加工预训练 615 亿 Token、指令微调 89 万条、强化学习偏好 6.6 万组与基准测试 0.95 万条四类数据集，在加工过程中会形成大量可用于标准验证的实测数据。

我方参与标准验证的立足点就是这批实测数据与随之形成的作业规范，而不是概念性的意见。

2.2 参与方式与产出

表 2-1　技术标准验证的参与方式与产出

参与方式的落点在前三行。标准适用性验证与技术指标实测的依据是《高质量数据集质量评测规范》等现行评测依据，评测的指标体系、评测方法与实施过程在服务方案「数据集质量评测方案」一节论述；本节交付的是以该评测过程为载体的标准验证成果，两者是同一批作业的两种产出，不重复投入。

2.3 验证作业的实施流程、记录与质量控制

标准验证不另起一条作业线。四类数据集的加工与评测本身就是验证载体，验证作业挂在既有工序上：工序责任人在执行中发现某一条款无法执行或执行结果不可判定时，当场按统一模板登记一条标准适配问题，其余四步由标准岗与质量岗在既有的批次节奏上完成。

作业分五步。第一步，问题捕获。执行主体是采集、预处理、标注、合成、增强、质检、验证七个环节的工序责任人与评测环节的评测岗；输入是现行标准条款与本批次的真实数据对象；产出是一条标准适配问题记录。判定条件是记录中必须指明具体数据对象——指不出对象的，按意见登记而不进入验证流程。

第二步，复现与定级。执行主体是质量岗。输入是问题记录与该批次的全量样本；产出是复现范围、样本量与占比。定级分三档：一档为条款表述歧义，执行结果因人而异；二档为条款在本场景下缺少可引用的取值范围或判定方法；三档为条款与矿山装备制造的数据形态不适配，按条款执行会得到错误结论。三档均进入后续步骤，一档在建议中以澄清诉求提出，二档、三档以修订诉求提出。

第三步，实测取值。执行主体是质量岗，依据服务方案「数据集质量评测方案」确立的指标体系与评测方法，给出与该条款相关的实测值、统计口径与分布。不重复组织评测：取值取自同一批评测作业的中间结果，只是按标准条款重新归集一次。

第四步，修订建议成文。执行主体是项目组标准岗。输入是前三步的记录与实测值；产出是一条可被第三方按同一方法复算的修订建议，内容包含建议改什么、改后如何判定、支撑该判定的样本量与实测分布。判定条件是复算可行性：第三方拿到同样的数据与方法应当得到同一结论，做不到的退回第三步补实测。

第五步，复核与汇总。执行主体是项目组标准岗与甲方业务归口部门，双方对每条建议签署成立、不成立或证据不足待补三类结论之一；成立的进入半年度汇总件《标准适配问题与修订建议》，证据不足的退回补证据并记录退回次数，同一条退回两次仍无法补足的转为内部留存，不再提交。

一条建议能否成立，判据是证据而不是意见。支撑样本量低于 200 条、或在本项目范围内无法复现的，只登记不成建议；200 条是按基准测试数据集 0.95 万条的 2% 取的首批门限，首轮全量评测完成后按各模态的实际分布复核一次并相应调整。若某一模态的样本总量不足以支撑该门限，该模态的建议改以逐例说明的方式提出，并在建议中写明实际样本量与该样本量下结论的适用范围，不以不足量的样本给出普适结论。

记录用统一模板，字段与填写要求见表 2-2，不由各环节自拟格式——字段不统一，半年度汇总时就无法按标准条款归集。

表 2-2　标准适配问题记录的字段与填写要求

记录与汇总件进入治理文档体系统一编号与归档，并作为贯标评审中「过程被规范执行」的一类执行记录。记录的完整性按季度自查：抽取当季各环节的加工任务，核对该季度内发现的适配问题是否都有对应记录与去向，缺记录的补登记并倒查该环节的登记习惯。

2.4 组织分工与可检查的交付承诺

标准化工作的分工是确定的：标准的立项、起草、审查与发布由归口单位主导，参与单位提供实测证据与修订建议。我方在本项目中承担的正是后者——以四类数据集的真实加工与评测过程为载体，提供可复算的验证材料、实测数据与修订建议，并按标准化技术组织的工作安排参与试点应用。相关知识产权产出（论文、发明专利、软件著作权）的指标与安排在「技术创新与机制创新」一节论述（b0804r06）。

我方就此作出三项可被逐条检查的承诺：其一，在数据集加工过程中按统一模板记录标准适配问题，每条记录包含问题现象、涉及的标准条款、本项目的处理办法、建议的修订方向与支撑该建议的样本量；其二，每半年汇总一次形成《标准适配问题与修订建议》，经招标方确认后由招标方决定是否向归口单位提交；其三，若归口单位开展标准验证或试点应用工作并需要实测数据，在招标方同意且符合保密要求的前提下提供去敏后的验证数据与测试结论。

三项承诺的交付节点、产出形式与验收方式列入治理成果的交付口径（第 4 章），不单独计量工作量。之所以挂在半年度汇总上而不另设里程碑：标准验证的成效取决于归口单位的工作节奏，设为独立里程碑会让项目进度受制于外部环节，而半年度汇总既保证工作持续进行，又使进度可控。

3、数据标注规范建设要求（3.2.6.9）

3.1 需要解决的标注口径与流程问题

招标文件要求聚焦多模态数据高质量供给需求，制定覆盖不同数据类型的标准化、流程化标注规范，解决多模态数据标注口径不一、流程混乱、与业务场景适配性不足的问题（b1851、b1852）。采购清单第 5 项的第 4 条是同一要求（b0804r06）。

这三个问题在本项目的具体表现是可以指认的。口径不一：同一道备料工序在总工艺路线上叫一个名字、在车间卡片上叫另一个名字，28 道备料工序在不同系统中的名称差异若不先归一，标注出来的工序标签互相对不上。流程混乱：图纸与工艺卡的配对关系在甲方现状中未建立，约 63 万张历史工艺样本若没有配对规则就直接发给标注员，标注结果无法形成成对监督样本。与业务场景适配性不足：缺陷描述是自由文本，标注员按字面分类得到的标签与质量管理部门实际使用的缺陷类型对不上，标出来的数据场景侧用不了。

因此标注规范不能只写标注流程，它要先把标签体系的来源锁住——标签取自治理侧的参考数据码表与数据元标准，不由标注环节自创。这是本节把标注规范放在治理部分而不是加工部分的理由。

3.2 规范体系的构成

规范按一份总则加分册的结构组织，共十份，列入治理文档体系一并交付。

表 3-1　数据标注规范分册清单

十份分册中第 1、9、10 三份是跨模态的通用件，先行发布；第 2 至 8 份按数据集加工的批次顺序发布，与「数据治理规划（二）」第一阶段的标准发布节点对齐。各分册的编制、评审、发布与培训准入按第 3.3 节的六阶段口径执行。

3.3 规范的编制、评审与发布

十份规范不是一次写完再统一发布。总则与两份跨模态通用件先行，模态分册按数据集加工的批次顺序滚动发布，使每一批标注作业开工时都有已生效的规范可依。编制与发布按六个阶段推进，每个阶段的输入、承办、产出与通过条件事先写死，不通过的去向也一并写明。

需求输入阶段确定一件事：这一份分册要支撑哪些训练目标与哪些验证用例。输入有两路——四类数据集的数据卡对该模态提出的字段与标签要求，以及 11 个场景验证方案中反向落下来的能力点。两路需求合并成标注需求清单，逐条标明对应的数据子集与验证用例，不能对应到任何一条的需求退回提出方说明用途。这一步的意义在于把标签体系的来源锁死在下游用途上，避免出现标了一批用不上的标签、而场景要的标签没有标。

标签取数阶段只做一件事：把本分册要用的标签集从治理侧取出来。工序、物料、设备、测点、缺陷类型、故障类型等标签一律取自参考数据码表与主数据，术语取自业务术语标准，字段定义取自数据元标准。分册中出现的每一个标签都要能指回码表中的一行；指不回去的，先走码表的新增申请流程，申请通过后再写入分册。这一条是标注规范放在治理部分编制的直接原因，也是它与标注作业方法分开成件的分界线。

草案编制阶段产出分册草案，内容按总则规定的统一体例组织：适用范围、标签集与取值、标注粒度与判定规则、典型样例与边界样例、不可标注情形的判定、交付物格式与校验项、一致性要求与返工条件。样例必须取自本项目的真实数据对象，不用通用示意图；边界样例尤其要给足，标注员之间的分歧绝大多数出在边界上。

三道评审依次进行，三道都通过才发布。第一道由项目组内部评审，核体例完整性与可执行性——判据是一名未参与编制的标注员仅凭该分册能否独立完成一组试标。第二道由甲方业务归口部门评审，核标签体系与本域实际业务口径是否冲突——判据是标签集中的每一个取值在业务侧都有确定含义，且与该部门在用的分类不矛盾。第三道由管理层评审，确认责任分工、评审与变更的审批路径。任一道不通过的，退回草案编制阶段并记录不通过的具体条目与理由，修订后重新进入该道评审，不跳道。

发布与版本登记阶段由数据管理办公室执行：分册在治理平台上登记版本号与生效日期，标注任务创建时强制引用生效版本，未登记版本不可被引用。发布同时下发标签集到标注工具，使标注员在工具中只能从已发布标签集中选择。

培训与准入阶段是规范能不能落地的最后一关。标注员上岗前须通过本分册的培训与试标考核，试标样本由质量岗从真实数据中抽取并事先标定；试标结果与标定答案的一致率达到准入门限方可承接正式任务，未达门限的补训后重试，两次未达的不承接该模态的标注任务。分册发布新版本且涉及标签集或判定规则变更的，已上岗标注员须重新试标。

六个阶段的输入、承办与审批、产出、通过条件与不通过的去向汇总于表 3-2。

表 3-2　标注规范的编制与发布流程

3.4 规范的执行、检查与修订

规范发布之后要能被查出有没有被执行，否则它只是一份文件。执行、检查与修订三件事按下述口径固定下来。

执行靠平台约束而不是靠提醒。标注任务在创建时必须引用一个已生效的分册版本号，引用不到的任务创建不成功；标注工具中的标签集由平台从参考数据码表下发，标注员不能在工具中自建标签，确需新增的走码表新增申请，申请期间该样本挂起不强行归类。交付物的格式与必填校验项由工具按分册配置自动校验，校验不通过的批次不进入质检环节。这三条合起来构成标注环节的入口约束，与加工链路上其他环节的门控口径一致。

检查分三层。任务层由平台自动校验，对象是每一个标注任务，核的是规范版本引用、标签集合法性与交付物格式，频次是实时，不通过即阻断提交。批次层由质量岗按批抽检，对象是已提交的标注批次，核的是标注员之间的一致率与标注结果同业务口径的符合性，抽检比例按批次规模与该模态的历史一致率确定，低于门限的整批返工并提高下一批的抽检比例。周期层按季度由数据管理办公室组织规范执行情况检查，对象是当季全部标注作业，核的是规范版本是否及时更新、新增标签申请是否走完流程、返工记录与整改是否闭环，检查结论进治理执行记录。

一致性要求的量化口径以实测基线为准。首轮标注完成后按模态分别出具标注员间一致率基线，基线连同抽检方法写入项目质量计划，并作为返工条件的判定依据；此后各批次以逐步接近该基线之上的水平为目标，逐批记录实测值与基线的差距。某一模态连续两个批次低于基线的，处置按三档推进：先收紧——提高抽检比例并对分歧集中的标签补充边界样例；再隔离——该批次不进入发布版本，仅作内部复核；仍不达标的复议——由质量岗与业务归口部门共同复核该模态的标注粒度与标签划分是否本身不可操作，必要时修订分册而不是反复返工。

修订的触发条件写死四条：新增标签申请在同一分册上累积到一定数量，说明标签集覆盖不足；某一标签的一致率持续低于基线，说明判定规则表述不清；场景验证侧反馈某一标签不可用或粒度不合用；上游的参考数据码表、数据元标准或业务术语标准发生修订。四条中任一条成立即启动修订。修订稿走与编制阶段相同的三道评审，通过后发布新版本并登记版本差异；已按旧版本标注的数据按制度变更的影响分析流程处理——只是口径说明变化的更新数据卡中的规范版本号，需要重标的列入定向回流计划并按批次排期。

三层检查的对象、方法与频次、判定依据、不达标处置与留痕汇总于表 3-3。

表 3-3　标注规范执行情况的三层检查

三层检查的记录与标注规范本身一并归入治理文档体系，既用于标注质量的内部复核，也作为贯标评审中标注过程被规范执行的证据。标注粒度的具体取值、标注工序的组织、预标注与人工复核的配合方式在「数据加工生产（二）」一节给出，承载标注作业的四类标注工具链在「工具链二」一节给出，标注模板与样例在附录佐证卷提供。

4、治理成果的交付口径

4.1 七类交付物的合计口径

治理部分的交付物按七类归并，表 4-1 给出合计口径与分布。各成果物的章节骨架、验收口径与提交节点在两个子节的对应章节逐项给出。

表 4-1　治理成果的交付口径

治理文档的交付数量按「只增不减」执行：37 份是下限，实施中若某一主题需单独成文则增编并登记入引用关系表；拆分或合并须提交变更申请并保留与招标文件原清单的逐项对应关系，使验收时可逐行核对（b1334）。各份文档的全文按项目计划在相应阶段提交评审，投标阶段提交的是编制方案与模板样例。

4.2 三十七项规划成果的落地对应

一份治理文档交上去，怎么证明它不只是文本？本项目的答法是：每一项规划成果都要在治理平台上有对应的配置项，配置项运行起来产生对应的记录，记录又对应到数据集交付中的某一个环节。三者齐备，这份成果才算落了地。表 4-2 逐项给出这一对应关系，三十七项逐行可核。

表 4-2　三十七项规划成果与平台配置、运行记录、数据集交付的对应

这张表双向可用。验收时从左往右查：每一项规划成果都要能在平台上指出对应的配置与记录，指不出来的成果只是一份文本，不计入落地。实施时从右往左查：数据集交付过程中遇到的口径、权限或质量问题，都能回到某一项成果去修订，而不是在加工侧临时打补丁——临时补丁改的是单个批次，修订成果改的是此后所有批次。

三十七项的名称、形态、所属规划域与提交节点在「数据治理规划（二）」的治理规划文档交付清单中逐行列出，与本表同序，可并排核对。

5、前置条件与回退口径

两个子节已分别列出域内的前置条件与应对。站在总述一级，有三项条件对治理部分的整体节奏起决定作用，在此单列并给出回退口径。

表 5-1　治理部分的总述级前置条件

三项条件里前两项是进度变量，第三项是定级变量。本节的处理方式是把它们写成前提而不是隐含假设，并给出过渡办法与可重新核算的口径，使治理进度、数据集规模与贯标时点之间的关系在前提变化时可被重新计算，而不是在交付时才发现差距。