负责人 中移动　·　状态 定稿　·　覆盖 122 个标书单元　·　 批注 7

1、数据集运营服务管理平台建设要求（3.2.4）

1.1　平台职能定位、总体架构与功能模块构成

1.1.1　平台承担的运营管理职能与职能分界

天地奔牛的数据资源具备支撑高质量数据集建设的条件：生产业务数据留存完整，十年前生产了哪个矿的哪些产品都可追溯；历史图纸约 63 万张，且每张图纸在历史上都配有一张已审核签发的工艺卡片，天然构成成对的监督样本；板材备料的工序集合固定封闭，现掌握口径为 28 道。这些资源分布在产品全生命周期管理、企业资源计划、制造执行、质量管理等十余套系统与大量纸质记录中，其权属归属、使用授权与收益归集尚无统一承载。

数据集运营服务管理平台承担的正是这一层职能：支撑高质量数据集面向企业内部应用与对外流通交易的全生命周期运营管理（b1159、b1160），使四类数据集从一批文件成为可挂牌、可申请、可交付、可结算、可追查的数据资产。平台覆盖七类核心能力——数据及服务管理、订单管理、数据及服务交付管理、清算管理、审计管理、运营平台服务和 SLA 保障、对外接口——分属三层职责：前五类承载一笔交易从登记到结算的完整履约链路，第六类承载服务水平的监测与考核，第七类承载数据集走出企业之后的对外对接。三层共用同一套登记记录、同一套授权来源与同一套审计流水，不另设并行台账。

数据集的生产在加工生产平台完成，运营平台不重复承担生产职能。按招标文件 3.2.6.3 节的要求，加工生产侧须「完成数据集向数据集运营服务管理平台的移交与登记，支撑其后续的挂牌展示、对外发布与接入国家数据基础设施」（b1575、b1576）。移交物为数据集内容、数据集卡片、版本指纹、质检报告与验证报告五项，合称移交五件套；这五项同时是运营平台登记注册环节的受理前提，五项不齐的版本在受理处即退回，不进入审批队列。

运营平台与平台之外各侧的职能分界如表 2.4-1。分界的判据是「谁对这件事的结果负责」，而不是「谁的系统里有这个界面」；每一行同时写明两侧之间凭什么交接，交接物即是责任转移的凭证。

表 2.4-1　运营平台与平台之外各侧的职能分界与交接物。数据来源：招标文件 3.2.4、3.2.6.3、3.2.6.6 节。

1.1.2　平台在项目中的位置与数据流向

数据集运营服务管理平台是奔牛数据智能平台中承载数据资产运营的组成部分，部署在天地奔牛内网，通过接入连接器与外部可信流通环境对接。它在本项目中的位置与数据流向如图 2.4-1。

图 2.4-1　运营平台的数据流向与责任边界

图 2.4-1　运营平台的数据流向与责任边界。数据来源：招标文件 3.2.4 节（b1160）、3.2.6.3 节（b1575、b1576）、3.1.1 软件采购清单（b0692r02）。

图中三条横向边界值得特别说明。加工生产侧向运营平台移交的是「已完成质检与验证的正式版本」，不是中间产物；运营平台不接收未出具质检报告与验证报告的数据集版本，这条规则在登记注册环节由系统校验而非人工把关。对外一侧，企业内部用户走内网直连，外部用户的一切访问都经接入连接器落地，运营平台不向互联网直接暴露服务端口。两侧之间的审计记录是连续的：一条数据集从移交登记到被某个外部用户下载，中间每一次状态变更都落在同一条审计链上。

1.1.3　平台设计的三项取舍

第一，先把权属与版本钉住，再谈交易。 数据集交易出问题，九成不是因为交易流程不够花哨，而是因为事后说不清「这份数据当时是哪个版本、来源是什么、谁批准可以对外」。所以本平台把登记注册、数据集确权、版本管理三个模块设计为交易链路的强制前置：未完成确权登记的数据集可以存在于平台上，但进入不了挂牌展示，也生成不了订单。这个设计会让上架慢一些，换来的是争议处理时有据可查。

第二，交付方式由数据属性决定，而不是由用户偏好决定。 同一份数据集，作为训练语料整包下载、作为检索服务按次调用、作为加工任务由平台代为执行，三种方式的风险完全不同。整包下载后数据脱离平台控制，按次调用则数据不出域。平台在数据集注册时就要求提供方指定允许的交付方式，并把它作为一项可审批、可变更的属性管理起来（b1179）。

第三，SLA 指标只承诺能被平台自己测出来的量。 平台服务质量报告由平台自动生成（b1204），指标口径与采集点在 1.7 节逐项写明。凡是需要人工统计才能得出的「满意度」类指标，我方按季度抽样调查口径处理，不混入自动化 SLA 考核，避免考核数据的来源说不清。

1.1.4　平台总体架构分层

平台采用四层架构。自下而上为资源与安全层、数据与资产层、运营能力层、服务与接入层。分层的依据是变更频率：资源与安全层随信创与国密政策演进，数据与资产层随数据集版本演进，运营能力层随运营机制调整，服务与接入层随对外接口规范演进。四层各自可以独立升级，这是平台能用到 2028 年之后的前提。

图 2.4-2　运营平台总体技术架构

图 2.4-2　运营平台总体技术架构。数据来源：招标文件 3.2.4 节能力划分（b1160）、3.1.1 软件采购清单（b0692r02）、3.2.1 服务采购清单（b0804r04、b0804r05）。

架构中有一处设计需要点明：数据集内容与交易数据物理分离。数据集内容存放在对象存储，交易、订单、清算数据存放在关系库，两者之间只通过数据集版本标识关联。这样做的直接好处是，交付一笔订单时平台不需要移动数据集本体，只在存储侧生成受控副本或开放一条只读通道，交付动作本身的耗时与数据集体积基本无关。预训练数据集按本项目口径合计 615 亿 Token，若每笔订单都复制一份完整内容，交付时效无法承诺。

存证账本只记录关键事实的摘要，不记录数据集内容。登记、确权、挂牌、订单成立、交付完成、清算完成六类事实在发生时写入账本，写入内容为事实摘要与版本指纹的哈希值，用于事后比对记录是否被篡改。这项能力与接入连接器要求的区块链存证功能对齐（见硬件分节 b2150r03）。

1.1.5　七类能力域与功能模块的对应关系

招标文件 3.2.4 节要求的能力域共七类（b1160），服务采购清单实列功能模块 16 项（b0804r04），两者是「能力域—实现模块」的关系而非并列关系。数量口径在全节统一为一句话：采购清单实列的 16 项模块全部交付，不增不减；3.2.4.6 节要求的平台服务与 SLA 保障能力（b1198）在清单 16 项之外另以 1 个模块承载；16 项清单模块与 1 项增列模块合计 17 个交付模块，满足「不少于 14 个功能模块」的要求并留有余量。增列模块与清单 16 项之间是监测与保障关系而非并列关系，逐项映射见 1.1.8 节。能力域与模块的对应关系如表 2.4-2。

表 2.4-2　七类能力域与功能模块的对应关系。数据来源：招标文件 b1160、b0804r04、b1198。前五行与第七行为采购清单实列的 16 项模块按能力域归位，其中交易费用管理模块同时服务订单与清算两个能力域，在表中出现两次而实际交付一个模块，故六行合计 16 项；第六行「平台服务与 SLA 保障」为清单之外增列的 1 项。16 ＋ 1 ＝ 17 个交付模块。

1.1.6　功能模块清单：采购清单 16 项与增列 1 项

这张表要回答的是交付清单层面的问题：平台建成后点得开、用得上的功能模块究竟是哪些，能否与服务采购清单的条目逐条对上。模块名称逐字沿用采购清单的条目名，不合并、不拆分、不另起新名，甲方核对时无须在两套叫法之间做一次翻译；核心功能要点由对应的功能要求条款收敛而来，取舍标准是写进要点的每一项在验收时都应点得开一个页面或取得出一条记录。

表中三列各管一事。「功能模块」列与采购清单逐条对齐，是核对有无遗漏的判据；「回应单元」列是证据，1 至 16 行回指服务采购清单与各自的功能要求条款，第 17 行回指 3.2.4.6 节；「核心功能要点」列给出验收着眼点，完整规格在 1.1.7 节按十一项展开。其中第 11 行数据集服务是数据集转为可调用服务的出口，服务目录、计量与计费均挂在其下；第 17 行不与前十六行并列，而是对它们的运行状态做监测与披露。

交付数量据此定下：16 项清单模块为基线，增列 1 项后合计 17 项，较「不少于 14 个功能模块」留有余量；实施阶段如甲方对模块范围另有调整，经书面变更确认后增减，调整后总数仍不低于 14 项。

表 2.4-3　功能模块清单。数据来源：招标文件 b0804r04（实列 16 项）、b1160、b1198。序号 1—16 为服务采购清单实列模块，逐项对应清单条目；序号 17 为清单之外增列模块，用于承载 3.2.4.6 节的平台服务与 SLA 保障能力，其对清单 16 项的监测映射见 1.1.8 节表 2.4-3E。

1.1.7　采购清单 16 项模块的功能规格

招标文件服务采购清单实列的 16 项功能模块（b0804r04）在本节逐项给出可验收的功能规格。规格按十一项写定：使用角色、菜单页面、关键字段、对象状态、业务动作、校验规则、权限控制、数据来源、输出物、典型异常与处置、验收用例。十一项按四张表分列，同一序号在四表中指同一模块；各模块的业务论述见 1.2 至 1.8 节对应各节。增列的第 17 项模块不在本节四表之内，其与 16 项的映射见 1.1.8 节。

表 2.4-3A　16 项模块的使用角色、菜单页面与数据来源。数据来源：招标文件 b0804r04 服务采购清单实列模块、b1161—b1206 各功能要求条款。菜单页面为平台导航层级，实施阶段按用户习惯微调而不改变功能归属。

表 2.4-3B　16 项模块的关键字段与对象状态。数据来源：招标文件 b1161—b1206 各功能要求条款；元数据项分组见表 2.4-5，授权操作七类见 1.4.6 节。

表 2.4-3C　16 项模块的业务动作、校验规则与权限控制。数据来源：招标文件 b1161—b1206 各功能要求条款、b1182 与 b1183（授权与配额）、b1192—b1197（审计）。

表 2.4-3D　16 项模块的输出物、典型异常与验收用例。数据来源：招标文件 b1161—b1206 各功能要求条款；验收用例与 1.9.3 节的验收口径同源，可直接用作上线验收的测试脚本。

1.1.8　增列模块与采购清单 16 项的映射

3.2.4.6 节要求的平台服务与 SLA 保障能力（b1198—b1204）是一项横向能力：它本身不产生数据集、不成立订单，而是对上述 16 项模块的运行状态进行监测、判定、告警与披露。把它并入 16 项中的任何一项都会使那一项的职责不清，故单列为第 17 个交付模块；它与 16 项之间是监测与保障关系，逐项映射如表 2.4-3E。这张映射表同时是 SLA 指标的采集点清单：表 2.4-17 的七项核心指标，其数据全部来自本表所列的采集点。

表 2.4-3E　增列模块对采购清单 16 项模块的监测映射与采集点。数据来源：招标文件 b1198—b1204（平台服务与 SLA 保障）、b0804r04（清单 16 项）。核心指标的计算口径与承诺值见表 2.4-17。

1.1.9　角色与租户模型

平台的使用者分五类角色，权限边界各不相同。这个划分决定了后面所有流程的审批链条，先在此说明一次，后文不再重复。

表 2.4-4　平台角色与权限边界。数据来源：招标文件 b1165、b1166、b1182、b1183、b1194、b1195。

租户采用两级模型。一级租户对应法人主体，二级租户对应该主体下的部门或项目组。配额、计费、授权均可按任一级别设定，继承关系为一级设上限、二级在上限内分配。这一模型同时服务于平台能力交付场景（b1182、b1183）：外部用户购买平台加工能力时，平台为其开通一个一级租户，授权范围与资源配额在开通时一次配置完成。

1.1.10　技术选型口径

平台基于国产化软硬件栈建设，运行于国产 CPU 与国产操作系统，数据库、中间件、容器平台均采用已通过信创适配认证的产品。密码运算统一调用商用密码服务平台提供的服务，不在应用内自行实现密码算法（b0692r02、b0694 口径）。具体的国产化比例承诺与适配清单见非功能分节与安全分节。

平台在数据集服务模块中需要调用大模型能力，用于语义检索、样本摘要与质量问答。我方采用当期能力评测领先的通用大模型，经统一网关接入，可替换、可评测、可随代升级。网关层记录每一次模型调用的输入输出摘要与耗时，计入 API 调用审计。模型能力的更替不改变平台对外接口，这是把模型置于网关之后的原因。

1.2　数据及服务管理功能要求（3.2.4.1）

数据及服务管理是平台运营的入口能力，由登记注册、数据集确权、数据集目录、数据集元数据、数据集上传、数据集检索与预览、数据集版本管理、数据集动态更新、数据集挂牌展示 9 个功能模块承担，支持数据及服务的注册、审批、发布、变更和下架（b1161、b1162）。

1.2.1　五个动作的状态流转与准入条件

平台把注册、审批、发布、变更、下架五个动作实现为受控状态之间的迁移（b1162）。数据集版本与服务实例在平台内始终处于草稿、待受理、审批中、已发布、变更中、停售保留、已下架七个状态之一，每一次迁移有明确的准入条件、执行角色与产出凭证；准入条件不满足即不迁移，迁移前后的状态值与依据单据号写入审计（见 1.6.2 节数据集生命周期事件）。

准入条件按动作分别设定。草稿迁入待受理，须通过字段级、文件级、凭证级三道完整性校验（见 1.2.3 节）；待受理迁入审批中，须移交五件套齐备且版本指纹重算一致；审批中迁入已发布，须价值、质量、安全合规、可运营四个维度均出具结论且安全合规维度无否决项，并完成确权登记、目录归类与挂牌信息编排三件事（见 1.2.4 节、1.2.5 节）；已发布迁入变更中按变更类型分流，元数据变更原地留痕、内容变更派生新版本并重走注册与审批；迁入停售保留或已下架，按六类下架情形各自的触发方、核验项与在途订单处置执行（见 1.2.6 节）。执行角色按 1.1.9 节的五类角色划分，提供方不可自行发布，运营管理员不可越过审批结论上架。

登记记录是后续订单、交付与清算的唯一基准：订单锁定的版本、交付生成的授权、清算引用的权属份额，均取自登记记录而不另行录入。因此入口环节设置的是准入校验而非事后修正——登记信息一旦被交易记录引用，更正须经冲销原记录与重新登记两步，并在审计中留下两条关联记录。

1.2.2　注册对象与注册信息

平台支持两类对象注册：数据集与数据服务（b1163）。数据集的注册单位是版本，不是数据集本身——同一个数据集的 v1.2 与 v1.3 是两条可独立挂牌、独立定价、独立下架的记录，它们通过版本树关联。数据服务的注册单位是服务实例，一个服务实例绑定一个或多个数据集版本。

在线注册须录入的信息按招标文件要求覆盖名称、类型、提供方、描述四项（b1163），我方在此基础上按五组元数据组织，便于后续检索、审批与定价都有据可依。

表 2.4-5　注册元数据项分组。数据来源：招标文件 b1163、b1164、b1166、b1569、b1570、b1793。完整元数据标准清单作为治理文档交付，见数据治理分节。

1.2.3　注册信息的完整性校验

招标文件明确要求「运营平台须支持完整性校验」（b1164）。我方把完整性校验设计为三道，依次执行，任一道不通过即退回提供方并给出具体缺项，不进入审批队列。

第一道是字段级校验。必填项为空、枚举值不在字典内、数值超出合理区间、日期逻辑矛盾，由系统即时提示。这一道在表单填写过程中实时执行，提交前即可发现。

第二道是文件级校验。平台比对上传包的实际结构与声明的结构：声明的文件数与实际文件数是否一致，数据字典文件与自描述封装文件是否存在且可被解析，样本抽样读取是否成功，版本指纹重算结果与声明值是否一致。指纹不一致意味着内容在移交途中发生变化，此类情形直接退回而不是提示修改。

第三道是凭证级校验。质检报告编号与验证报告编号须能在平台内被检索到对应报告，且报告结论为通过；权属主体须有对应的确权记录或在同一次注册中一并提交确权材料。这一道是前面提到的强制前置：没有质检与验证凭证的版本进不了审批（b1575、b1576 的承接）。

