交付物 B：元协议设计稿（草案 v0.2）

状态：草稿，未生效。本文档是设计稿，按 P-06，未经批准不得发布为正式版本。 建议归宿：定稿后以 P-01 v2.0.0 发布（吸收并扩展现行 P-01，MAJOR 变更，走 P-06 批准流程）。替代方案（新设 P-00）见交付物 E-2。 阅读对象：不了解项目背景的人。读完应能回答：这个体系是什么、由什么组成、怎么运转、边界在哪、怎么判断好坏。

第一章 体系定义

1.1 正式定义

数据产品体系（Constraint Lab 数据产品体系）是一套以"结构化、可溯源、可持续维护的数据产品"为产出的生产系统。它不是若干网站的集合，也不是一个工作台或一批脚本的集合，而是一个包含**规则（协议）、管理（控制）、操作（执行）、产品（模块）**四种职能的完整生产组织。

一句话：这个体系生产的数据产品，每一条事实都能回答"从哪来、谁验证的、什么状态、谁负责"；支撑它运转的规则、任务、状态各有唯一归属。

1.2 目标与核心目标

1.3 体系管理的对象

体系管理五类对象：数据产品（五个，将新增）、数据资产（各产品的 data/ 与来源）、任务（采集/校验/审核/发布等运行单元）、规则（全局协议→项目协议→模块契约）、公共能力（控制与执行的通用机制）。

1.4 输入—处理—输出—反馈

输入：   外部信息源（官网/文献/公开数据） + 所有者的决策与规则 + 人工录入
处理：   采集 → 结构化 → 校验闸 → 人工审核 → 发布（协议层定义规则，
         控制层决定时机，执行层实际操作，模块层定义业务语义）
输出：   面向人的网站 + 面向 AI 的 API/MCP + 面向所有者的状态看板
反馈：   健康探测、质量校验、任务结果、问题工单 → 回到"处理"与"规则"两层

1.5 体系 ≠ 网站 ≠ 仓库 ≠ 任务

• 一个数据网站只是模块层的一个用户入口；体系还包含它背后的数据资产、规则与维护机制。
• 一个代码仓库只是承载形式；一个仓库可含多层职责（五站仓库同时含模块层业务与执行层脚本），一个职责也可跨仓库。
• 一次数据任务只是执行层的一个动作；体系关心的是任务前后完整的规则依据、状态流转与证据链。

1.6 成功标准与基本约束

成功 = 第 1.2 节五个目标同时成立，且第 1.4 节循环在无人工干预下能维持"采集→校验"段、在有人工节点处有明确待办。基本约束：不虚构能力（没实现的不说有）；单一事实来源；变化可追溯（见第九章治理）。

第二章 体系组成与职责

九类组成部分。"必须检查"≠"必须建成独立服务"——每类都可以由现有系统承载。

2.1 元协议与全局规则

• 职责：定义体系是什么、四层边界、核心概念、全局/项目权限分界、健康验收原则、治理规则。
• 输入：所有者决策、实践反馈。输出：本协议及其修订。
• 不负责：具体任务怎么写、具体数据字段是什么。
• 现状：P-01~P-06 承担了大部分；本设计稿是其扩展候选。

2.2 专项协议、项目协议、模块契约与决策记录

• 职责：专项协议=某类横切事务（如任务执行）的细化规则；项目协议=单项目身份/范围/资产/管线（P-03）；模块契约=单模块 I/O 与替换边界（P-05）；ADR=不可逆架构决策的记录。
• 现状：模板齐备，项目协议 0/5；执行类专项协议缺失（P-07 候选）。

2.3 控制层（当前由 Data Workbench 承载）

• 职责：状态汇总（items/site-status/outcomes）、任务决策（何时允许/需要跑什么）、审核流程、失败登记与后续处理、通知。
• 输入：执行层结果、健康探测、人工录入。输出：任务指令、工单、看板、通知。
• 不负责：实际运行脚本；定义业务规则。
• 现状：已实现并部分验证（单项目闭环）；四站未接。

2.4 执行能力

• 职责：按契约实际运行任务；进程/超时/日志管理；结果与运行记录产出；版本对应。
• 现状承载：workbench 执行内核（runs/scheduler/exec/tasks/node-runs）+ 各项目 scripts/ + 各站 CI/CF 部署。目标承载（执行工作台独立化）仅为设计，未决策实施。
• 现状缺陷：无统一结果信封、无 gitSha 记录、接口为进程内约定。

