# 数据主权归属

*构建元模型 · 第 4 课，共 6 课 · 约 15 分钟*

## 你将学到

这个问题决定了你的模型与你的 wiki 是有序共存还是一片混乱：对每一个数据集，谁是主？（ARCH-018。）

## 双真相病

你的模型描述产品。但运维手册住在 Confluence，任务曾住在某个追踪器，代码住在 GitLab，而人们每天都在编辑这一切。同一个事实一旦同时存在于两个可编辑的地方，你就有了两个真相，而每个读者都会悄悄挑一个。解药不是集中化（你不可能把运维从他们的 wiki 上迁走），而是**声明式的主权归属**：每个数据集恰好有一个记录系统，且机器可读。

## 三种合法模式

**以模型为主（回写）。** 数据集诞生于模型；外部系统拿到的是生成的、明确标记的只读投影，"仅供阅读方便"。流向：模型 → 外部。冲突：模型胜出；外部编辑无效，或转为变更提案。*活例：Orkestron.AI 的模型是其产品事实的主；公开站点提供一份生成的 `product-facts.json`，标注"请勿在此编辑"，并带内容哈希用于漂移检测。*

**以外部为主（镜像）。** 数据集在外部系统中存活与变化；模型持有一份采集来的镜像，以便链接、分类与推理。流向：外部 → 模型，经由一条把原始抓取（连同来源）落地并转换的流水线。镜像在模型内只读，并带有**新鲜度元数据**：上次采集、节奏、过期上限。冲突：外部系统胜出；你重新采集，绝不给镜像打补丁。*活例：持续更新的 wiki 空间，以 GitLab 为主的源码克隆。*

**分区式。** 诚实的混合情形：一些数据集以模型为主，一些以外部为主，各自分别声明。一条铁律：同一个字段绝不在两边都可写。如果你确实两边都需要，就把这个数据拆开（外部系统主 `status`，模型主 `assessment`）。

## 登记册：sources.yaml

仓库根目录的一个文件声明每一个数据集：主、外部系统与范围、在模型中的位置、流向、流水线、节奏、冲突规则、责任人，以及一个**状态**：`active`、`declared`（主权已定，流水线尚未建成：合法且可见的欠账）、`suspended` 或 `retired`。正是这份制品，为"有个 Confluence：里面装了什么，谁更权威？"这个问题提供了机械的答案，对每个数据集，永远有效。

## 与现实相遇的状态值

这套状态词汇在写下之后没几天就从生产中长出来了：

- `declared`：Orkestron 模型上线时，正典镜像已声明但尚未内嵌：登记册上一笔可见的欠账，一次会话之后结清。零条 `declared` 记录的登记册是挣来的，不是假设出来的。
- `retired`：DevTeam.Games 持有一份任务追踪器的完整导出，而该账户已注销。记录系统不复存在；镜像成了一份冻结的证据档案，永远无法重新采集，也绝不可"更正"。登记册说的正是这件事。
- `suspended` 加上一条"永不发布"的冲突规则：一份曾用于设计灵感的专有参考代码库：存在于磁盘上，法律上不可触碰，而这个事实住在登记册里，而不是住在某个人的记忆里。

## 由机器盯着的漂移

声明式的主权归属让机械层面的诚实成为可能：上面那个回写的例子每天跑一次检查，从模型重新生成投影，把内容哈希与线上副本比对，一旦漂移、副本缺失，或检查本身出错，就通知所有者。发现分歧的是一个 cron，而不是会议上的尴尬。

## 要点

- 每个数据集一个主；流向跟随主权；副本是可丢弃的，且带有标记。
- 三种模式：回写、镜像、分区；同一个字段绝不被写两次。
- `sources.yaml` 加上状态（active/declared/suspended/retired），把关于谁说了算的部落知识变成了带版本的数据。

## 深入阅读

- [数据主权归属与记录系统（ARCH-018）](/spec/#02-architecture/Data-Mastership.md)
- [跨宇宙同步](/spec/#03-federation/Synchronization.md)（本课在联邦层面的兄弟篇）

下一课：[复用这个世界](05-reuse.md)