三道校验的通过率是一项运营指标。招标文件对完整性校验只给了定性要求（b1164），未给量值，该门限因此由我方设立：首期上线阶段按「一次提交通过率不低于 70%」设定基线，上线三个月后按实际退回原因分布优化表单与字典，目标逐步接近 90%。全卷量值的取法在本节同样适用——招标文件给定量值的，取条款值本身，口径不改写、量值不下调；条款未给量值的，由我方设立并列明设立依据。门限见表 2.4-5A，测法见表 2.4-5B，两表就同一项指标前后对齐：前者定数，后者定怎么测、多久测一次、不达标怎么办。只写到门限为止等于只承诺了好结果，第一次不达标时双方无章可循，故两表须同时成立。

表 2.4-5A　一次提交完整性校验通过率的门限。数据来源：招标文件 b1164（完整性校验要求，未给量值）；承诺值与设计值由我方设立，设立依据见本表末列，属对招标要求的补充量化，不替代、不改写招标文件的任何一条要求。

表 2.4-5B　一次提交完整性校验通过率的测法。数据来源：招标文件 b1164（完整性校验要求）、b1201—b1204（服务质量报告与统计周期）；方法、频次、公式、阈值与处置口径为本节承诺值，与表 2.4-17 及 1.5 节对账完成率同口径，未另立采集点与统计周期。

表 2.4-5A 的两个量值是我方自设的运营目标；上线后的实测结果用于驱动表单与字典的优化，不用于回调量值本身。样本量下限与「连续两个统计周期」均为测法参数，约束的是何时才足以判定达标与否，不构成新增的性能承诺。

图 2.4-3　数据集注册与审批流程（泳道）

图 2.4-3　数据集注册与审批流程。数据来源：招标文件 b1162—b1169、b1793。

1.2.4　多维度审批

招标文件要求审批「须支持多维度审批」，并点明四个维度：价值、质量、安全合规性和可运营（b1165、b1166）。这四个维度不是四个形容词，我方把每一维度落到可判断的评审项与判据。

表 2.4-6　四维度审批评审项与判据。数据来源：招标文件 b1165、b1166、b0804r06 第 7 项（安全合规建设要求）。质量门槛的具体数值以数据集质量评测分节设定的三维度门槛值为准。

审批的组织方式按数据集的对外开放程度分两档，兼顾灵活性与规范性。仅在企业内部使用、且提供方为天地奔牛内部部门的数据集，走简化审批：质量与安全合规两个维度必审，价值与可运营维度由运营管理员书面确认即可，审批时限按 2 个工作日。拟对外挂牌、或提供方为外部主体的数据集，走完整审批：四个维度各自独立评审，安全合规维度一票否决，审批时限按 5 个工作日。两档之间可由运营管理员升档，不可降档。

审批意见按维度分列保存，不生成汇总性结论。这样做的原因是：退回之后提供方需要知道究竟是哪一维度不通过、具体缺什么，一个「综合评议不通过」的结论没有可操作性。审批记录随数据集版本永久保存，后续版本的审批可引用上一版本的意见作为对照。

1.2.5　发布与变更

发布是把审批通过的数据集版本推到可被检索、可被下单的状态，由运营管理员执行，执行前须完成三件事：确权登记已落账、目录归类已挂接、挂牌信息已编排（见图 2.4-3 第四泳道）。发布动作支持定时发布，用于对外发布需要与宣传节奏配合的情形。

变更分两类，处置方式不同。元数据变更不改变数据集内容，包括描述、关键词、适用场景、联系渠道、价格与许可条款的调整。其中价格与许可条款的变更须经可运营与安全合规维度重新确认，其余项由提供方自助修改并留痕。内容变更必然产生新版本，走完整的注册与审批流程，原版本可选择保留在售、停售但保留历史取回、或下架三种处置。

变更对已成立订单的影响有明确规则：订单成立时锁定的是具体版本与当时的许可条款，后续变更不回溯影响已成立订单；若变更涉及安全合规事由，平台可依据审计与合规判定对已交付订单发起召回通知，这一情形在交易合同条款中事先约定。

1.2.6　下架

招标文件要求下架功能「满足运营过程中各种原因导致的下架需求」（b1167、b1168）。我方梳理六类下架情形并分别给出处置口径。

表 2.4-7　六类下架情形与处置口径。数据来源：招标文件 b1167、b1168、b0804r06 第 7 项。退款与召回的具体条款以交易合同管理模块的合同模板约定为准。

下架不等于删除。下架后数据集版本、元数据、审批记录、交易记录与审计日志全部保留，仅对外通道关闭。这是审计与争议处理的需要（b1196）。确有删除需求时走单独的数据销毁流程，须经审批并留销毁记录。

1.2.7　数据集目录与元数据模块

目录采用双视图。业务域视图按供需计划、产品工艺设计、制造过程、产品质量四类数据集组织，每类下按预训练、有监督指令微调、人类偏好对齐、基准评测四个用途子集展开；场景视图按本项目的细分任务场景组织，一个数据集版本可同时挂在多个场景节点下。双视图的必要性来自两类用户的检索习惯不同：企业内部的数据工程人员按数据集大类找，业务部门与外部用户按场景找。

目录节点编码预留国家数据基础设施的统一目录标识位（b1206）。编码结构为「行业域—企业主体—数据集大类—用途子集—版本序号」五段，各段长度固定，便于与外部目录标识做映射而不必改写既有编码。

元数据模块承载表 2.4-5 的五组元数据项，并提供三项能力：元数据标准的版本化维护，使字典调整可追溯；元数据批量导入导出，用于首期大批量数据集上架；元数据质量巡检，按月统计必填项缺失率、枚举值异常率、与质检报告不一致项数，生成巡检清单交运营管理员处理。

1.2.8　数据集上传与下载模块

上传模块面对的实际约束是数据集体积。按本项目口径，预训练数据集合计 615 亿 Token，指令微调 89 万条，强化学习偏好数据 6.6 万组，基准测试 0.95 万条；其中产品工艺设计数据集涉及 63 万张历史图纸及其配对工艺卡片，文件数量级在百万。

因此上传模块按分片上传、断点续传、并发分片、分片级校验设计，单次上传任务支持中断后从已完成分片继续，不要求重传整包。对于体积超过在线上传合理区间的首期历史数据，平台提供离线导入通道：由加工生产侧生成标准包与清单，经内网存储直接挂载，平台执行与在线上传相同的三道完整性校验后入库。

下载模块的设计重点不是速度而是可追溯。每一次下载生成一张下载凭证，记录下载人、租户、订单号、数据集版本、下载范围、时间、源地址与下载包指纹。下载包内嵌不可见水印与一份交付清单文件，清单列明版本指纹、许可条款、允许用途与适用边界。整包下载之外支持子集下载，子集范围由订单授权决定，常见场景是用户只购买某一业务域或某一时间区间的样本。

下载次数与并发按订单与租户配额控制。配额用尽时下载入口关闭并提示联系运营管理员，不做自动放行。

1.2.9　数据集检索与预览模块

检索提供三种方式并存。一是元数据组合检索，按数据集大类、用途子集、模态、时间跨度、业务域、质量得分区间等条件筛选，适合知道自己要什么的用户。二是关键词全文检索，检索范围覆盖数据集名称、描述、关键词、适用场景与数据字典的字段说明。三是语义检索，用户以自然语言描述需求，平台返回相关数据集并给出相关性说明。语义检索由数据集服务模块调用统一网关后的大模型实现，检索结果附带命中依据，便于用户判断是否误召。

预览的核心约束是「让用户看清但不让数据流出」。我方的预览设计分三层：元数据预览对所有已挂牌数据集开放，内容包括表 2.4-5 中除技术信息外的全部项；样本预览按数据集类型提供固定条数的受控样本，文本类按条、图像类按张、时序类按窗口，样本在挂牌时由提供方指定或由平台随机抽取后经安全合规确认；结构预览提供数据字典与自描述封装文件的在线查看，使用户在不取得样本的情况下也能判断字段是否满足需要。

样本预览经脱敏处理，脱敏规则按数据集的敏感判定结论配置。预览不提供下载、不提供复制全文、不提供批量翻页，单用户单数据集的预览次数计入配额并入审计。

1.2.10　数据集版本管理与动态更新模块

版本管理模块维护版本树。每个版本记录版本号、版本指纹、父版本、变更说明、质检与验证报告编号、挂牌状态、在售起止时间。版本差异说明由提供方在注册时填写，内容要求写明三件事：样本范围的增减、标注口径的调整、已知缺陷的修复情况。这三件事决定了已购买上一版本的用户是否需要升级。

历史版本的留存期按许可与审计要求设定，默认不少于项目质保期结束后 3 年。留存期内原购买主体可申请取回历史版本。取回不是对「曾经购买」这一事实的自动兑现：平台在开放取回通道前重新核验四项，四项全部通过方可开放，任一项不通过即不予开放并书面告知具体事由。

第一项是授权有效性。核验原订单是否仍在有效期内、原授权是否已被回收或冻结、申请主体是否仍为原购买主体；主体发生合并、分立或注销的，按权利承继材料重新认定，认定不成立的不予取回。第二项是许可期限。核验该版本的许可条款在取回之日是否仍在许可期内，以及原订单约定的使用期限是否已届满；许可期已过或使用期限已届满的不予取回，用户可按当期挂牌条件重新订购。第三项是安全限制。核验该版本当前的敏感判定结论、脱敏要求与允许交付方式较原交付时是否发生变化，发生变化的按当前结论重新界定取回范围与交付方式，而不按原范围照发。第四项是下架事由。因质量问题或合规事由下架的版本，取回不予开放；因版本迭代替换或提供方主动下架而转入停售保留的版本，按前三项核验结论决定是否开放。

核验通过后，取回走订单链路生成一笔零金额订单，由该订单派生新的授权记录与新的下载凭证，授权范围、有效期与配额按本次核验结论重新设定，不沿用原订单的授权记录。取回申请、四项核验结论、开放或拒绝的决定与依据，连同取回动作本身全部入审计。

动态更新模块承接数据持续汇聚的产出（见 2.1 节），负责把增量数据并入既有数据集。更新有两种形态：增量追加不改变既有样本，产生小版本号；重标与修订改变既有样本，产生大版本号并需重新质检。更新计划按数据集设定窗口，默认按季度，高时效性数据集可设为按月。每次更新完成后，平台向订阅该数据集的用户推送更新通知，通知内容包括变更范围、是否影响既有样本、是否建议升级。

1.2.11　数据集确权与挂牌展示模块

确权模块记录四类事实：来源凭证、权属主体、许可条款、流转记录。来源凭证指数据的原始出处与取得依据，对企业内部数据为系统取数授权记录，对外部汇聚数据为数据提供协议编号。权属主体登记到法人层级，多方共有的数据集登记各方份额与收益分配约定，该约定直接作为清算规则的输入（见 1.5 节）。许可条款从平台提供的许可模板中选择或在模板基础上加附加条款，模板覆盖内部使用、行业公益开放、商业授权、定制开发四类。

权属争议有专门的处置通道。任何用户可对已挂牌数据集提出权属异议，异议受理后该版本转入争议标记状态，挂牌暂停，在途订单中止，相关清算暂挂。争议结论由运营组织的专业把关层出具（见 2.5 节），结论与处置过程全程留痕。

挂牌展示模块负责对外呈现。挂牌页面的内容结构为五块：数据集概览与价值说明、规模与模态构成、质量结论摘要与适用边界、许可条款与允许用途、价格与交付方式。其中质量结论摘要与适用边界必须展示，不允许只展示优点。这是我方的一项运营规则：适用边界披露不充分的数据集，使用方拿去训练出问题后的争议成本远高于多卖一笔的收益。

图 2.4-4　数据集目录与挂牌展示界面示意

图 2.4-4　数据集目录与挂牌展示界面示意。数据来源：招标文件 b0804r04 模块清单、b1160、b1569、b1570；数据集规模取本项目产品工艺设计数据集指令微调子集口径 10 万条，备料工序 28 道。图中标注「示意」的质量得分与更新时间为界面占位样式，实际取值由数据集质量评测报告与更新任务记录写入。

1.2.12　数据集服务模块

数据集服务模块把数据集封装为可直接调用的能力，它是任务式使用与定制化数据服务的承载模块。平台提供四类服务封装。

检索服务把数据集封装为按条件返回样本的接口，调用方按次计费，数据不出域。问答服务在数据集之上提供自然语言问答，返回答案与出处样本标识，适用于标准、规程、制度类语料。评测服务接收调用方提交的模型接口地址，用基准评测数据集对其打分并返回评测报告，调用方的模型不进入平台、平台的基准答案不出平台，这是基准数据集防泄露的交付方式。加工任务服务接收调用方提交的原始数据与加工要求，由平台调用专项智能工具链执行加工并返回成果，工具链本身不对外交付（工具链清单与能力见本投标文件工具链分节）。

四类服务共用同一套配额、计费、审计机制，在用户侧表现为同一种订购与调用方式。服务的技术参数与可用性承诺进入 SLA 体系（见 1.7 节）。

1.2.13　智能体开发服务的供给形态与服务目录登记

招标文件在数据集运营架构建设要求中写明「须面向行业用户提供定制化的数据服务与智能体开发服务」（b1811），并要求整合各相关方在数据采集、数据标注、模型训练、智能体开发、数据集评测等环节的专业能力实施专业服务（b1809、b1810），同时「须明确架构中各相关方的服务边界、协作接口与质量责任」（b1812）。这三条要求在运营架构层面的组织方式见 2.3 节；在平台层面，智能体开发服务以一个服务目录条目的形态存在，其登记模块、目录展示方式与条目字段如下。

这项服务挂在数据集服务模块之下，不新增功能模块，1.1.6 节的 17 个模块清单不变。挂法上与 1.2.12 节的四类服务封装有一处区别需要先讲清。检索、问答、评测、加工任务四类是标准化的可调用服务，用户订购后按接口调用；智能体开发服务是定制类服务条目，它在服务目录中与四类标准服务并列展示、并列检索、并列下单，但供给形态是按需承做而不是接口调用，下单后进入 2.3.4 节的五步定制流程。两类条目放进同一本服务目录，是因为用户只需要在一个地方找服务；供给形态在条目上标明，是因为用户在下单前就该知道自己拿到的是接口还是交付物。

服务目录对每一个条目登记十四项字段。标准类条目的部分字段可留空，定制类条目则十四项必填——条目信息不全就无法让用户在下单前判断这项服务能不能用、用得起用不起。字段设计与本条目的登记口径如表 2.4-7A。

表 2.4-7A　服务目录条目字段与智能体开发服务的登记口径。数据来源：招标文件 b1809、b1810、b1811、b1812；服务分层与计费口径依据 b1817、b1819。条目上的「交付物形态」只登记类型清单，数量与效果指标不在目录层面登记，理由见下文第二条边界。

本条目的服务边界有三条，写在条目上并随服务说明一同对用户展示。第一条是范围边界：本包的建设范围是数据集加工生产、质量评测与场景验证，智能场景建设不在本包范围内（b0804r06）；服务目录中的本条目是运营期面向行业用户的服务供给能力，与本项目建设期内的场景建设责任是两件事。

第二条是承诺边界：条目登记的是能力、输入要求、交付物类型与验收方式，具体交付物清单、数量与效果指标由每一笔定制合同逐项约定，不在服务目录层面作数量承诺或效果承诺——目录是用来让用户找到服务并判断是否合用的，不是用来预先替未签的合同下结论的。第三条是技术边界：本条目所需的模型能力按 1.1.10 节的口径经统一网关接入，可替换、可评测、可随代升级，模型能力的更替不改变本条目的服务边界与验收口径。

协作接口的通用规则——服务边界按交付物划分、交接按交接单落地、交接单在平台留痕——见 2.3.5 节。本条目在通用规则之外另设四个接口点，每个接口点在条目上登记交接物、交出方、接收方与接收检查不通过时的处置，并随服务说明对用户展示。四个接口点的设置依据是定制服务受阻位置的实际分布：需求要素不全、授权范围不足、验收判据未确认、运行期问题无人认领，四类情形占受阻工单的绝大多数。四个接口点如表 2.4-7B。

表 2.4-7B　智能体开发服务条目的协作接口点与接收检查口径。数据来源：招标文件 b1812（服务边界、协作接口与质量责任）、b1182、b1183（授权与配额）、b1199—b1204（服务分级与 SLA）。