2.5 数据产品（模块层主体）

• 职责：领域数据模型、业务规则、数据资产、采集来源定义、用户入口（网站）与机器入口（API/MCP）。
• 不负责：全局规则；其他产品的数据。
• 现状：五产品齐备；机器入口仅 CN 上线。

2.6 数据、来源、证据、业务规则与质量状态

• 数据必须有定义、来源、四态标记（P-04 §2.3：原始/处理/推断/已验证）；证据等级与验证规则由项目协议定义；质量状态由校验闸与人工审核共同产生。

2.7 对外访问能力（API/MCP）

• 职责：把模块层数据按 P-04 §2.5 声明的方式对外服务；AI 入口须自报家门（范围、语义、状态标注）。
• 现状：CN 三端已部署；BagComply/PoreWise 代码未部署；BB/WGL 无。

2.8 监测、验证、审核、发布、反馈与维护机制

• 监测=site-status 六维探测；验证=校验闸+构建闸+发布护栏；审核=人工节点（items/reviews）；发布=guarded 流程；反馈=notify+变更检测（sourceMonitoring）。
• 现状：机制齐备，但发布段生产未实战、四站未覆盖。

2.9 决策者（人）

• 所有者是体系的一部分而非外部：批准协议变更、处理 items 中标记需人工的事项、决定高风险操作。体系的目标是让人只出现在"必须人"的位置。

第三章 四层架构的正式定义

权威定义 = P-02（v1.0.0 正式生效）。本章不复述其全文，只做三点元协议级澄清与现状对照。

3.1 依赖方向与反馈回路

协议层 ──约束──→ 控制层 ──任务指令──→ 执行层 ──操作──→ 模块层
   ▲                                                    │
   └──────修订提议（实践反馈）                              │
                                                          ▼
        控制层 ←──结果/状态/异常反馈──────────────────────┘

• 依赖方向严格单向：下层不得修改上层规则；上层不得指定下层自主事项（P-01 §6）。
• 反馈回路两条：运行反馈（模块层→控制层，数据/状态回传）与治理反馈（任何层→协议层，规则修订提议）。
• 协议层对模块层的约束是间接的（通过项目协议），不直接指挥产品实现。

3.2 逻辑分层 ≠ 物理部署

四层是职责透镜。当前物理映射（现状事实）：

元协议立场：不因分层而强制拆分部署；也不因当前同进程而否认层间边界。控制/执行是否分离由专门 ADR 决策（见治理冲突 C2 的处理），本文档只规定：无论物理上怎么部署，控制职责不得执行任务，执行职责不得决策任务——这是逻辑边界，与部署无关。

3.3 各层"做什么/不做什么"一句话版

• 协议层：说什么算什么。不执行、不管理状态。
• 控制层：决定谁在什么时候做什么。不亲自做。
• 执行层：把它做了，留下证据。不发明规则、不做判断。
• 模块层：提供领域数据与业务语义。不受他人代管业务规则。

第四章 体系运行机制：一个数据产品的生命周期

九个环节，标注实现程度：【已实现并验证】/【部分实现】/【仅目标机制】。

新项目接入的标准路径（元协议规定，各环节细节由专项协议细化）： 定义项目协议（P-03 模板）→ 声明数据模型与来源规则 → 在 workbench 登记项目配置 → 首个任务以 read-only 类型试运行 → 结果经人工审核 → 逐步放开调度与 mutating 任务 → 定期复审项目协议。

第五章 核心概念与对象关系

5.1 概念表

5.2 五组不可混淆的区分（硬性条款）

1. 任务执行成功 ≠ 数据质量合格。 退出码 0 只说明程序正常结束；数据判定由校验闸与人工审核独立给出。
2. 数据采集成功 ≠ 已通过审核/允许发布。 采集产物一律先入待审区（inbox/changes）。
3. 项目启用（enabled）≠ 管线接通。 当前四站 enabled 而零运行记录即为实证——状态必须区分"配置启用"与"有运行证据"。
4. 页面构建成功 ≠ API/MCP/生产运行正常。 构建闸只覆盖静态产物；服务可用性由健康探测独立判定。
5. 缺失 / 未找到规则 / 信息不足 / 验证失败是四种不同状态，必须分别表达，不得合并为"失败"。此原则直接约束未来结果信封的字段设计。

5.3 对象关系图

项目 ──拥有──→ 数据实体 ←──定义── 业务规则
 │                ↑
 │                │产出
