> 译文仅供阅读便利。具有规范效力的是英文原文。 # 数据主控 **元宇宙规范** **文档编号：** MU-V2-ARCH-018 **标题：** 元模型架构标准 - 数据主控与记录系统 **文档类别：** 规范性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** MMAS-Core、MMAS-Package、Model-Traversal-and-Layout、Traceability **说明性引用：** Synchronization、Extension-Model、Provenance-Graph、AI-Agent-Guide **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 元模型很少独自存在。同一份知识往往还存在于 wiki（Confluence）、工单系统（Jira、ClickUp）、CRM、数据库或文档库中，而那些副本是由从不打开该模型的人在编辑。 本文档回答的，是决定这种并存究竟是秩序还是混乱的唯一问题：**对每一个数据集来说，主控方是谁 - 元模型，还是外部系统？** 它定义： - **记录系统（SoR）**：某个数据集的真相被写下的唯一场所； - 三种合法的**主控模式**（模型主控、外部主控、分区）； - **主控登记表**（`sources.yaml`）：上述一切的机器可读声明； - 由每种模式所导出的流向、新鲜度、冲突与写入规则。 没有这份声明，读者无从知道在模型中找到的某个事实是权威的，还是一份可能已陈旧的镜像；代理也无从知道订正该写到哪里。有了它，这两个问题都有机械化的答案。 --- # 2. 适用范围 本规范治理元模型与**同一治理域内的运营系统**之间的关系：wiki、工单系统、数据库、文件存储、业务应用。 它不治理： - **主权宇宙之间的联邦** - 那属于 [Synchronization](../03-federation/Synchronization.md) 与 MUFP（各方各有自己的记录系统；联邦从不转移主控）； - **导入的外部标准**（Schema.org、FHIR、ISO 词表）- 它们始终由各自的标准组织在外部主控，由 [Extension-Model](Extension-Model.md) 处理。 --- # 3. 设计原则 - **每个数据集只有一个主控方。**每个数据集恰有一个记录系统。「两边都算有点权威」按定义就是不合规。 - **主控是声明出来的，不是推断出来的。**任何读者都不该从文件夹名称、习惯或团队口耳相传中推断权威归属。 - **流向跟随主控。**数据从主控方流*向*它的各份副本；除了这条流向，副本永远不被写入。 - **副本是可丢弃的。**任何非主控副本都可以删掉，并从主控方无损重建。 - **溯源是强制的。**每一条被镜像的数据都知道自己从哪里来、什么时候来的。 --- # 4. 定义 - **数据集** - 作为一个单位被治理的一体化数据（一组对象、一棵页面树、一张表、一份登记表）。粒度由模型所有者选择；主控按数据集声明。 - **记录系统（SoR）** - 某个数据集在其中被*写下*、并且其状态在任何冲突中胜出的那个系统。 - **镜像** - 模型内部持有的、外部主控数据集的一份副本，由采集产生。 - **采集** - 把外部数据集捕获进模型的流水线（原始捕获加语义转换）。 - **回写投影** - 模型主控数据集的一份副本，为便于阅读、存储或处理而发布到外部系统。 --- # 5. 三种主控模式 ## 5.1 模式 M：模型主控 数据集**诞生于元模型**。事实直接在模型中写下（编辑、评审、像代码一样版本化）。外部系统收到的是**回写投影**：渲染后的页面、导出的表格、同步的记录，发布给那些更愿意在那里阅读的人和工具。 规则： - 流向永远是**模型 → 外部**。 - 每一份被投影的副本都必须标注为生成物：它声明自己的主控方、生成时间，以及以目标系统所支持的任何形式给出的「请勿在此编辑」提示（页面横幅、记录字段、文件头）。 - 在外部副本上所做的编辑**没有权威**。实现应当或者锁定外部副本，或者在下次发布时将其覆盖，或者把这类编辑捕获为*变更提议*并送回模型的正常变更流程；它不得悄然合并这些编辑。 - 发生任何冲突时，**以模型为准**。 *示例：一份在模型中撰写的架构决策登记表；Confluence 上承载的是它的一份生成的、只读的呈现，因为更广泛的组织生活在 Confluence 中。* ## 5.2 模式 E：外部主控 数据集**在外部系统中生存并变化**（团队每天更新的 Confluence 空间、工单系统、生产数据库）。模型持有一份**镜像**：一份经采集并加以语义结构化的副本，使模型能够链接、分类并对这些数据进行推理。 规则： - 流向永远是**外部 → 模型**。 - 采集必须把未加修改的捕获连同其溯源附属文件一起放入 `raw/<系统>/<数据集>/`，遵循 [Model-Traversal-and-Layout](Model-Traversal-and-Layout.md) §6；随后由语义转换填充模型各层中的镜像。 - 被镜像的内容在**模型内部是只读的**。订正应在外部系统中进行并重新采集；此外模型可以把带注记的偏差（「来源称 X，我们评估为 Y」）作为自己的、由模型主控的陈述记录下来，与被镜像的事实清楚分开。 - 每个被镜像的数据集都必须带有**新鲜度元数据**：上次成功采集的时间、声明的节奏，以及一个陈旧上限，超出该上限就必须向消费方发出警示。 - 发生任何冲突时，**以外部系统为准**；镜像通过重新采集来订正，绝不反向而行。 *示例：人工智能代理持续把一个活跃的 Confluence 空间采集进模型；模型添加结构、链接与分类，但页面本身是在 Confluence 中撰写的。* ## 5.3 模式 H：分区 该知识领域被切分：一部分数据集（或字段）由模型主控，另一部分由外部主控。这是现实中最常见的情形，而它只有在**分区是显式的**时才合法： - 每个分区都必须声明为拥有单一主控方（模式 M 或 E）的独立数据集。 - 同一个字段不得在两边都可写。对同一条数据的双向主控不合规；若确有必要，就把这条数据拆开（例如：外部系统主控 `status`，模型主控 `assessment`）。 - 跨分区引用是允许并且值得鼓励的；它们是引用，不是副本。 --- # 6. 主控登记表（`sources.yaml`） 每个合规仓库都必须在其根目录中放置一份主控登记表，覆盖**模型所持有或所镜像的每一个数据集**。未出现在登记表中的数据集，被视为由模型主控并完全在本地撰写；任何外部系统的参与若没有对应的登记条目，即为不合规。 每条条目都必须声明： | 字段 | 含义 | |-------|---------| | `id` | 稳定的数据集标识符 | | `description` | 这是什么数据，一句话 | | `master` | `model` 或 `external` | | `system` | 涉及外部系统时：系统名称、URL、范围（空间、项目、表） | | `model_location` | 该数据集（或其镜像）在仓库中的位置 | | `flow` | `model->external`、`external->model` 或 `none` | | `pipeline` | 搬运数据的采集器或发布器（工具、脚本、代理） | | `cadence` | 该流向多久运行一次；对镜像还包括 `staleness_limit` | | `conflict_rule` | 重申谁胜出，外加升级联系人（`steward`） | | `status` | 该流向的生命周期：`active`（默认）、`declared`、`suspended`、`retired` | **已声明条目。**真实的模型会经历一种过渡状态，而登记表必须能对它说真话：主控已经定下，但流向尚未建成 - 镜像位置存在却从未采集过，或回写已经商定却没有任何流水线在发布它。这类条目必须带有 `status: declared`。已声明条目是合法的，但它是**尚未偿还的债务，而不是运行中的机制**：已声明的镜像不得被呈现为新鲜（它根本没有采集时间），已声明的回写也不提供任何防漂移保护。通过省略该条目、或把它标为 `active` 来掩盖这一过渡状态，属于不合规；登记表存在的意义，正是让这种状态被看见。 一份同时包含两个 Confluence 方向的示例登记表： ```yaml datasets: - id: adr-register description: Architecture decision records master: model system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Architecture } model_location: bundles/architecture/decisions/ flow: model->external pipeline: tools/publish-adr-to-confluence cadence: on-change conflict_rule: model wins; external edits become change proposals steward: architecture-owner - id: ops-runbooks description: Operational runbooks maintained by the ops team in Confluence master: external system: { name: Confluence, url: https://wiki.example.com, scope: SPACE/Ops } model_location: bundles/operations/runbooks-mirror/ flow: external->model pipeline: tools/harvest-ops-runbooks cadence: daily staleness_limit: 7d conflict_rule: Confluence wins; fix at source and re-harvest steward: ops-lead ``` 这正是那份能够针对每一个数据集、机械地回答「有个 Confluence - 里面是什么，元模型和 Confluence 谁更权威？」的制品。 --- # 7. 冲突与漂移 - **检测。**实现至少应当在每次流向运行时检测主控方与副本之间的漂移（内容比对、指纹、时间戳）。 - **解决。**漂移**只**沿 `conflict_rule` 所声明的方向解决；逐案「凭判断」处理属于不合规。 - **升级。**无法机械解决的漂移（分区本身就划错了，主控方存在争议）交给该数据集的管护人；若主控发生变化，则产生一个新版本的登记条目 - 主控变更是被版本化的事件，绝不是悄然的编辑。 --- # 8. 新鲜度与信任 被镜像数据集的消费方必须能够不离开模型就看到：主控系统、上次采集时间，以及是否已超出陈旧上限。陈旧的镜像必须被标示，而不是被隐藏。取自陈旧镜像的陈述会把这份陈旧性带进自己的溯源；下游的信任决策（见 Trust-Model）可以据此加权。 --- # 9. 人工智能代理规则 与合规模型协作的代理： - **在依赖某个数据集之前**：必须查阅登记表；对镜像必须检查新鲜度，陈旧时宁可重新采集也不要猜测。 - **在写入之前**：必须只写入该数据集的主控方。对外部主控事实的订正要送到外部系统（或送给有权限的人）；对模型主控事实的订正则写进模型。写入副本无论多么方便都属于不合规。 - **在引用时**：应当点明主控方（「据 Confluence Ops 空间，采集于 2026-07-30」），而不是把镜像当作出处呈现。 正是这些规则，使人与代理混编的团队能够共同处理同一份知识，而不至于从任何一边把它弄坏。 --- # 10. 与其他标准的关系 - **[Model-Traversal-and-Layout](Model-Traversal-and-Layout.md)** 给镜像与投影安排物理位置（`raw/`、层内镜像、`artifacts/`）与来源（采集 / 生成）；本文档赋予它们权威。 - **[Synchronization](../03-federation/Synchronization.md)** 治理*跨越*主权边界的各方；本文档治理*同一主权之内*的各种工具。联邦从不移动主控；宇宙只公开它自己主控的内容，或明确标示为镜像。 - **[Extension-Model](Extension-Model.md)**：导入的标准是模式 E 的一种固定特例（主控方：标准组织；流向：版本化发布流入）。 - **[Traceability](Traceability.md) / [Provenance-Graph](Provenance-Graph.md)**：采集与发布的每次运行都是溯源事件；登记表告诉你政策，溯源图告诉你实际发生了什么。 --- # 11. 校验 结构校验（V1）必须检查：登记表存在、可解析，且每个所声明的 `model_location` 都存在。语义校验（V2）应当检查：每份镜像都有溯源与新鲜度元数据；没有文件在两条条目之下都可写；流向与主控方相符（`master: external` 绝不会配 `flow: model->external`）；并且每一条 `status: declared` 的条目都被报告为未偿债务。运行时校验（V5）可以拿实际采集历史来核对陈旧上限，并且应当把所声明节奏从未真正运行过的条目降级为 `declared`。 --- # 12. 架构不变量 主控必须保留： - 任一时刻每个数据集只有一个记录系统； - 主控变迁是被声明、被版本化的； - 每份镜像的溯源与新鲜度； - 每份非主控副本的可丢弃性； - 宪法合规。 主控绝不得仅凭物理位置来推定：位置给出的是默认读法，登记表给出的才是法律。 --- # 13. 未来方向 两项自然的扩展：一种**连接器档案**格式，用以描述常见系统（Confluence、Jira、Notion、关系型存储）的采集与发布流水线，使登记表可以引用有类型的连接器，而不是零散脚本；以及把登记条目呈现在**语义分发包**中，让打包模型的消费方一眼看出哪些部分是撰写出来的知识，哪些是别人 wiki 的镜像。 --- # 结语 每个数据集的真相都恰有一个归宿。主控登记表让这个归宿变得显式，流向规则让副本保持诚实，新鲜度规则则让读者对副本保持诚实。 一个声明了自己主控方的模型，可以安全地与 wiki、工单系统和数据库并存；不这样做的模型，离出现两个真相只差一次编辑。