质量责任按「谁的交付物谁负责」确定，这一总则见 2.3.5 节。本条目另有三条补充规则。一是数据集本身的质量责任在平台侧，以数据集质量评测报告为依据；用户基于该数据集作出的业务判断，责任在用户侧。二是交付物按合同约定的验收标准逐项验收，验收标准中的业务判据由用户在方案设计阶段确认，未经确认的业务判据不作为验收依据。三是模型能力随代升级不构成对已验收交付物的再次承诺，用户要求按新一代模型能力重做的，作为一笔新的定制需求受理。

本条目的度量项为三项过程时效：受理反馈时效、方案提交时效、节点交付及时率。三项的交付物验收以合同约定的逐项判据与人工确认为准，不以自动化率一类的加工侧指标替代。三项的计算口径、采集点、承诺值与趋向目标如表 2.4-7C，三项均按 1.7 节的 SLA 体系纳管，数据源唯一取平台工单与订单的时间戳，人工统计的数不进这三项。

表 2.4-7C　智能体开发服务条目的三项过程时效。数据来源：招标文件 b1201—b1204（SLA 核心指标与服务质量报告）、b1812（质量责任）。承诺值为运营侧对外承诺口径，与表 2.4-17 同采集点、同统计周期。

表中承诺值与趋向目标属对外承诺，签约后按合同约定考核，其取值不随上线后的实测结果回调。与之分开的是两项实施校准参数：一是工作时长所依据的工作日历，在实施阶段按甲方生产日历确认，确认前按法定工作日历计算；二是用户致因延误的剔除判据，在服务级别协议附件中逐条细化，细化前按表 2.4-17 下文的剔除口径执行。校准参数只影响统计口径的细化，不改变承诺值本身。三项指标未达成时按表 2.4-17 的未达成处置执行，并在服务质量报告中逐项披露归因与改进措施（b1204）。

1.2.14　从登记到撤回的全流程与四类凭证的一致性检查

前十二节逐模块写了各自的设计。一份数据集在平台内的实际走法是跨模块的：登记、版本、挂牌、授权、订单、交付、反馈、撤回八个环节首尾相接，每个环节的准入条件由上一环节的产出决定。八个环节的触发条件、前置校验、状态迁移、产出留痕与审计事件如表 2.4-7D。表中「前置校验不通过」一律是「停在本环节」，不是「带病进入下一环节」。

表 2.4-7D　数据集从登记到撤回的八环节全流程。数据来源：招标文件 b1162（五个动作）、b1167、b1168（下架）、b1171（订单全过程）、b1175、b1176（交付）、b1184（线下验收与评价）、b1192—b1197（审计）。一致性检查各项见表 2.4-7E。

八个环节之间传递的是四类凭证：数据集卡片（即数据卡）、质量报告（质检报告与验证报告）、许可（确权记录中的许可条款与期限）、摘要（挂牌页的质量结论摘要与存证账本的事实摘要）。这四类凭证在不同环节由不同模块读写，一旦彼此说法不一，后果不是界面不好看，而是交易记录把错误固化下来。平台因此设九处一致性检查，检查由系统执行并在不通过时阻断，不依赖人工发现。九处检查如表 2.4-7E。

表 2.4-7E　四类凭证的九处一致性检查。数据来源：招标文件 b1164（完整性校验）、b1166（审批判据）、b1179、b1180（交付方式与授权）、b1196（争议用途）、b1569、b1570（数据集卡片与自描述封装）。检查由系统执行，检查结论随对象留痕。

九处检查中第四、五、六三处值得单独点出，它们管的是同一件事的三个侧面：对外说的（挂牌摘要）、约定的（许可）、实际给的（订单授权与交付范围）必须层层收敛而不能放大。用户在挂牌页看到的允许用途，不会比许可条款更宽；订单里选定的用途，不会比挂牌页展示的更宽；实际开放的授权，不会比订单更宽。三层收敛是权属争议发生时能够自证的基础。

1.3　订单管理功能要求（3.2.4.2）

订单管理由交易合同管理与交易费用管理（订单侧）两个功能模块承担。

1.3.1　订单要覆盖的交易形态

招标文件要求订单管理「支撑数据和服务从申请到履约的全过程」，列明订单生成、订单支付、订单取消、订单状态跟踪和订单履约确认五项（b1171）。这五项本身不难，难点在于本项目的交易形态并不单一。企业内部部门调用数据集，走的是内部结算甚至不结算；行业中小企业购买一个标准数据包，可以在线下单在线支付；科研机构申请公益开放数据集，需要资质核验但不收费；大型用户购买定制数据服务，必然要先线下谈范围、谈价格、签合同，再在平台上补一笔订单做履约跟踪。

一套订单模型要同时装下这四种形态，关键是把「订单」与「合同」「支付」解耦：订单是履约的载体，合同是约定的载体，支付是资金的载体，三者通过订单号关联但各自有独立状态。线下协商的交易先有合同再有订单，在线选购的交易先有订单再生成合同，内部调用的交易有订单而无支付。

表 2.4-8　四类交易形态与订单处理方式。数据来源：招标文件 b1172、b1173（在线选购与线下协商）、b1174（多种支付方式）、b1838（公益导向）、b1817（公益性与增值服务分层）。

1.3.2　订单生成

在线选购的路径是常规的：检索或浏览挂牌数据集，加入订单，选择交付方式与授权范围，系统按计费规则试算金额，确认后订单成立。其中两处设计值得说明。

一是授权范围在下单时就要确定。用户需要选择使用主体（哪个租户、哪些用户组）、使用期限、使用用途、交付方式与配额。这些选择直接写入订单，交付时按订单授权生成权限，而不是交付后再配权限。好处是权限的来源永远可追到一笔订单，审计时不会出现「这个人为什么有这个数据的权限」答不上来的情况。

二是计费试算在订单成立前完成并留存。试算结果包含计费项明细、单价、数量、折扣依据与合计金额，用户确认的是这张明细而不只是一个总价。试算快照随订单保存，后续计费规则调整不影响已成立订单。

线下协商的订单由运营管理员代录（b1172、b1173）。代录须先完成合同登记：上传合同扫描件或在线签署件，录入合同编号、签署方、标的范围、金额、支付安排、交付安排、履约期限、违约与争议条款摘要。合同登记完成后才能生成关联订单，订单的标的与金额须与合同一致，不一致时系统拦截并要求说明。代录订单同样进入正常的交付与清算链路，不走例外通道。

1.3.3　订单支付

平台支持多种支付方式（b1174）。在线支付对接企业网银与第三方支付通道，支付结果由通道回调确认，平台不以用户页面操作作为到账依据。线下对公转账由用户上传付款凭证，运营管理员核对银行流水后确认到账，这一动作须双人复核。内部调用不发生资金流动，按内部结算单据记账。公益开放不收费，订单金额为零但仍生成订单与清算记录，用于统计公益服务量（见 2.6 节）。

支付环节的几条规则需要写进平台：支付金额须与订单金额一致，部分到账的订单保持「部分支付」状态不进入交付；超额到账触发差额退款流程；支付凭证与订单一一对应，同一凭证不可用于多笔订单核销；所有支付与核销动作入交易清算审计（b1195）。

支付通道与收款账户按五步流程在实施阶段完成配置，每一步留下可核验的记录，账户信息由甲方财务在第一步中提供，平台侧不预设、不代拟。

第一步，财务授权。由甲方财务部门出具收款主体、账户用途与经办授权的书面文件，载明开立主体、适用交易类型、可受理币种与授权有效期。平台据此建立收款主体档案，档案中登记主体名称、账户用途、授权文件编号与有效期；账号等敏感要素交由商用密码服务平台加密保管，运营管理员界面按掩码显示，完整值仅在向通道发起请求时由密码服务解密使用。

第二步，通道配置。按授权文件逐一配置在线支付通道与对公转账的到账识别规则，配置项包括通道类型、商户号映射、回调地址与验签方式、对账文件格式与获取方式、结算周期、单笔与单日限额。配置由具备支付配置权限的运营管理员录入，录入后处于「待测试」状态，不直接生效。

第三步，联调测试。在测试环境完成小额支付、退款、超额到账、部分到账、回调重发五类用例验证，同时核对对账文件可被自动解析、伪造的回调请求能被验签拒绝、重复回调不产生重复核销。测试结论形成测试记录，附每一类用例的请求与回执摘要。

第四步，审批上线。配置项与测试记录一并提交甲方财务与平台运营双方复核，复核通过后由具备上线权限的管理员执行上线，上线动作双人复核并计入交易清算审计（b1195）。

第五步，上线核验。上线首日执行一笔小额真实交易并完成全链路对账，确认订单金额、到账金额、清算金额三者一致后，通道转为正式可用。此后通道参数的任何变更重走第二步至第四步，变更前后的配置版本均留存。

1.3.4　线上交付与先行交付的差异处理

招标文件对这一条的要求写得具体：「须支持线上交付和先行交付两种不同交付方式下订单支付后的针对性处理，已实现线上交付的自动化和实时化、线下交付的履约可控」（b1175、b1176）。这实际上是两种不同的风险结构，平台的处置方式也不同。

线上交付的风险在于交付动作一旦完成就不可撤回——数据集下载完成之后，无法再收回。所以线上交付采取「支付后即时交付」：支付确认的回调到达后，平台自动生成授权、开放下载通道或签发 API 密钥，并向用户推送交付通知。这一过程无人工干预，目标时延按支付回调到达后 5 分钟内完成授权生成；数据集体积较大时，下载通道开放即视为交付完成，实际传输时长不计入交付时效。交付完成后订单自动转「待履约确认」，用户确认或超过 7 个自然日未提出异议即视为履约确认，进入清算（b1188、b1189）。

先行交付针对的是需要先行提供服务、后续分期收款的情形，典型是定制数据服务与线下专业服务。风险在于平台已经投入人力与资源，而款项未必全额到账。平台的处置是把履约拆成可验收的节点，每个节点对应一次交付确认与一次清算触发：

表 2.4-9　先行交付的节点划分与清算触发。数据来源：招标文件 b1175、b1176、b1184、b1188、b1189。节点划分可按合同约定调整，调整后的节点同步写入订单。

任一节点的验收意见为不通过时，订单转「整改中」，整改完成后重新提交验收。整改期间不触发该节点的清算。节点验收记录、验收材料与会议纪要统一保存在订单下（b1184）。

1.3.5　订单取消与状态跟踪

订单取消（b1177）按订单所处状态分三档。未支付的订单，用户可自助取消，立即释放占用的配额。已支付未交付的订单，用户提交取消申请，运营管理员核验未发生交付动作后执行取消并发起退款。已交付的订单原则上不支持取消，但下列两种情形例外并有明确处置：数据集因质量问题下架时，中止在途交付并退款；因合规事由下架时，按 1.2 节表 2.4-7 的口径处理。例外情形的处置依据与审批记录随订单保存。

订单状态跟踪对用户与运营两侧都要可见。订单状态机如图 2.4-5。

图 2.4-5　订单状态机与清算触发点

图 2.4-5　订单状态机与清算触发点。数据来源：招标文件 b1171—b1177、b1188、b1189。

状态跟踪在用户侧表现为订单详情页的时间轴，列出每一次状态变更的时间、执行方与依据单据；在运营侧表现为订单看板，按状态、超期风险、金额、数据集维度聚合，并对停留超过阈值的订单生成待办工单。阈值按状态设定，待支付默认 7 日、待交付默认 1 日、待履约确认默认 7 日、整改中默认 15 日。

1.3.6　交易合同管理模块

合同管理模块提供三类合同的处理能力。标准合同由平台内置模板，在线签署，签署采用电子签章并由商用密码服务平台提供签名与时间戳服务，签署完成的合同不可修改。线下合同支持扫描件归档加关键条款录入，关键条款录入项为签署方、标的、金额、支付安排、交付安排、履约期限、许可范围、违约责任、争议解决方式九项，录入值与扫描件由运营管理员双人复核。框架合同支持「一份框架合同对多笔订单」，框架合同下的订单自动继承框架约定的价格与许可条款，剩余额度由系统扣减。

合同到期前 30 日提示续签。涉及许可期限的合同到期时，平台同步处理相关授权的回收：到期后 API 密钥失效、下载通道关闭、租户资源配额归零，已下载的数据按合同约定的后续处理条款执行。

1.3.7　交易费用管理模块（订单侧）

计费规则由计费项、计量方式、单价、折扣策略四部分构成。计费项按交付方式分设：整包下载按数据集版本计次或计量，接口调用按调用次数或返回样本量，平台能力按租户按期计费，加工任务按任务量计费，线下服务按人日或按合同总价计费。计量方式与单价由数据集提供方在挂牌时设定，经可运营维度审批确认。折扣策略支持按用户类型、按采购量、按合作关系三类，折扣的授予须有审批记录。

订单金额的试算、开票与凭证管理也在本模块。发票信息按租户维护，开票申请由用户在订单完成后提交，平台生成开票任务流转至财务；发票号与订单、合同、清算明细四者关联，便于对账与审计（b1190、b1195）。

1.4　数据及服务交付功能要求（3.2.4.3）

数据及服务交付由数据集下载、数据集服务、数据集权限管理三个功能模块承担。

1.4.1　交付方式由数据属性决定

招标文件把交付分为线上与线下两种方式，并要求「针对不同属性的数据和服务自定义交付方式」（b1179）。这一条是整章的设计前提。我方的处置是在数据集注册时就把「允许的交付方式」作为一项元数据管起来（见表 2.4-5 权属与合规组），该项由提供方声明、经安全合规与可运营两个维度审批确认，用户下单时只能在允许范围内选择。

判断依据主要有三条。数据敏感程度决定能否整包离开平台：含企业秘密或经脱敏仍有重识别风险的数据集，只允许接口调用与任务式使用，不开放整包下载。许可类型决定交付的后续约束：公益开放数据集可整包下载但限制用途，商业授权数据集按合同约定。数据体积与使用方式决定技术通道：预训练语料整包下载更经济，基准评测数据集则必须以评测服务方式交付，否则基准答案一旦外流，这份数据集作为基准就失效了。

表 2.4-10　数据集类型与默认交付方式。数据来源：招标文件 b1179、b1180、b0804r06 第 7 项（去标识化与脱敏要求）；数据集类型划分取本项目四个用途子集口径。默认方式可由提供方在审批通过后调整。

1.4.2　三种线上交付通道

招标文件要求支持「数据集的下载、接口、任务式使用等多种方式」（b1180）。三种通道的技术实现与责任边界不同，分述如下。

下载通道的交付物是一个受控数据包。包内除数据集内容外，固定包含四个文件：数据集卡片（datacard），说明来源、规模、模态、构建方式与已知缺陷；数据字典与结构定义（schema），使第三方平台在脱离本平台后仍能准确解析；许可声明，列明许可类型、允许用途、使用期限与禁止事项；交付清单，记录订单号、版本指纹、交付时间与下载凭证号。包整体计算指纹并与登记指纹比对一致后方可下发。

接口通道的交付物是一组 API 与一把密钥。接口按数据集或服务粒度发布，采用 HTTPS 与国密传输通道，调用方以密钥加签方式认证。接口返回的数据量受单次与周期双重配额限制，超限返回明确的限流提示而不是静默截断。

任务式通道的交付物是一份任务成果。用户提交任务参数与（如需）自有数据，平台在内部执行后返回成果，原始数据集不离开平台。评测服务与加工任务服务走这一通道。任务执行过程的资源占用计入租户配额，任务日志与成果保留期默认 90 日，期满前用户可自行取回。

图 2.4-6　三种线上交付通道与数据流向

图 2.4-6　三种线上交付通道与数据流向。数据来源：招标文件 b1180、b1181、b1194—b1196。

1.4.3　接口交付的密钥、配额、文档与监控

招标文件对 API 交付提出四项要求：密钥管理、配额控制、调用文档和监控功能（b1181）。逐项说明如下。

密钥管理按租户与应用两级签发。一个租户可为不同应用签发多把密钥，便于区分调用来源与分别设限。密钥的生命周期包括签发、启用、轮换、停用、吊销五个动作，轮换支持新旧密钥并行的过渡期（默认 7 日）以免业务中断。密钥仅在签发时完整显示一次，平台侧存储散列值；签名与验签由商用密码服务平台提供能力支撑。密钥与订单绑定，订单到期或取消时密钥自动停用。