任务 ──运行──→ 运行实例 ──产出──→ 执行结果 ──附──→ 证据
 │                                  │
 └─授权自 控制层                      ▼
                              数据质量状态 / 审核发布状态 / 异常记录
                                    │
                                    ▼
                          items 工单（证据关闭）→ 健康状态

第六章 全局规则与项目自治边界

继承 P-01 §6 框架，按元协议需要细化：

6.1 必须全局统一（项目不得放宽）

1. 四层职责边界（P-02）与本章 5.2 五组区分。
2. 任务生命周期的共同概念：任务/运行实例/结果/证据的定义（第五章）。
3. 结果可追溯性：任何改数据的任务必须留下可查证运行记录，记录必须含执行时代码版本（目标态；现状缺 gitSha，属待补）。
4. 状态报告的基本义务：控制层能问"某项目最近任务跑得怎样、数据质量如何、有什么待处理"，且答案有证据。
5. 证据要求：items 关闭需证据；高风险操作需人工批准。
6. 变更管理：协议变更走 P-06；架构决策走 ADR。
7. 单一事实来源：同一规则只在一处正文定义（见第九章）。

6.2 项目自治（全局不指定）

技术栈、目录结构、内部校验闸数量与语义、数据字段、证据等级档位、发布条件、内部审核粒度、采集源选择、页面设计。

6.3 中间地带（需要决策的灰色区）

• 校验闸的"闸"概念（构建前必须过校验）是全局的；闸有几道、查什么是项目的。
• mutating 任务的人工确认是全局的；哪些任务算 mutating 由项目声明、控制层复核。
• 信封格式是全局契约；stats/checks 内容是项目的。

第七章 系统健康与验收标准

7.1 原则：状态必须由证据支撑，禁止单点绿色即判健康

一个绿色状态只证明一件事成立。判定"项目健康"需要下表多层证据同时成立。

7.2 三级健康矩阵

7.3 状态与验收的关系

• 每个状态字段必须能回答"这个状态谁产生的、依据什么证据"。
• "未验证"是合法状态且必须如实显示（P-04 §3.2 第 3 条的体系级推广）——BagComply 的 155 条 needsReview 是正确行为的范例而非待抹平的异常。
• 验收标准写进对应协议：全局验收原则在本章；项目验收条件在项目协议（P-03 §2.7）；任务验收在专项协议（P-07 候选）。

第八章 协议体系与演进治理

8.1 协议族结构

元协议（本文件，体系总定义）
 ├─ 全局专项协议：P-02 四层 / P-03 项目定义 / P-04 数据与AI / P-05 模块契约
 │                / P-06 版本演化 / P-07 任务与执行（候选，待立项）
 ├─ 项目协议 ×N（P-03 模板）
 │    └─ 模块契约 ×N（P-05 模板）
 └─ ADR 决策记录（跨层不可逆决策）

8.2 变更路由规则（改什么文件）

8.3 单一事实来源规则

1. 同一规则只在一处正文定义，其他位置只允许引用。
2. 引用必须带版本（如"依 P-02 v1.0.0 §4"），被引用文件升级导致语义变化时，引用方有义务复审。
3. 元协议与 P-01 的重叠由归宿决策消除（见 E-2）：无论合并还是编号并列，体系总定义的正文只存在一份。
4. 项目内部文档（如 workbench 的"六层"表述）不得与全局协议冲突；冲突时以全局协议为准或走 P-06 提案。

8.4 兼容、废弃与迁移

遵循 P-06 全文，元协议补充两条：

• 元协议 MAJOR 变更（体系定义/四层边界变化）必须同步评估 P-02~P-07 与全部已注册项目协议的影响，并在变更记录中列出迁移清单。
• 任何被替代的文档（如本设计稿、docs/03–07 设计档案）转为"档案"状态并标注替代者，不删除。

第九章 现状 / 目标 / 待建设 对照

第十章 与现有协议的关系声明

1. 本元协议不废除任何现行协议；P-02/P-03/P-04/P-05/P-06 原文继续有效，本文件通过引用与之衔接。
2. 本元协议与 P-01 的关系（吸收升级 or 并列编号）是待决策项，定稿时消除重叠（治理规则 8.3.3）。
3. 本文档当前为草稿：按 P-06 §6，可视为"实验性规则"对待——项目可参考反馈，不构成强制约束；转正需走批准流程。

（完）