配额控制设四个维度：单次返回量上限、单位时间调用频次上限、周期总量上限、并发数上限。配额在订单授权时设定，运营侧可临时提额并留审批记录。配额消耗对用户可见，接口响应头返回剩余量，用量达到 80% 时推送提醒。超限时返回标准错误码与可重试时间，不静默降级。

调用文档随接口发布自动生成并与接口版本同步。文档内容包括接口说明、请求与响应结构、字段含义（取自数据字典）、错误码表、配额说明、示例请求与示例响应。文档提供在线调试功能，调试使用预置的样本数据而非真实数据集，避免调试行为消耗配额或触碰真实数据。接口变更时保留旧版本文档并标注停用计划，旧版本接口的最短保留期按 6 个月承诺。

监控分两层。技术层监控接口的可用性、时延、错误率、流量，数据进入 SLA 监测体系（见 1.7 节）。行为层监控调用模式的异常：调用频次显著偏离本租户历史基线、返回样本量接近数据集总量、短期内穷举式参数遍历、非常规时段的大量调用，四类情形触发告警并通知运营管理员与审计员。行为层监控的判据以每个租户的历史基线为准，而不是统一阈值——不同用户的正常用量差异很大，统一阈值会把正常用户误判为异常。首期上线阶段基线数据不足，先按保守的统一阈值运行，积累 3 个月数据后切换为按租户基线。

1.4.4　平台能力交付

招标文件要求支持「平台能力交付相关的租户开通、角色配置、功能模块授权和资源配额管理」（b1182、b1183）。这是把平台本身作为服务对外提供的情形，典型用户是产业链上的中小企业——它们有自己的数据要加工，但没有能力自建加工环境。

租户开通由订单触发，开通内容为一套完整配置：租户基本信息与管理员账号、可见的功能模块范围、可用的数据集与服务范围、资源配额、计费与账期、数据隔离策略。开通动作生成一份租户开通单，内容与订单授权一致，由运营管理员复核后生效。

角色配置在租户内由租户管理员自行维护。平台预置四种角色模板（租户管理员、数据管理员、使用人员、查看人员），租户管理员可在模板基础上调整权限项，但不能超出平台授予该租户的权限上限。这个上限由平台侧设定，租户侧不可见也不可改。

功能模块授权按模块粒度控制。例如一个只购买了数据检索与下载能力的租户，其界面中不出现加工任务与评测服务的入口。授权变更即时生效，收回授权时同步清理该租户下已签发的相关密钥与在途任务。

资源配额覆盖存储容量、计算资源（任务并发与累计算力）、接口调用量、下载流量、用户数五项。配额采用「一级租户设上限、二级租户在上限内分配」的两级模型（见 1.1.9 节）。配额使用情况在租户控制台可视，接近上限时提示扩容。超限行为按配额类型分别处置：存储与用户数超限阻断新增，计算与调用量超限阻断新请求但不中断在途任务，下载流量超限暂停新下载。

表 2.4-11　租户资源配额项与超限处置。数据来源：招标文件 b1182、b1183。配额默认值按租户等级设定，各级默认值在实施阶段随服务分级方案一并确认并写入租户开通单；确认前按本表的配额项、计量单位与超限处置口径执行。

1.4.5　线下服务交付

招标文件对线下交付列明六个环节：计划、签到、材料、纪要、验收和评价（b1184）。这六个环节我方按一个服务工单贯穿，每个环节产出一份可核验的记录。

计划环节由运营管理员与用户共同确认服务计划，内容包括服务事项、交付节点、到场人数与角色、时间安排、用户侧需配合事项、验收标准。服务计划经用户确认后作为后续验收的依据。签到环节记录每次到场的时间、地点与参与人，签到由用户侧确认，形成服务量的原始凭证——这是线下服务计费与清算的基础，没有签到记录的服务量不计入结算。

材料环节归集服务过程中提交与产出的文件：需求说明、技术方案、交付物清单、操作手册、培训教材、测试记录等。材料统一挂在服务工单下，按节点归类，用户可随时调阅。纪要环节要求每次正式会议或现场作业后 2 个工作日内提交纪要，内容包括讨论事项、结论、待办与责任方、下次安排；纪要经用户确认后生效，用户在 3 个工作日内未反馈即视为确认。

验收环节按服务计划中的节点逐项验收，验收结论分通过、附条件通过、不通过三种。附条件通过须列明待整改项与完成时限，整改完成后补充确认。验收通过触发该节点的清算（见表 2.4-9）。评价环节在每个节点验收后由用户打分，评价维度为响应及时性、专业能力、交付质量、配合度四项，评价结果进入服务质量报告（见 1.7 节），并作为运营侧内部考核与服务改进的输入。

1.4.6　数据集权限管理模块

权限模型采用「角色—资源—操作」三元组，并在资源维度支持到子集级。资源可以是一个数据集版本、版本中的某个业务域分区、某个时间区间的样本，或一个数据服务接口。操作包括检索、预览、下载、调用、提交任务、查看元数据、查看质检报告七类。

权限的唯一来源是订单授权（见图 2.4-6 左栏）。平台不提供脱离订单的直接授权入口，内部调用与公益开放也须先生成零金额订单。这一约束使得「某用户为何拥有某项权限」这个问题总能在平台内回答到一笔订单、一份合同或一张内部使用登记单。

权限的有效期与订单一致，到期自动回收。回收动作包括：撤销角色绑定、停用相关密钥、关闭下载通道、终止在途任务、清理临时副本。回收完成后生成一份回收记录。对于已下载到用户侧的数据，平台在许可声明中约定到期后的处理义务，并在到期时推送提醒；平台能做到的是通道关闭与记录留存，用户侧副本的处置依赖合同约束与用户自律，这一点在许可条款中写明，不做超出技术边界的承诺。

1.4.7　三类服务的受理、计量、交付与争议处置

交付侧除数据集本身之外，另有三类以服务形态交付的标的：定制加工服务（按需承做的数据加工与智能体开发，见 2.3.4 节）、平台能力服务（把平台本身开通给用户使用，见 1.4.4 节）、接口服务（数据集服务模块封装的检索、问答、评测、加工任务四类可调用接口，见 1.2.12 节）。三类的交付物形态不同，受理到争议处置的处理方式因此分别写定，如表 2.4-11A。

表 2.4-11A　三类服务从受理到争议处置的处理方式。数据来源：招标文件 b1180、b1181（接口与任务式使用）、b1182、b1183（平台能力交付）、b1184（线下交付六环节）、b1811、b1812（定制服务与质量责任）。

三类服务的争议处置共用一套四步流程与同一套时限：提出、受理与证据固定、核查、结论与处置。用户在平台提交争议单并指明标的与事由，平台在 2 个工作日内受理并固定相关日志、计量数据与交付记录的快照，在 10 个工作日内出具核查结论；事实复杂的可延长一次并书面告知延长事由与新的时限。争议期间，争议标的相关的清算暂挂，其余未争议标的的交付与清算照常进行。核查结论与处置依据随争议单永久保存，并计入交易清算审计（b1195）。

三类服务在运行中会遇到五类典型场景，处置口径如表 2.4-11B。其中重复回调一项是平台对外接口与支付通道共用的幂等规则：所有异步回调按请求标识或流水号判重，重复到达的回调只产生一次状态变更，其余记为重复事件入审计。

表 2.4-11B　三类服务的五类典型场景处置。数据来源：招标文件 b1174（支付）、b1177（订单取消）、b1181（配额与监控）、b1182、b1183（平台能力交付）、b1188、b1189（清算联动）。

1.5　清算管理功能要求（3.2.4.4）

清算管理由交易费用管理模块的清算侧能力承担。

1.5.1　清算的对象、依据与五项功能构成

一份数据集的收益往往由多个贡献方分享。以本项目的产品工艺设计数据集为例：原始图纸与工艺卡片来自天地奔牛的设计与工艺部门，解析与标注由加工生产环节完成，质量结论由评测环节出具，对外运营由平台承担；产业链企业把自有数据汇聚进来形成联合数据集后（见 2.1 节），贡献方还会增加。

平台因此把收益分配实现为可配置、可追溯的清算而不是逐笔协商：清算对象取自确权模块登记的权属主体与贡献登记，分配份额取自确权记录或数据提供协议，分配基数、分配方式与触发条件取自订单成立时绑定的清算规则版本。三者在订单成立之时即已确定，清算执行时不再引入新的判断；规则在订单成立后发生调整的，只对新订单生效。

清算功能按五项组织：清算规则管理、订单清算管理、资金对账管理、分账管理和清算报表管理（b1185、b1186）。五项之间的关系是规则定分配口径，订单清算按触发条件生成明细，对账核验资金流与明细一致，分账执行应付与付款，报表供运营决策与审计查验。

1.5.2　清算规则管理

招标文件要求「支持灵活的清算规则定义，从而支持灵活多样的收益分配方案」（b1187）。规则的灵活性靠规则要素的组合实现，而不靠为每种情形写一套代码。我方把清算规则拆为六个要素。

表 2.4-12　清算规则的六个要素。数据来源：招标文件 b1187、b1188、b1189。规则由运营管理员配置，经运营组织的决策层审定后生效（见 2.5 节）。

规则配置支持版本化与生效日期管理。规则变更不回溯：订单成立时即绑定当时生效的规则版本，后续规则调整只影响新订单。规则变更前平台提供试算功能，运营方可用历史订单样本测算规则调整后的分配结果，再决定是否发布。这一步在实际运营中很有用——分配比例的调整往往牵涉多个供给方，先算清楚再谈，比谈完再算省事。

1.5.3　订单清算管理

清算与订单的联动按招标文件要求「与订单支付、履约确认和售后状态联动，按照设定的清算规则生成清算明细」（b1188、b1189）。联动关系已在图 2.4-5 下半部分列出五个触发点，这里补充三条处置规则。

第一，清算明细一经生成即不可修改，更正只能通过生成冲销明细加新明细的方式实现。这是审计可追溯的基本要求，也避免「改数」留不下痕迹。

第二，退款、异议、召回三类事件都会产生反向清算。退款生成冲销明细，金额为原明细的负数；异议处理期间相关明细转「暂挂」状态不进入支付；召回按合同约定的处理比例生成部分冲销。暂挂状态的明细在争议结论出具后按结论解挂或冲销。

第三，售后状态影响尾款与质保金。线下服务与定制服务的清算中若约定质保金，质保金部分在清算明细中单列并标注释放条件与计划释放日期，到期由系统提示释放，释放仍需运营管理员确认（见售后服务分节关于质保期的承诺口径）。

1.5.4　资金对账管理

招标文件要求支持资金对账功能（b1190）。对账的本质是三组数据的比对：平台订单与支付记录、支付通道与银行流水、清算明细与实际付款。我方按三重对账设计。

第一重是收款对账。平台每日自动拉取支付通道对账文件与银行流水，与平台支付记录逐笔比对，输出四类差异：平台有记录通道无记录、通道有记录平台无记录、金额不一致、状态不一致。差异逐笔挂起并生成待办，由运营管理员与财务核实后处理，核实结论与处理方式入审计。

第二重是清算对账。清算明细汇总金额与各清算对象的应付金额比对，与实际付款记录比对，确认应付等于已付加未付。差异同样挂起待查。

第三重是台账对账。按月核对数据集资产台账中记录的使用情况与订单、交付、清算三方的记录是否一致。这一重的目的是发现「有交付无订单」「有订单无清算」一类的链条断裂。

对账结果按日、按月生成对账报告。日报告列差异明细与处理状态，月报告列对账完成率、差异笔数与金额、平均处理时长。我方承诺对账差异的处理时效：日常差异在 2 个工作日内定性，涉及通道或银行的差异在 5 个工作日内闭环；对账完成率的首期基线按 98% 设定，运行三个月后逐步接近 99.5%，未达成时由运营管理员逐笔说明原因并列入月度服务质量报告。

图 2.4-7　清算与对账的资金流与数据流

图 2.4-7　清算与对账的资金流与数据流。数据来源：招标文件 b1186—b1191。

1.5.5　分账管理

分账管理把清算明细落到各清算对象的应付账与实际付款。平台维护各清算对象的账户信息与结算周期，按清算周期汇总应付金额，生成付款申请单，经审批后提交财务执行，执行结果回写平台形成付款记录。

共有数据集的分账按确权模块登记的份额执行。份额变更须经权属主体共同确认并留痕，变更同样不回溯已生成的明细。若出现权属争议，相关明细转暂挂，争议解决后按结论处理。

分账对平台的现金流有影响，因此平台提供应付账龄分析与资金计划视图，便于运营方安排结算节奏。平台本身的运营收入在分账中作为一个清算对象处理，与其他对象同口径核算，这样「以服务养服务」的循环（b1821）在账上能直接看出来。

1.5.6　清算报表管理

招标文件要求「支持多维度的清算报表生成功能」（b1191）。报表的维度与清单如下。

表 2.4-13　清算报表清单。数据来源：招标文件 b1191；营收目标达成表对应 b1819 关于营收目标分解的要求。报表支持按角色授权查看，数据提供方只能看到与本方相关的数据。

报表支持在线查看、导出与定时推送。导出格式包括表格文件与版式文件，导出动作入审计并记录导出范围。数据集收益表与服务类型收入表是运营决策的主要依据：前者回答「哪些数据集真正被需要」，后者回答「公益与增值的比例是否失衡」，两者都按季度进入运营组织决策层的审议议题（见 2.5 节）。

1.6　审计管理功能要求（3.2.4.5）

审计管理由全流程审计管理模块承担。

1.6.1　审计的范围与基本原则

招标文件要求审计管理「包括且不限于审计日志管理、数据访问审计、API 调用审计、交易清算审计和审计报表导出」（b1193），并要求能支撑「平台运营、安全合规、客户对账、监管检查和争议处理」五类用途（b1196）。这五类用途对审计数据的要求不同：运营要聚合，合规要完整，对账要可比，监管检查要可导出，争议处理要可还原到单次动作。我方因此确立三条原则。

第一条，审计写入与业务动作同事务提交。业务成功而审计缺失的情形在设计上不成立，审计写入失败则业务动作回滚。这一条是「记录所有用户对数据集的访问行为」（b1194）能够成立的技术前提。实际覆盖率受异常场景影响，我方承诺首期上线即对平台内所有业务入口实施审计埋点，并按月做埋点覆盖巡检，覆盖率目标逐步接近完整；巡检发现遗漏的入口在下一个迭代窗口补齐，巡检结论列入月度服务质量报告。

第二条，审计记录只增不改不删。审计表不提供更新与删除接口，留存期内的记录不可变更。留存期内的审计数据定期生成摘要并写入存证账本，用于验证记录未被篡改。

第三条，审计员的操作同样入审计。审计员查询了哪些记录、导出了什么范围，本身是一条审计记录。没有这一条，审计就留了一个不受监督的口子。

1.6.2　审计事件类型与记录字段

审计事件按业务域分六类，每类的关键字段如下。所有事件共有的基础字段为：事件号、事件类型、发生时间（统一时间基准）、操作主体（用户、租户、角色）、来源地址与客户端标识、操作结果（成功／失败／拒绝）、关联订单号、关联数据集版本号、请求标识。

表 2.4-14　审计事件类型与记录字段。数据来源：招标文件 b1193—b1197。字段清单的完整版本作为治理文档《审计日志规范》交付，见数据治理分节。

1.6.3　四类专项审计视图

招标文件点名的四类审计在平台中表现为四个专项视图，它们查的是同一份审计数据，但组织方式与检索入口不同。

数据访问审计视图以数据集版本为主线，回答「这份数据被谁在什么时候以什么方式访问过」。视图提供时间轴与聚合两种呈现：时间轴列每一次访问事件，聚合按用户、租户、访问方式、数据量统计。对敏感数据集提供访问热度与异常访问提示。这个视图在争议处理时最常用——数据疑似外流时，第一步就是看访问记录（b1194）。

API 调用审计视图以接口与租户为主线，回答「这个租户调了多少、调了什么、有没有异常」。除逐条记录外提供调用量趋势、错误率分布、配额使用率、异常模式命中情况。与 1.4.3 节的行为层监控共用同一套判据，监控告警与审计记录互相可跳转。

交易清算审计视图以订单号为主线，把订单、合同、支付、交付、履约确认、清算明细、分账付款串成一条链（b1195）。任一环节缺失或金额不一致，视图上以标记呈现。客户对账与监管检查主要用这个视图。

数据集生命周期审计视图以数据集版本为主线，把注册、校验、审批、确权、发布、变更、下架串成一条链，用于回答「这份数据当时为什么允许对外」这类事后追问。

1.6.4　审计报表与导出

审计报表分三组。运营类报表按周、月汇总平台活跃度、数据集访问排行、交付量、异常事件数；合规类报表按月汇总敏感数据访问情况、权限变更情况、一票否决项审批情况、埋点覆盖巡检结论；检查类报表按需生成，用于对外提供，内容与范围按请求方要求裁剪。

导出能力有三条约束：导出须指定范围与用途并留记录；导出文件带水印与导出凭证号；超出一定规模的导出须经审批。导出格式支持结构化数据文件与版式文件两类，结构化文件用于对账与再分析，版式文件用于盖章提供。

1.6.5　可扩展性与时效性

招标文件要求审计「满足可扩展性和时效性要求」（b1197）。两项要求的技术口径如下。

可扩展性方面，审计数据采用「写入—索引—归档」三段式存储。写入段承接实时写入，按日分区；索引段支撑按订单号、数据集版本号、用户、时间四个主检索键的查询；归档段存放超过热数据期的记录，压缩存放但保持可检索。扩容通过增加分区与存储节点实现，不需要改表结构。审计事件类型的新增通过配置扩展字段实现，不需要改既有记录。审计数据量按本项目规模预估：首期年均审计事件量在千万级，三段式存储可在不改架构的前提下支撑十倍增长。

时效性方面分三档承诺。实时写入的时延目标为业务动作完成后 1 秒内可查（同事务提交，实际由数据库提交时延决定）。热数据期内（默认 90 日）的按主键查询响应目标在 3 秒内，组合条件查询在 10 秒内。归档数据的检索为异步任务，提交后目标在 30 分钟内返回结果。留存期按合规与审计要求设定：交易与清算类审计不少于 10 年，数据访问与 API 调用类不少于 3 年，身份权限与运维类不少于 3 年，上列年限为平台承诺的留存下限，最终留存期在实施阶段按甲方合规要求与等级保护测评结论确定，确定值不低于该下限。

上述响应时间目标为运营侧承诺值，与平台整体性能指标的关系见非功能分节。

1.7　平台服务与 SLA 保障功能要求（3.2.4.6）

平台服务与 SLA 保障由我方在采购清单之外增列的同名功能模块承担。

1.7.1　分级服务体系

招标文件要求「建立分级服务体系，针对不同级别的客户和产品提供差异化的服务保障」（b1199、b1200）。分级的目的不是把用户分成三六九等，而是让资源投入与承诺水平匹配：对关键用户与关键数据集给出更高的承诺并配套更密的监测，对一般用户给出可持续的承诺水平。

服务分三级。基础级面向公益开放用户与标准包购买用户，服务通过平台自助渠道提供，承诺水平按平台整体可用性。标准级面向签订年度合同的行业用户与企业内部业务部门，提供专属服务通道与工单响应承诺。专属级面向定制服务用户与链主企业内部关键场景，提供指定服务窗口、服务经理对接、季度服务评审。

产品侧同步分级，依据是数据集或服务在业务中的关键程度。关键级数据集指支撑企业生产经营关键环节的数据集与服务，例如支撑板材备料工艺设计的工艺数据集与接口；重要级指支撑日常业务的数据集；一般级指参考性与历史性数据集。平台按「客户级别与产品级别取高」确定一笔订单的服务保障级别。

表 2.4-15　三级服务体系与响应承诺。数据来源：招标文件 b1199、b1200。工单级别定义见表 2.4-16；承诺值为运营侧目标值，签约时按合同约定最终确认。

表 2.4-16　工单级别判定标准。数据来源：招标文件 b1202、b1203 关于快速响应与及时处理的要求。

1.7.2　SLA 核心指标定义

招标文件要求「定义 SLA 核心指标」（b1201）。指标要可度量，就必须写清三件事：怎么算、在哪儿采、不达成怎么办。我方按这三件事定义七项核心指标。

表 2.4-17　SLA 核心指标定义与承诺值。数据来源：招标文件 b1201—b1204。表中承诺值对应标准级服务；基础级与专属级按表 2.4-15 的差异化原则分别下调与上调，三级承诺值在签约时按合同约定确认；无论何级，均载明统计周期、剔除口径与未达成处置三项，口径与本表一致。可用性与响应时延的平台底层能力指标见非功能分节，本表为运营侧对外承诺口径。

指标定义中有三处刻意的保留，在此说明理由，以免将来履约时产生歧义。可用性剔除计划内维护窗口，维护窗口须提前 5 个工作日公告并约定在业务低峰时段。接口响应时延只统计服务端耗时，因为网络传输质量不在平台控制范围内。交付及时率剔除用户致因的延误，例如用户未按时提供资质材料导致资质核验无法完成——这类情形逐笔归因并在服务报告中列出，不计入违约。

SLA 指标按可履约的形式约定：每一项可用性承诺均载明统计周期、剔除口径与未达成时的处置方式，使其在服务期内可逐月核算、可追溯、可考核。

1.7.3　自动化服务监控体系

招标文件要求「支持自动化的服务监控体系，实时监测平台的各项指标，做到快速响应、及时处理」（b1202、b1203）。监控体系按采集、判定、处置、复盘四段设计。

采集覆盖四层。基础设施层采集服务器、存储、网络、密码机的运行状态；平台组件层采集数据库、中间件、容器与网关的健康状态与关键队列深度；业务链路层按关键链路做端到端拨测，拨测用例覆盖登录、检索、预览、下单、支付回调、授权生成、下载、接口调用八条；业务指标层按表 2.4-17 的口径实时计算 SLA 指标并与阈值比对。

判定采用双阈值。警示阈值用于提前介入，例如可用性月度累计消耗已达承诺容差的 50% 时发出警示；告警阈值用于立即处置。对波动型指标采用连续多个采样周期越界才告警，避免单点抖动造成告警风暴。告警按工单级别自动分级并派单。

处置按级别走不同通道。严重级告警同时推送值班人员、运营管理员与服务经理，并自动创建事件工单；较重与一般级进入工单队列按承诺时限处理。处置过程中的每一步动作与时间入工单记录，用于后续计算响应与解决及时率。应急处置的预案清单与演练安排见售后服务分节。

复盘针对严重级事件与连续两次未达成的指标。复盘输出三项内容：事件时间线、根因、改进措施与完成时限。改进措施作为待办跟踪至关闭，关闭情况在下一次服务报告中体现。

图 2.4-8　SLA 监测看板界面示意

图 2.4-8　SLA 监测看板界面示意。数据来源：招标文件 b1201—b1204；看板中数值为示意值，用于说明指标口径与呈现方式，不代表承诺值。

1.7.4　服务质量报告

招标文件要求「自动生成服务质量报告，为服务考核和改进提供依据」（b1204）。报告分两类。

对内报告面向运营组织，按月生成，内容为七项：SLA 指标达成情况与趋势、未达成项的逐项归因与改进措施、工单与事件统计、分级服务的履约情况、审计埋点覆盖巡检结论、对账完成率与差异处理情况、下期改进计划。对内报告进入运营组织执行层的月度例会议题，未达成项的改进措施在报告中列明责任与时限。

对外报告面向用户，按服务级别的约定周期生成，内容按该用户可见范围裁剪：本用户相关的可用性与接口指标、本用户订单的交付及时情况、本用户工单的响应与解决情况、本用户的配额使用情况、下期服务安排。专属级用户的季度服务评审会以此报告为基础材料。

报告生成是自动的，但结论不自动——未达成项的归因需要人写，改进措施需要人定。平台负责把数据算准、把报告出齐、把待办跟到关闭，这是「为服务考核和改进提供依据」的落脚处。

1.8　对外接口要求（3.2.4.7）

对外接口承载数据集走出企业之后的对接能力，由对外接口模块承担：依照国家数据基础设施的接入规范预留统一目录标识登记、统一身份注册和标准接口互联互通三类对接接口，并视国家数据基础设施开放进度支持数据集标识的注册与解析对接（b1205、b1206）。

1.8.1　接口预留与接入实施的分段安排

对外接口按两段推进。第一段是不依赖外部开放进度的本地准备：按接入规范实现统一目录标识登记、统一身份注册与标准接口互联互通三类对接接口，在本项目建设期内完成，并以接口桩联调方式验收。第二段是随规范开放推进的对接实施：依照开放进度完成数据集标识的注册与解析对接，技术方案与组织实施见 2.7 节。

招标文件在 b1206 中以「视国家数据基础设施开放进度」限定了第二段的推进条件，两段的验收口径因此分开设定。第一段的交付物是接口实现、字段映射配置与四步联调记录，验收判据是按规范定义实现并通过接口桩联调，不以真实对端接入成功为判据。第二段按接入规范与测试环境具备的时点启动，里程碑与验收口径在实施计划中单列。分段的结果是本项目的验收不受外部开放进度制约，而规范开放后平台无需改造即可对接——所需工作限于映射配置的调整。

1.8.2　三项接口预留的本地实现

按「统一目录标识、统一身份登记、统一接口要求」三项要求（b0676、b1206），平台的本地准备如下。

统一目录标识登记方面，平台的数据集目录编码采用五段结构并预留标识映射位（见 1.2.7 节）。目录项的元数据按「可对外发布的目录信息」与「仅内部可见的目录信息」两级标注，对外发布级的字段集合按当前已公开的行业目录规范对齐，包括数据集名称、提供方、业务域、模态、规模区间、许可类型、更新频次、联系渠道。平台提供目录信息的批量导出与增量同步接口，接口数据格式采用标准结构化格式并提供映射配置，规范调整时通过映射配置适配而不改数据模型。

统一身份注册方面，平台的身份体系按「主体标识＋凭证」分离设计。主体标识记录法人主体的统一社会信用代码、主体名称、主体类型，与平台内部的租户标识一一映射；凭证部分支持多种认证方式并存，为将来对接外部统一身份提供新增一种认证方式的扩展点。平台不把内部租户标识当作对外身份使用，这是为了外部身份体系接入时不需要重建租户数据。

标准接口互联互通方面，平台的对外接口按三组预留：目录与元数据同步接口、数据集标识注册与解析接口、交易与交付协同接口。接口采用标准协议，传输通道采用国密算法，调用方身份与权限经网关校验。接口的版本管理与文档管理与 1.4.3 节同口径。

表 2.4-18　对外接口预留情况与对接条件。数据来源：招标文件 b1205、b1206、b0676、b1841。接口桩指按规范定义的接口实现，可用于联调验证而尚未接入真实对端。

1.8.3　对接的职责边界、联调、失败补偿与交接

对接实施须逐项定清四件事：两侧的职责边界、联调的通过判据、对接失败的补偿路径、建设期结束时的交接内容。

对接的职责边界按对接事项逐项划定，如表 2.4-18A。划定的判据是「数据与凭证在哪一侧生成、由哪一侧负责其正确性」，不按系统归属划分。边界之所以要写到这个粒度，是因为对外流通环节的争议往往出在两侧都以为对方会做的那一格。

表 2.4-18A　对外对接的职责边界。数据来源：招标文件 b1205、b1206（对外接口三项预留）、b1840—b1845（接入实施、可信流通与资产化运营）。

联调按 2.7.1 节的四步执行，每一步的验证内容与通过判据如下，四步全部通过方可启用，任一步未通过即停在该步并出具不通过说明。第一步接口连通，验证网络可达、证书与国密通道握手成功、鉴权凭证可用，通过判据是连续 10 次探测全部成功且无降级为非国密通道的情形。第二步数据格式校验，以不少于 200 条真实结构的样本数据逐字段比对，通过判据是必填字段无缺失、枚举值全部落在对端字典内、字段长度与编码无截断。第三步业务流程贯通，以目录发布、标识注册、订单协同、交付凭证互认四条主流程各跑通一次完整往返，通过判据是每条流程的回执状态与平台内状态一致。第四步异常场景验证，覆盖对端超时、对端业务拒绝、回调丢失、重复回调、数据不一致五类，通过判据是每一类都触发了预期的补偿动作且未产生重复状态变更。四步各出具一份联调记录，记录中载明用例清单、执行时间、结果与遗留项，遗留项逐条写明关闭计划。

对接失败的补偿机制按失败类型分别设定，如表 2.4-18B。补偿的共同原则是：先自动重试、再入补偿队列、最后转人工，三级之间有明确的升级条件而不是无限重试；平台内的业务状态不因对接失败而回退，对外状态与平台内状态的差异由补偿队列负责收敛。

表 2.4-18B　对接失败的类型、补偿与升级。数据来源：招标文件 b1206（视开放进度对接）、b1841（优先采用成熟技术与产品）、b1844（可信、高效流通）；接入连接器的通道管控与存证能力见硬件分节。

对外对接的全过程计入审计。每一次同步、注册、解析与协同调用生成一条 API 调用审计记录，记录字段除 1.6 节表 2.4-14 的通用字段外，另加对端标识、批次号或请求标识、请求摘要、响应码、重试次数与补偿结果六项。对外发布与对外撤下两类事件另立专项审计视图，可按数据集版本回溯其对外可见状态的全部变更，这是对外流通发生争议时的首要证据来源（b1196）。补偿队列的每一次入队、续试与出队同样留痕，出队记录中写明是补偿成功还是转人工，转人工的关联到处置工单。

建设期结束向运营方交接时，对外接口部分按一份交接清单移交并以交接单落地：映射配置的当前版本与历次变更说明、四步联调记录与遗留项关闭情况、接口文档与错误码表、补偿队列的当前状态与处置手册、对端的联系与变更通知渠道登记、未完成的标识申请清单及其各自所处环节。交接以运营方逐项接收检查并签回为完成标志，接收检查不通过的逐项退回补充。交接完成后 3 个月为技术支持期，期内由实施侧保留一条响应通道处理对接类问题，响应与处置时限按专属级服务承诺执行（见表 2.4-15）。

1.9　平台实施部署、培训与验收

运营平台的建设与交付按实施阶段划分、培训、验收与风险回退四项安排。与系统集成分节的工作在第三阶段合并执行，与售后服务分节的承诺在第五阶段上线后衔接。

1.9.1　实施阶段划分

运营平台的建设按五个阶段推进，与数据集加工生产的进度相衔接——平台要在第一批数据集完成质检与验证之前具备登记与上架能力，否则数据集产出后无处可放。

第一阶段为调研与设计，主要工作为业务流程细化调研、与甲方现有系统的账号与身份对接方案确认、元数据标准与目录编码确认、权限模型与角色设置确认、清算规则与价格体系的初稿、SLA 指标与承诺值的确认。本阶段的产出为需求规格说明书、接口设计说明书、数据库设计说明书与部署方案，经甲方确认后进入开发。

第二阶段为平台搭建与功能实现，按模块分批交付，交付顺序按依赖关系排定：先建身份权限、目录元数据、登记注册、确权、版本管理（上架链路），再建订单、合同、费用、交付、权限签发（交易链路），再建清算、审计、SLA 保障（保障链路），最后建对外接口（对接链路）。每批交付后进行内部测试与甲方确认测试。

第三阶段为集成与联调，内容为与商用密码服务平台的对接、与接入连接器的对接与联调、与加工生产平台的移交登记接口联调、与甲方身份认证系统的对接。本阶段与系统集成分节的工作合并安排，联调按 2.7.1 节的四步执行。

第四阶段为试运行，内容为首批数据集的登记与上架、内部用户的试用、小范围外部用户的试用、SLA 指标的基线采集、运营制度与作业手册的试行。试运行期不少于 1 个月，期间发现的问题按缺陷分级处理，严重与较重缺陷在试运行期内闭环。

第五阶段为正式上线与运营移交，内容为已验收数据集的批量上架、运营组织的运行、培训交付、文档交付与验收。

图 2.4-9　运营平台建设五阶段与第二阶段四条链路的交付顺序

图 2.4-9　运营平台建设五阶段与第二阶段四条链路的交付顺序。数据来源：阶段划分与各阶段工作内容依本节 1.9.1 节；四条链路的依赖顺序依第二阶段模块交付顺序；联调四步依 2.7.1 节；验收四方面依表 2.4-19 与招标文件 b1159。

1.9.2　培训安排

培训按对象分三类，具体课时与教材清单见售后服务分节，本节只说明与平台功能对应的培训内容。

面向运营人员的培训覆盖四个组的作业内容：上架受理与审批组织、订单与交付处理、清算配置与对账、运行监测与 SLA 管理。培训方式为课堂讲解加平台实操，实操在培训环境进行，培训环境的数据为脱敏样本。培训结束后进行操作考核，考核不通过的补训。

面向审批专家与审计员的培训覆盖审批界面操作、评审项与判据的理解、审计视图的使用与报表导出。这一类培训的重点不在操作而在判据——四维度审批的判据理解不一致，审批结论就不可比。

面向用户的培训覆盖检索与预览、下单与交付、接口接入与调试、配额与账单查看。用户培训以线上课程与操作手册为主，专属级用户提供现场培训。

1.9.3　验收口径

运营平台的验收按功能、性能、安全、文档四个方面组织，每一方面有明确的验收方法与通过判据。

表 2.4-19　运营平台验收口径。数据来源：招标文件 b1159、b1160、b0804r04、b0804r07；性能指标以非功能分节约定值为准，测评要求以安全分节安排为准。

有两处验收口径需要事先说明清楚，避免验收时产生分歧。

对外接口的验收以「按规范实现并通过接口桩联调」为准，不以「与真实对端接入成功」为准。原因是招标文件已明确「视国家数据基础设施开放进度」（b1206），真实对端的开放时点不在项目可控范围内。我方承诺的是接口能力在项目期内建成并可验证，真实对接在规范与测试环境具备后按双方约定的时间窗完成，所需的适配工作量在原方案的映射配置范围内。

SLA 指标的验收以「指标可被平台自动采集与计算、口径与表 2.4-17 一致」为准，承诺值的达成考核从正式上线后进入第一个完整统计周期起算。试运行期采集的指标作为基线参考，不作为考核依据——试运行期的数据量与使用模式与正式运营差异较大，用它考核没有意义。

1.9.4　风险与回退安排

本节列出三项与运营平台直接相关的风险及其回退安排。项目整体风险管理见项目管理分节。

对外接入规范未按预期开放。影响是 2.7.1 节的实施段无法完成。回退安排为：本地准备段按期完成并验收，对外接入段转为长期跟进，平台保持接口桩与映射配置可用；若规范在项目期内开放，按约定时间窗完成对接；若未开放，不影响平台其余功能的验收与运营。

汇聚方数据供给不达预期。影响是数据集的持续丰富与更新受限。回退安排为：优先保障链主企业内部数据的汇聚（这部分在企业内部管理制度约束下可控），外部汇聚按实际到位情况调整数据集的更新频次承诺并在挂牌页标注，不因外部供给不足而降低已挂牌数据集的质量结论口径。同时启用汇聚激励机制的调整权限，由决策层审议是否提高激励力度。

对外运营的用户规模与收入低于预期。影响是「以服务养服务」循环的第一环变弱。回退安排为：公益服务预算的制度化安排不随商业收入波动削减（见 2.6.6 节），保障公共服务职能的履行；商业服务的投入按数据集收益表动态调整，优先投向已验证有需求的数据集；平台运行的基本保障成本纳入运维预算，不依赖运营收入。这项安排的意思是，平台的基本运行与公共服务不以商业收入为前提条件。

2、数据集运营推广服务要求（3.2.6.6）

运营推广服务围绕数据持续汇聚、运营体系、运营架构、盈利模式、运营组织、公共服务内容体系及接入国家数据基础设施七个方面建设，不含团队建设、运营服务硬件基础设施及其他服务配套能力建设（b1785、b1786）；团队人员配置见项目团队分节，硬件基础设施见硬件与集成分节。

七个方面共用同一载体，即第 1 章的数据集运营服务管理平台：汇聚机制供给运营要素，运营体系与运营组织确定决策、把关与执行的主体，运营架构组织服务的供给方式，盈利模式维持运营投入，公共服务体系履行行业公共职能，接入国家数据基础设施打通对外流通路径。

2.1　数据协同汇聚要求（3.2.6.6.1）

本项目四类数据集所需的数据分布在产业链各环节：刮板输送机的供需计划数据涉及矿方的生产规划与地质条件、涉及采煤机与液压支架配套厂家的接口参数；制造过程数据涉及钢材供应商的材料批次与质量证明；产品质量数据涉及在役设备所在矿井的实际工况。其中选型输入的截深、截高、推移步距一类接口参数，由矿方与刮板输送机、采煤机、液压支架、破碎机各方协商确定，常只存在于交流过程而无规范的电子留痕，须由汇聚机制约定其留痕方式、提交责任与提交时点，才能进入平台。

平台据此建立数据协同汇聚机制，将分散在产业链各环节、各主体的数据资源与数据集持续汇聚至运营平台，保障并促进平台运营要素的丰富与更新（b1787、b1788），按汇聚范围与责任主体、持续增量汇聚、权属与合规登记、激励与更新四项落地（b1789—b1795）。

2.1.1　汇聚范围、责任主体与协同规则

招标文件要求「建立面向产业链上下游各环节、各主体的数据协同汇聚机制，明确汇聚范围、责任主体与协同规则」（b1789、b1790）。

汇聚范围按产业链环节划分五类主体与对应的数据类型。

表 2.4-20　汇聚范围与责任主体。数据来源：招标文件 b1789、b1790；产业链环节划分与数据类型依据矿山装备制造的业务链条及本项目四类数据集的覆盖范围（b1578）。

责任主体的落实方式分两档。链主企业内部的数据汇聚，责任落到各业务单元，由运营组织按数据域指定数据责任人，责任内容为按约定频次提供数据、确认数据口径、处理数据质量问题。这一层的约束力来自企业内部管理制度，具体制度清单见数据治理分节。产业链外部主体的数据汇聚，责任通过协议落实：平台与汇聚方签订数据提供协议，约定数据范围、频次、质量要求、权属与许可、收益分配、保密义务与违约责任。

协同规则的核心是三份文本：数据提供协议模板、数据汇聚技术规范、数据口径对照表。协议模板按汇聚方类型分设三种（无偿公益提供、有偿提供、合作共建按份共有）。技术规范规定接入方式、数据格式、字段要求、传输安全与交付频次。口径对照表解决同一业务含义在不同主体的系统中字段名与取值不同的问题，这是跨主体数据能用起来的前提——没有口径对照，汇聚进来的数据合不到一起。

2.1.2　持续增量汇聚

招标文件要求「支持分散数据资源与数据集的持续、增量汇聚，保障汇聚工作的常态化与持续性」（b1791、b1792）。常态化靠的不是口号而是通道与节奏。

通道按汇聚方的技术条件分四种，由汇聚方选择：接口对接适用于有系统且能开放接口的主体，按约定频次增量拉取或推送；文件交换适用于有系统但不便开放接口的主体，按约定格式定期交换文件；平台录入适用于数据量小或非结构化的情形，由汇聚方在平台上直接填报或上传；现场采集适用于缺少数字化条件的环节，由项目组按计划上门采集并整理入库。四种通道的数据进入平台后走同一套校验与登记流程，不因来源不同而降低要求。

节奏按数据的时效要求设定。设备运行与过程参数类按日或按周增量；工单、检验、服务记录类按月增量；图纸、工艺、标准、规范类按季度增量或按变更触发；地质与工作面参数类按项目触发。汇聚计划按年制定、按季滚动调整，计划内容包括汇聚方、数据类型、通道、频次、责任人、质量要求。

平台侧的支撑是动态更新模块（见 1.2.10 节）与一个汇聚看板。看板按汇聚方与数据类型呈现计划量、实际量、到位率、质量问题数、逾期情况。到位率是运营组织的月度考核指标之一，首期按不低于 80% 设定基线，运行一年后逐步接近 90%；连续两期未达成的汇聚方由运营组织的执行层上门沟通，调整频次或更换通道。

2.1.3　权属与合规登记

招标文件要求「建立汇聚数据的权属与合规登记机制，确保来源可溯、权属清晰、合规可用」（b1793、b1794）。这一条与 1.2 节的确权模块是同一套机制在汇聚场景下的应用，此处只写汇聚特有的处置。

来源可溯的落地是「一数一源」登记：每一批汇聚数据登记其来源主体、来源系统或采集方式、取得依据（协议编号或内部授权记录）、交付时间与交付人、原始数据的指纹。登记在数据进入平台时完成，后续加工产出的数据集通过血缘关系回溯到原始来源。

权属清晰的落地是在协议签订时就把三件事写明：原始数据的权属归汇聚方，汇聚方授予平台的权利范围（使用、加工、再许可、对外运营各项分别约定），加工产出的数据集权属归属与收益分配。合作共建类的汇聚采用按份共有，份额在协议中约定并登记入确权模块，直接作为清算规则的输入（见 1.5 节）。

合规可用的落地是入库前的三项核查：敏感信息核查，识别个人信息、敏感地理信息、重要行业数据与企业秘密数据，按核查结论执行去标识化或脱敏（b0804r06 第 7 项）；授权范围核查，确认拟进行的加工与运营行为在汇聚方授予的权利范围内；用途限制核查，确认数据的允许用途与数据集的声明用途一致。三项核查有结论才允许入库，核查记录随数据批次保存。

2.1.4　激励与更新机制

招标文件要求「建立汇聚激励与更新机制，促进平台运营要素持续丰富与动态更新」（b1795）。汇聚方愿意持续供数，靠的是看得见的回报。我方设计四类激励，适用对象不同。

表 2.4-21　四类汇聚激励方式。数据来源：招标文件 b1795、b1817、b1821；服务积分的折算系数由运营组织决策层按年审定并在平台内公布，审定依据为上年度各类数据的汇聚成本与使用频次。

更新机制的重点是「让数据集不过期」。我方按三条处置。一是时效性监测：数据集资产台账记录时效性占比（承接 b1573），台账按月重算，时效性占比低于阈值的数据集生成更新待办。二是更新承诺：数据集挂牌时由提供方承诺更新频次，承诺写入元数据并对用户可见，未按承诺更新的数据集在挂牌页标注「更新滞后」，连续两期未更新转停售。

三是使用反馈回流：用户在使用数据集后可提交反馈，反馈类型包括样本错误、口径不符、缺失场景、建议补充，反馈按数据集归集并进入下一版本的修订计划（承接 b1571、b1572 的回流逻辑）。反馈量与反馈采纳率是数据集运营质量的侧面指标，进入月度服务质量报告。

图 2.4-10　数据协同汇聚机制的主体、通道与登记环节

图 2.4-10　数据协同汇聚机制的主体、通道与登记环节。数据来源：招标文件 b1788—b1795、b0804r06 第 7 项。

2.2　数据集运营体系建设要求（3.2.6.6.2）

数据集运营体系以「链主企业牵头、产学研用协同、市场化运作」为核心运营方针，构建既符合矿山装备制造行业特性、又遵循市场经济规律的行业数据运营体系（b1796、b1797）。

2.2.1　运营方针的三个支点

招标文件把运营方针明确为「链主企业牵头、产学研用协同、市场化运作」，要求构建既符合矿山装备制造行业特性、又遵循市场经济规律的行业数据运营体系（b1797）。三个支点各自解决一个问题：链主牵头解决权威性与数据来源，产学研用协同解决能力补足，市场化运作解决可持续性。

2.2.2　链主牵头的组织与责任机制

招标文件要求「以产业链主企业的行业影响力与业务场景为牵引，明确链主牵头的组织与责任机制」（b1798、b1799）。

链主牵头在本项目中有两重含义。第一重是业务场景牵引：数据集建什么、建多少、什么口径，以链主企业的真实业务场景为准而不是以通用框架为准。本项目四类数据集的划分——供需计划、产品工艺设计、制造过程、产品质量——就是按链主企业的业务主线划分的，28 道备料工序、63 万张历史图纸这些具体对象也来自链主企业的实际生产。第二重是行业影响力牵引：链主企业在产业链中的地位使它有能力把上下游召集起来谈数据汇聚，这是单纯的技术平台做不到的。

责任机制按三层落实。链主企业承担数据运营的主体责任，包括数据来源的合法性、对外运营的合规性、运营组织的决策责任。各汇聚方承担所供数据的真实性与权属担保责任，由数据提供协议约定。平台运营方承担平台运行与服务履约责任，由 1.7 节的 SLA 体系与售后服务分节的承诺约束。三层责任不交叉覆盖，这是出事时能找到人的前提。

2.2.3　产学研用协同创新机制

招标文件要求「建立产学研用多方协同创新机制，明确各方角色、协同流程与成果共享规则」（b1800、b1801）。

表 2.4-22　产学研用四方的角色与成果共享口径。数据来源：招标文件 b1800、b1801、b0804r06 第 2、3、8 项（标准验证、专家库、知识产权要求）。

协同流程按年度循环组织：年初由运营组织汇总各方需求形成年度协同计划，计划明确课题、参与方、投入与产出；年中按季度推进并在运营组织例会上过进度；年末形成成果清单并按共享规则分配。涉及知识产权的成果（论文不少于 5 篇、发明专利不少于 3 项、软件著作权不少于 6 项，见 b0804r06 第 8 项）在立项时约定署名与权属，避免成果出来再谈。

数据标准专家库是协同机制的组织载体之一，专家的类别、入库标准、遴选流程、工作职责与考核机制见技术创新分节，本节不重复。

2.2.4　市场化运作机制

招标文件要求「建立市场化运作机制，按市场经济规律设计运营与服务的供需对接与价值分配」（b1802、b1803）。

供需对接的市场化体现在三点。一是价格由供需形成而非一刀切定价：数据集的定价由提供方设定、经可运营维度审批、在挂牌页公开，用户可比较同类数据集的价格与质量；运营方按季度公布各数据集的订单量与收益情况（对提供方可见），为定价调整提供参考。二是需求公开征集：平台设需求发布区，用户可发布未被满足的数据需求，有能力的供给方应征，运营方撮合；需求发布区的数据在实践中还有一项作用，它直接告诉运营方下一批该建什么数据集。三是服务可比较：同类服务允许多个供给方并存，由用户选择，不做行政指定。

价值分配的市场化靠清算规则承载（见 1.5.2 节）。规则的设计原则是「贡献越靠前、分配越靠后」：原始数据提供方按固定比例或阶梯比例取得稳定分成，加工与评测贡献方按投入量取得分成，平台运营方取得服务费并承担平台运行成本。阶梯比例的作用是让持续供给高价值数据的主体获得递增的分成比例，这是对长期供给的回报。

市场化运作有一条边界必须说明：平台承担行业公共服务职能，公益性服务不以收益为目标（见 2.6 节）。公益与商业的比例由运营组织决策层按年审定，并在清算报表的服务类型收入表中单独呈现（见表 2.4-13），使二者的平衡状况可被审议。

2.2.5　与行业特性的适配

招标文件要求「确保运营体系适配矿山装备制造行业特性，与行业业务场景深度结合」（b1804、b1805）。矿山装备制造的四条业务特征对运营体系提出了具体要求，逐条对应如下。

按订单设计的产品组织方式，意味着行业数据的复用价值集中在「相似工况下的历史案例」。运营体系因此把检索能力作为重点：选型类数据集须支持按工作面条件检索相似历史项目，而不只是按关键词检索文档。这一点落在 1.2 节的检索与预览模块。

小三机与大三机协同带来的成套责任，意味着接口参数类数据天然是多方共有的。运营体系因此把按份共有与多方分账作为常规机制而不是例外处置（见 1.5.5 节）。

长周期多工序跨车间的制造过程，意味着制造过程数据的汇聚是持续的而不是一次性的。运营体系因此把动态更新与增量汇聚作为常态安排（见 2.1.2 节），而非项目期内汇聚一次了事。

交付后长期在役服务，意味着产品质量数据的时效性要求高、来源在用户侧。运营体系因此把下游用户的数据回流作为激励机制的重点对象：在役运行与故障数据由煤矿企业回流，回流方按贡献取得服务权益与优先获取权（见表 2.4-21）。这条回路还解决了一个长期难题——远程运维平台报警不少、故障标签很少，报警与真实故障之间缺少可核对的证据；用户回流维修事实，正是在补这批标签。

2.3　数据集运营架构建设要求（3.2.6.6.3）

2.3.1　运营架构的构成与责任落点

运营架构回答一项服务如何被组织出来、由谁的专业能力承担、谁对交付质量负责，与 1.1 节的技术架构（系统由哪些层与哪些模块构成）是两件事。招标文件的要求是「以数据集运营平台为依托，联合数据集建设各相关方专业能力，面向行业用户提供专业化、定制化服务」（b1806、b1807），落点在联合各方能力与明确服务边界两处。

两处落点在运营中是一体的：联合各方能力意味着一项服务的交付链上有多个承担方，出现问题时须能分清责任归属；边界不清的联合运营，结果是用户找不到对接人、各承担方互相推诿。运营架构因此把服务边界、协作接口与质量责任（b1812）作为设计内容本身——服务边界按交付物划分，协作接口按交接单落地，质量责任按交付物归属，三者的具体规则见 2.3.5 节。

2.3.2　以运营平台为统一依托

招标文件要求「以数据集运营平台为统一依托，构建支撑各类运营服务的总体架构」（b1808）。统一依托有三项具体含义，三项都已在前九章落地，此处汇总说明它们在运营架构层面的作用。

第一，统一入口。所有服务无论由谁承担，都从运营平台下单、在运营平台跟踪、经运营平台交付、由运营平台结算。用户不需要知道背后是谁在做，也不需要分别对接多个承担方。这是「专业化服务」在用户感受上的起点。

第二，统一凭证。服务的每一个关键节点都在平台上留下凭证：订单、授权、交付清单、验收意见、服务纪要、清算明细。出现争议时以平台凭证为准，不以各方的内部记录为准。

第三，统一考核。各承担方的服务质量按同一套指标考核（见 1.7 节），考核结果进入服务质量报告，并作为后续服务分派的依据。这一条把「联合」从一次性协作变成有反馈的长期机制。

2.3.3　五类专业能力的整合

招标文件要求「联合数据集建设各相关方，整合其在数据采集、数据标注、模型训练、智能体开发、数据集评测等环节的专业能力实施专业服务」（b1809、b1810）。五类能力在本项目中的承载与对外服务形态如下。

表 2.4-23　五类专业能力的整合与服务边界。数据来源：招标文件 b1809、b1810、b1811、b1812；本包范围边界依据第 01 包「数据加工生产服务」的服务范围界定（b0804r06）。

表中第四行需要特别说明：本包的建设范围是数据集加工生产、质量评测与场景验证，智能场景建设不在本包范围内。智能体开发在此处作为运营期面向行业用户的对外服务能力列出，与本项目建设期内甲方场景的建设责任是两件事，运营架构中列此项，是为向行业用户提供定制化的数据服务与智能体开发服务。

2.3.4　定制化服务的组织方式

招标文件要求「面向行业用户提供定制化的数据服务与智能体开发服务」（b1811）。定制化服务与标准服务的差别在于：标准服务是「货架上拿」，定制服务是「按需做」，后者需要一套从需求到验收的组织流程。我方按五步组织。

需求受理。用户通过平台提交定制需求，内容包括业务目标、数据范围、交付形态、时间要求、预算区间。运营管理员在 2 个工作日内完成初步评估并反馈可行性判断。

方案设计。由运营管理员召集相应专业能力的承担方共同出方案，方案内容包括实施路径、交付物清单、里程碑、验收标准、所需用户侧配合事项、报价。方案须明确哪些环节由哪类专业能力承担，以及各环节的质量责任。

合同与立项。方案确认后签订合同、在平台生成订单与服务工单，按先行交付的节点模型（见表 2.4-9）拆分里程碑。

实施交付。按节点执行，每个节点出具交付物与验收记录。过程中的沟通、材料、纪要统一在服务工单下归集（见 1.4.5 节）。

验收与评价。按合同约定的验收标准逐项验收，验收通过触发清算，用户在节点后进行评价，评价进入服务质量报告。

2.3.5　服务边界、协作接口与质量责任

招标文件要求「明确架构中各相关方的服务边界、协作接口与质量责任」（b1812）。我方的处置方式是把这三件事写成一份《服务协作规范》，作为运营制度的一部分交付，其核心内容如下。

服务边界按「交付物」划分而不按「工作内容」划分。每一类专业能力的承担方对一份或几份明确的交付物负责，交付物有名称、格式、质量判据与验收方。这样划分的好处是边界可验证：交付物在不在、合不合格，看得见。按工作内容划分则容易出现「我做了但没做好算谁的」这类扯不清的情形。

协作接口按「交接单」落地。上游向下游交付时提交交接单，内容为交付物清单、质量自检结论、已知问题与限制、下游需注意事项。下游在约定时限内完成接收检查并签回，接收检查不通过的退回并说明具体缺项。交接单在平台上流转并留痕，这是追溯责任的依据。

质量责任按「谁的交付物谁负责」确定，并有两条补充规则。一是上游问题下游未检出，上游承担主要责任、下游承担检查责任，责任比例按交接单中约定的检查项范围判定。二是因用户侧输入不实或配合不到位导致的问题，由用户承担，这类情形须在交接单或服务纪要中有记录，不能事后主张。

图 2.4-11　运营架构：服务组织与责任链

图 2.4-11　运营架构：服务组织与责任链。数据来源：招标文件 b1807—b1812。

2.4　数据集运营盈利模式建设要求（3.2.6.6.4）

数据集运营盈利模式针对矿山装备制造领域不同类型、不同需求层次的用户实施差异化服务供给，在履行行业公共服务职能的同时实现商业价值（b1813、b1814）。

2.4.1　公益职能与商业价值的分账安排

招标文件对盈利模式的要求有一个前提条件：「在履行行业公共服务职能的同时实现商业价值」（b1814）。这两件事存在张力——公共服务要降低门槛，商业价值要有收入。处理这个张力的常见做法是把两者分开算账：公共服务由项目投入与行业支持维持，商业服务自己挣钱并补贴公共服务部分。我方采用这一思路，并在平台上把二者的账分开记录（见表 2.4-13 服务类型收入表），使「补贴了多少、够不够」在报表上能看出来。

2.4.2　客户需求分层与差异化服务策略

招标文件要求「梳理行业客户的不同需求并据此制定相应的服务策略，形成差异化服务供给体系」（b1815、b1816）。矿山装备制造行业的用户差别很大，一套服务策略套不上所有人。我方按需求特征分四类用户。

表 2.4-24　四类用户的需求特征与服务策略。数据来源：招标文件 b1815、b1816、b1817、b1838。

中小企业这一类值得多说一句。矿山装备制造产业链上的中小配套企业数量多，它们的共同困难不是没有数据，而是没有能力把数据变成可用的数据集。对这类用户，卖数据集的价值不如出租加工能力——这正是 1.4.4 节的平台能力交付（b1182、b1183）在商业上的意义：中小企业按年租用一个租户，用平台的工具链加工自己的数据，单次投入远低于自建环境。

2.4.3　服务内容与方式的分层设计

招标文件要求「对服务内容与服务方式实施分层设计，区分公益性公共服务与增值、定制服务」（b1817、b1818）。三层的划分与边界如下。

公益层不收费或仅收取必要的成本性费用，内容包括：行业数据集目录与元数据的公开查询、基础数据集的受限使用（配额受限、仅限非商业用途）、行业标准与规范文本的查阅、标注规范与数据集构建方法的公开、行业数据月报与年报。公益层的服务对象以行业中小企业、科研与标准机构为主，服务量按季度统计并进入服务类型收入表。

增值层按标准定价、按量计费，内容包括：标准数据集的商业授权使用、数据服务接口调用、评测服务、平台能力租用、标准培训。增值层是平台的主要收入来源，其定价与计费规则在挂牌时公开，用户可自助完成从选购到交付的全过程。

定制层按合同定价，内容包括：定制数据集建设、专项数据服务开发、现场数据治理与标注咨询、智能体开发服务、专属级运维支持。定制层的客单价高、交付周期长，按先行交付的节点模型管理（见表 2.4-9）。

三层之间有明确的转化设计：公益层的用户在使用过程中产生更具体的需求时，自然进入增值层；增值层的用户需求超出标准服务范围时，进入定制层。平台在公益层服务中记录用户的使用偏好与未满足需求（需求发布区），作为增值与定制服务的线索来源。这是「以服务养服务」的前半段。

2.4.4　营收目标分解与计费方式

招标文件要求「实现营收目标的分解与盈利模式的制定，明确各类服务的计费与价值转化方式」（b1819、b1820）。

营收目标按三级分解。一级按年度总目标分解到四个服务类别（标准数据集授权、数据服务接口、平台能力租用、定制服务）。二级按服务类别分解到季度，并按数据集大类分配——哪类数据集预期贡献多少收入，这个分配同时是数据集建设优先级的参考。三级按季度目标分解到运营执行层的具体责任，形成季度运营计划。目标值、实际值、达成率与偏差归因在营收目标达成表中按月呈现（见表 2.4-13）。

各类服务的计费方式如下。

表 2.4-25　各类服务的计费方式与价值转化逻辑。数据来源：招标文件 b1819、b1820、b1821；具体价格体系与年度营收目标值在运营筹备阶段由运营组织决策层审定后发布，本表只给计费方式与价值转化逻辑，不预设价格。

表中最后一行需要说明：公益服务不产生直接收入，但它带来两样对盈利模式有实际作用的东西。一是数据回流——公益用户在使用数据集时提交的反馈与回流数据，是数据集迭代的输入（见 2.1.4 节）；二是行业影响力——行业内的使用面扩大之后，增值与定制服务的潜在客户基数才会扩大。这两样在账面上记不出来，但在运营上是公益层存在的理由。

2.4.5　「以服务养服务」的循环机制

招标文件要求「形成『以服务养服务』的可持续良性循环机制」（b1821）。这个循环要真正转起来，需要四个环节都有机制支撑，缺一环就会断。

第一环，服务产生收入。增值层与定制层的收入按清算规则归集，平台运营方的服务费部分进入运营资金池。

第二环，收入反哺数据集建设。运营资金池按年度预算分配，其中一部分定向用于数据集的更新与新建。分配依据是数据集收益表（见表 2.4-13）：被频繁使用、收益高的数据集优先获得更新投入；长期无人使用的数据集降低投入或转入归档。这一条让投入跟着真实需求走，而不是跟着建设计划走。

第三环，数据集质量提升带来服务价值提升。数据集更新后质量结论与适用范围改善，可支撑更高的定价或更多的服务形态。质量结论由评测环节出具（见数据集质量评测分节），不由运营方自评。

第四环，服务价值提升带来更多用户与更多数据回流。用户增加带来更多使用反馈与回流数据，回流数据进入下一轮加工，形成数据资源的自我丰富。

图 2.4-12　「以服务养服务」的循环与断点防范

图 2.4-12　「以服务养服务」的循环与断点防范。数据来源：招标文件 b1819—b1821；数据集收益表口径见表 2.4-13。

循环中最容易断的是第二环。常见的情形是收入进了总账、建设按原计划走，两者不挂钩，于是收益高的数据集得不到更新、无人使用的数据集还在投入。我方的处置是把数据集收益表作为年度预算分配的硬性输入，分配方案须在运营组织决策层的会议上对照收益表逐项说明。

2.5　运营组织架构建设要求（3.2.6.6.5）

运营组织架构由组织架构与职位设置、议事规则与表决规则、权责与制衡安排、日常执行机制四项构成，实现平台重大事项的科学决策、专业领域的权威把关与日常运营的高效执行（b1822、b1823）。人员编制与岗位配置见项目团队分节。

2.5.1　决策、把关、执行三个层级的划分

招标文件要求组织架构「实现平台重大事项的科学决策、专业领域的权威把关与日常运营的高效执行」，并明确覆盖决策、把关、执行三个层级（b1823、b1824、b1825）。三层分设的原因是三类事项的性质不同，混在一起必然出问题。

重大事项的特点是影响范围广、不可逆、涉及多方利益，例如价格体系、公益与商业的比例、清算规则、对外接入的推进节奏。这类事项需要集体决策，决策慢一些可以接受，决策错了代价大。专业事项的特点是需要专业判断而不是利益平衡，例如数据集的质量是否达标、某份数据的权属与合规是否成立、标注口径是否正确。

这类事项交给票数表决会出错，必须由专业人员判断并对判断负责。日常事项的特点是量大、时效要求高，例如订单处理、工单响应、交付跟踪、对账差异处理。这类事项需要授权到人、按流程快速处理，每件都上会就会瘫掉。

2.5.2　组织架构与职位设置

招标文件要求「设计组织架构与组织职位」（b1824、b1825）。三层的构成与职责如下。

决策层设数据运营管理委员会。委员会由链主企业的主管领导担任主任委员，成员包括链主企业业务与职能部门的负责人、平台运营负责人，并设外部委员席位供产学研用各方代表参与。委员会的职责范围为七项：审定年度运营计划与营收目标、审定价格体系与清算规则、审定公益与商业服务的比例、审定数据集建设与更新的年度投入分配、审议重大合作与对外接入事项、审议权属争议的处理结论、听取季度运营情况与服务质量报告。委员会下设秘书处，承担议题征集、材料准备、会议组织与决议跟踪。

专业把关层设三个专业委员会，分别对应质量、合规、技术三类专业判断。数据质量专业委员会负责数据集质量门槛的设定、质量争议的裁定、质量评测方法的审议。合规与权属专业委员会负责敏感数据判定、权属登记争议的专业意见、对外运营合规性的审查意见。技术专业委员会负责技术方案的评审、工具链与平台能力的技术把关、对外接口规范适配的技术判断。三个专业委员会的成员从数据标准专家库中按议题遴选（专家库的构成、入库标准与考核机制见技术创新分节），每个议题的评审人不少于 3 人。

执行层设运营中心，按职能分四个组。运营服务组负责数据集上架运营、订单处理、用户服务与工单响应。交付保障组负责线上交付的监控与异常处置、线下服务的组织与节点管理。清算结算组负责清算规则配置、清算执行、对账与分账。平台运维组负责平台运行监测、SLA 指标管理、安全与审计配合。四个组的负责人向运营中心负责人汇报，运营中心负责人向委员会报告。

表 2.4-26　运营组织架构、职责与产出。数据来源：招标文件 b1823—b1829。各组的人员编制与岗位要求见项目团队分节。

2.5.3　议事规则与表决规则

招标文件要求「制定组织议事规则与表决规则，保障重大事项决策科学、专业把关权威」（b1826、b1827）。

决策层的议事规则按五条设定。第一，议题须提前 5 个工作日提交并附完整材料，材料包括议题背景、方案与备选方案、影响分析、相关专业委员会的意见。未附专业意见的议题不上会——这一条是把「专业把关」前置到决策之前，避免委员会在没有专业判断的情况下表决。第二，会议有效须有半数以上委员出席，涉及价格、清算规则、公益比例三类议题须有三分之二以上委员出席。

第三，表决采用一人一票，过半数通过；前述三类重大议题须三分之二以上同意通过。第四，委员与议题有利益关联的，在该议题表决中回避，回避情况记入会议记录。第五，决议形成后 3 个工作日内形成决议文件并下发执行，决议的执行情况由秘书处跟踪至关闭并在下次会议上报告。

专业把关层的议事规则不同于决策层，这是「权威把关」的要求所决定的。专业判断不采用多数表决，而采用「独立评审＋意见分歧上升」的方式：每个议题由不少于 3 名专家独立出具意见，意见一致时直接形成结论；意见不一致时增加评审人或组织面对面评审，仍不一致的议题提交决策层，由决策层决定是否暂缓或采用保守口径处理。专业意见须署评审人意见编号并说明依据，意见与结论随事项永久保存。合规与权属类的一票否决项（见表 2.4-6）在专业把关层即生效，不进入决策层表决——合规不是可以投票决定的事。

执行层的议事规则以例会与授权清单落地。日例会处理当日事项与异常，周例会处理跨组协同与指标回顾，月例会处理服务质量报告与改进措施。授权清单规定每个岗位可以自行决定的事项范围与限额，超出范围的上报。授权清单按季度复核，复核依据是实际发生的上报事项中有多少本可以在授权范围内解决——上报过多说明授权过紧，越权过多说明授权过松。

2.5.4　权责清晰与相互制衡

招标文件要求「确保组织架构中不同角色之间权责清晰、流程顺畅、相互制衡」（b1828）。制衡的设计体现在四处分离。

审批与执行分离。数据集的审批由专业把关层与审批专家承担，上架发布的执行由运营服务组承担。审批通过的数据集，运营服务组按流程执行上架；运营服务组不能自行决定上架未审批的数据集。

运营与清算分离。订单与交付由运营服务组、交付保障组处理，清算与分账由清算结算组处理。两组互为复核：清算结算组在生成清算明细时核对订单与交付记录的完整性，运营侧在月度对账中核对清算执行情况。

运营与审计分离。平台运维组配合审计，但审计职责由独立的审计员承担（见表 2.4-4），审计员不受运营中心管理，审计报告直接提交决策层。

规则制定与规则执行分离。清算规则、价格体系、SLA 阈值由决策层审定，运营中心按规则执行；运营中心可以提出规则调整建议，但不能自行调整。平台在技术上支撑这一分离：规则配置项的修改权限与业务操作权限分属不同角色，规则变更须有决议编号作为依据，无依据的变更被系统拒绝。

四处分离的共同点是：关键动作的发起方与审核方不是同一个角色，且动作留痕可查。这比写一条「加强监督」的原则有用。

2.5.5　日常运营的高效执行机制

招标文件要求「建立日常运营的高效执行机制」（b1829）。高效的来源是三件事：标准化、自动化、责任到人。

标准化方面，运营中心的日常事项编制作业手册，覆盖上架受理、订单异常处置、工单分级与派单、交付异常处置、对账差异处理、服务报告编制六类高频事项。手册内容为处置步骤、判断标准、时限要求、上报条件。作业手册作为运营制度文件交付，并在平台上以操作提示的形式嵌入对应界面。

自动化方面，凡可以由系统判断的事项不进入人工队列。平台已设计的自动化点包括：线上交付的授权自动生成、支付回调的自动核销、清算明细的自动生成、SLA 指标的自动计算、服务报告的自动生成、超期事项的自动派单、对账的自动比对。人工只处理自动化处置不了的例外，这是执行层人员配置能够控制在合理规模的前提。

责任到人方面，平台上每一个待办事项都有唯一责任人与时限，责任人由派单规则确定而不是由人认领。待办的完成情况进入个人与小组的运营看板，超期事项自动升级至组负责人。月度例会上回顾的是待办的按时完成率与升级次数，而不是工作量的描述。

2.6　公共服务内容体系建设要求（3.2.6.6.6）

公共服务内容体系覆盖数据流通全链条，按数据资源供给、技术工具赋能、知识智力支撑、价值转化通路四类组织，坚持公益导向、能力输出、生态共建（b1830、b1831）。

2.6.1　公共服务的定位与原则

招标文件要求坚持「公益导向、能力输出、生态共建」原则，设计并构建覆盖数据流通全链条的公共服务内容体系，履行平台「国家级行业数据智能基座」定位，降低行业企业数字化转型门槛（b1831）。

降低门槛这件事要落到具体的门槛上才有意义。矿山装备制造产业链上的中小企业面对数据智能化，实际卡在四道门槛上：没有可用的行业数据，自己采集与标注的成本承担不起；没有加工能力，缺少工具也缺少懂行的人；没有判断标准，不知道自己的数据够不够用、模型效果算不算好；没有流通通道，数据有价值也不知道怎么变成收益。

这四道门槛对应招标文件要求的四类公共服务——数据资源供给、技术工具赋能、知识智力支撑、价值转化通路（b1832—b1837）。这个对应关系不是巧合，招标文件的四类划分本身就是按门槛划的。

2.6.2　数据资源供给类公共服务

招标文件要求「建立数据资源供给类公共服务，面向矿山装备制造全行业提供基础数据资源支撑」（b1832、b1833）。

供给内容分三档。开放查询档面向所有注册用户，内容为行业数据集目录与元数据的公开查询、数据集卡片的查阅、样本受控预览。这一档不需要审批，注册即可使用，目的是让行业企业先知道有什么。受限使用档面向经资质核验的行业企业与科研机构，内容为基础数据集的非商业用途使用，配额按用户类型分档，用途限定在内部研究、教学、标准验证与非商业性模型训练。

这一档需要申请与承诺，走零金额订单链路（见 1.3 节表 2.4-8）。专题供给档按行业共性需求组织，例如面向中小配套企业发布的「零部件工艺基础数据专题包」、面向行业评测需求发布的「基准评测公开子集」。专题包按年度计划组织，内容与发布节奏由决策层审定。

供给的边界必须写清楚：涉及链主企业产品技术信息、商业秘密、客户信息的数据集不进入公共服务供给范围；进入供给范围的数据集经去标识化或脱敏处理，并经合规与权属专业委员会判定（见表 2.4-6 安全合规维度）。公共服务不是把数据无条件放出去，而是在确定的边界内尽可能降低使用门槛。

2.6.3　技术工具赋能类公共服务

招标文件要求「建立技术工具赋能类公共服务，向行业输出数据加工与智能化技术工具能力」（b1834、b1835）。

这一类服务的形态是能力租用与任务代做，而不是工具交付。本项目建设的 9 类 25 个专项智能工具链是本项目的核心技术资产（清单与能力见工具链分节），对外输出采用两种方式：一是平台能力租用，行业企业租用租户后在平台环境内使用工具链加工自有数据（见 1.4.4 节）；二是加工任务服务，企业提交数据与加工要求，由平台执行后返回成果（见 1.2.12 节）。两种方式下工具链本身不离开平台，这既保护了技术资产，也保证了加工口径的一致性——工具链在平台内由统一版本执行，加工结果可比。

这一类服务的公益部分体现在起步门槛上：对行业中小企业提供免费的试用额度与首次加工任务的成本价优惠，使企业在小规模投入下先验证效果。试用额度按年度公益服务预算分配，分配情况进入服务类型收入表（见表 2.4-13）。

工具能力的输出还包括方法与规范的公开。数据标注规范、数据集构建方法、质量评测方法这三类内容以公开文档形式向行业发布，不收费。公开这些内容不会削弱平台的竞争力——规范是公开的，把规范落地执行的工具链与数据积累才是平台的价值所在。这项公开同时服务于标准验证与试点工作（见 b0804r06 第 2 项）。

2.6.4　知识智力支撑类公共服务

招标文件要求「建立知识智力支撑类公共服务，提供行业知识与专业智力支持」（b1836）。

知识支撑的载体是三类内容。行业知识库汇集矿山装备制造领域的标准、规范、技术手册、工艺知识与故障案例，以可检索、可问答的形式对行业开放（基础检索与问答免费，深度服务按增值层计费）。行业数据报告按季度发布，内容为行业数据资源的汇聚与使用情况、数据质量的行业分布、典型应用效果，为企业的数字化决策提供参考。方法指南面向具体问题发布实操性文档，例如图纸类数据的解析与标注方法、设备时序数据的质量问题识别方法、小样本场景下的数据构建方法。

智力支撑的载体是数据标准专家库与咨询服务。专家库的专家按议题为行业企业提供咨询，咨询形式包括线上答疑、专题讲座、现场诊断三类。线上答疑与专题讲座属公益层，现场诊断属增值或定制层。专家库的建设与考核机制见技术创新分节，本节只说明其在公共服务体系中的作用：它是把分散在少数资深人员头脑中的行业经验组织起来对外输出的机制。

人才培养是智力支撑的延伸。平台面向行业提供数据治理、数据标注、数据集构建三类培训，培训教材与课程体系在项目期内形成并持续更新。培训的公益部分面向中小企业与院校，增值部分面向有定制需求的企业。培训的具体安排与课程清单见售后服务分节的培训方案，本节不重复。

2.6.5　价值转化通路类公共服务

招标文件要求「建立价值转化通路类公共服务，打通数据要素流通与价值转化路径」（b1837）。

通路的第一段是「让数据能挂出来」。行业企业的数据要变成可流通的资产，第一步是完成登记、确权与质量判定。平台把这一段作为公共服务提供：为行业企业的数据集提供登记注册、确权登记、质量预评估与挂牌指导，收取必要的成本性费用或在年度公益额度内免费。这一段的价值在于，很多企业的数据不是没价值，而是缺一套能被交易对手认可的凭证。

通路的第二段是「让数据能卖出去」。平台提供挂牌展示、需求撮合、交易合同模板、在线签署与清算分账服务（见 1.2 节至 1.5 节）。对首次挂牌的企业提供挂牌辅导，内容包括定价参考、许可条款选择、适用边界的披露要求。

通路的第三段是「让数据能走出去」。平台提供面向国家数据基础设施的接入服务：为行业企业的自有数据集提供对外接入的技术支撑与合规支撑（见 2.7.2 节）。这是单个企业自己很难完成的事——接入规范的理解、字段映射、标识申请、合规凭证的准备，对中小企业而言门槛过高，由平台统一承担更经济。

表 2.4-27　公共服务内容清单与收费口径。数据来源：招标文件 b1831—b1838、b1843。年度公益服务预算与各项额度由决策层按年审定，审定后在公共服务目录中公布并按季度披露执行情况。

2.6.6　公益导向与生态共建

招标文件要求「坚持公益导向与生态共建，推动行业数据要素的流通与共享」（b1838）。公益导向在本方案中有三项可核查的落地安排。

一是公益服务量的统计与公开。公益层的服务量（服务用户数、数据集使用次数、培训人次、咨询次数、辅导企业数）按季度统计并在服务类型收入表中单列，年度向决策层报告。公益服务量是运营组织的考核指标之一，与营收指标并列。

二是公益预算的制度化。年度运营预算中单列公益服务预算，预算规模由决策层按年审定，不随商业收入波动而临时削减。预算用尽时可申请追加，削减须经决策层表决。

三是公益与商业比例的定期审议。服务类型收入表按季度提交决策层审议，审议内容是公益与商业的比例是否偏离既定方针。偏离过多时调整价格体系或公益额度。这是把「公益导向」变成一个被定期检查的指标，而不是一句写在文件上的原则。

生态共建的落地是三项机制，均已在前文论述，此处只说明它们在生态层面的作用：数据协同汇聚机制（2.1 节）让产业链各方都成为数据的供给方而不只是使用方；产学研用协同创新机制（2.2.3 节）让高校与科研机构的方法研究能够落到行业实际数据上；汇聚激励机制（表 2.4-21）让贡献数据的主体获得回报，使共建有持续的动力。三者共同作用的结果，是平台上的数据与服务不只来自链主企业一家。

2.7　接入国家数据基础设施要求（3.2.6.6.7）

接入国家数据基础设施按制定技术方案与组织实施两步推进，实现平台生成数据集与行业用户自有数据集的高效流通与资产化运营（b1839、b1840）。平台侧的三类接口预留与联调安排见 1.8 节。

2.7.1　接入实施的技术方案

招标文件要求「制定接入国家数据基础设施的技术方案，优先采用成熟技术与产品并开展必要的技术开发实施」（b1841）。我方的技术路线以接入连接器为落地载体。

采购清单中列有接入连接器 3 台，功能要求覆盖数据接入、数据资源、数据登记、数据接口、数据交付、审核管理、系统日志、日志分析、日志审计、身份管理、配置中心、区块链存证、运行监测管理、访问控制（见硬件分节 b2150r03）。

这些功能与运营平台的能力有交集，我方的分工口径是：运营平台负责数据集的运营管理与交易履约，接入连接器负责对外流通侧的接入、登记、存证与通道管控。两者通过内部接口对接，运营平台不绕过连接器直接对外，连接器不承担运营管理职能。3 台连接器按一主一备一测试部署，测试节点用于规范变更时的预验证。

安装适配与国密调试属于系统集成范围（b0804r05），由集成分节统一安排，本节只约定运营平台侧的配置与联调口径：连接器接入前，运营平台须完成目录字段映射配置、主体标识映射表、接口鉴权配置三项；联调按「接口连通—数据格式校验—业务流程贯通—异常场景验证」四步执行，每步出具联调记录。

技术选型上，优先采用已在数据流通领域形成实践的成熟方案：传输与存证采用国密算法与已有存证服务能力，不自研密码与存证组件；目录与元数据的结构化格式采用公开标准；数据集标识的本地解析缓存采用成熟的键值存储。需要自行开发的部分限于映射适配层与业务协同逻辑，开发量可控，这是「优先采用成熟技术与产品」在本项目中的具体含义（b1841）。

2.7.2　两类数据集的接入

招标文件要求支持「平台生成数据集与矿山装备制造行业用户自有数据集的接入」（b1843）。两类数据集的接入路径不同。

平台生成的数据集已在平台内完成登记、确权、审批与挂牌，接入时只需补充对外发布所需的目录字段并申请标识，权属与许可信息直接取自确权记录。这条路径的工作量主要在字段映射与标识申请。

行业用户自有数据集的接入路径更长。用户先在平台完成注册与确权登记，经审批通过并挂牌，才具备对外接入条件。这里有一处设计选择需要说明：我方把「先入平台、再对外接入」作为唯一路径，不提供用户数据集绕过平台直接接入的通道。原因是对外接入意味着平台对该数据集的合规状态作出背书，没有经过平台审批与确权的数据集，平台无法承担这个背书。对用户而言这增加了一道流程，换来的是其数据集在对外流通时有完整的权属与质量凭证。

2.7.3　可信流通与资产化运营

招标文件要求「实现数据集在国家数据基础设施中的可信、高效流通」（b1844）与「支撑数据集在国家数据基础设施中的资产化运营」（b1845）。

可信流通依托三样东西：版本指纹、确权记录、存证摘要。数据集对外流通时，随同提供版本指纹与确权凭证，接收方可据此验证所取得的数据集是否为登记版本；登记、确权、挂牌、交付四类关键事实的摘要写入存证账本，流通过程中的争议可据此比对。高效流通依托两样：目录与元数据的增量同步，使对外目录与平台内状态保持一致，避免挂着已下架的数据集；交付通道的分级设计（见 1.4 节），使大体积数据集走下载通道、敏感数据集走接口与任务通道，不以一种通道应付所有情形。

资产化运营的平台支撑体现在三处。数据集资产台账记录各版本的样本规模、模态构成、时效性占比、许可状态与使用情况（承接 b1573、b1574），台账是资产计量的数据基础。收益记录按数据集版本归集，数据集收益表（见表 2.4-13）回答每一份数据集的投入产出。许可与权属记录支撑数据集作为资产在交易、授权、入股等场景下的权利边界说明。资产化运营的财务与法务口径超出平台功能范围，平台负责把事实记准、把凭证留全，具体的资产化路径按甲方与监管要求推进。

3、采购清单相关条目的落实

采购清单中与数据集运营服务管理平台相关的条目，其配置数量、许可方式与落实安排如下。报价填写见商务分卷的报价明细表，技术指标的逐条应答见对应技术分节。

3.1　软件采购清单（3.1.1）

招标文件第 3.1 软件部分（b0690）下设软件采购清单（b0691），清单表头为序号、名称、单位、数量、备注五列（b0692r01）。清单实列一项：安全软件，1 套，备注说明「安全软件即商用密码服务平台。不限制使用节点数量（许可数量）」（b0692r02）。

我方的应答口径如下。该项按 1 套配置，提供的商用密码服务平台集密码服务、管理、态势感知于一体，统一调用底层各类密码软硬件资源，为上层应用提供真实性、机密性、完整性、不可否认性的密码服务（对应 b0694 的能力要求，详见安全分节）。许可方式按「不限制使用节点数量」提供，不按节点数、不按 CPU 数、不按并发数另行计费，许可范围覆盖本项目建设的全部系统与节点，并覆盖项目建设期内的节点扩展。

与本节运营平台的关系：运营平台的密码运算统一调用该平台提供的服务，不在应用内自行实现密码算法。具体调用点包括用户认证与会话保护、电子签章与时间戳（交易合同在线签署）、数据集下载包与接口传输的加密、版本指纹与存证摘要的签名、审计日志的完整性保护。调用关系已在图 2.4-2 资源与安全层标出。

3.2　服务采购清单（3.2.1）

招标文件第 3.2.1 服务采购清单（b0803）表头为序号、名称、单位、数量、备注五列（b0804r01），实列七项服务，每项 1 套。七项的应答与本节的关系如下表。

表 2.4-28　服务采购清单七项的应答与本节相关性。数据来源：招标文件 b0803、b0804r01—b0804r08。报价填写见商务分卷报价明细表。

关于第 7 项备注中的目标表述需要说明口径：招标文件原文使用了「全维度数据质量合规核验目标」「缺陷整改全闭环管控目标」等表述（b0804r08）。我方在技术方案中对应的承诺口径为：按评测方案设定的质量维度逐项核验，核验维度与判据在评测方案中列明；缺陷整改按「发现—归因—整改—复测—归档」五步管理，整改闭环率设基线并逐步提升，未在本轮闭环的缺陷转入下一轮并在质量档案中留痕。具体指标与基线见数据集质量评测分节。