> 译文仅供阅读便利。具有规范效力的是英文原文。

# 语义迁移

**元宇宙规范**

**文档编号：** MU-V2-ARCH-010  
**标题：** 语义迁移标准（SMS）  
**文档类别：** 规范性  
**版本：** 2.0（草案）  
**状态：** 工作草案  
**规范性引用：** [MMAS-Core](../02-architecture/MMAS-Core.md)、[Versioning](../02-architecture/Versioning.md)、[MMAS-Interchange](../02-architecture/MMAS-Interchange.md)、[Event](../04-core-concepts/Event.md)、[Traceability](../02-architecture/Traceability.md)、RFC 2119  
**说明性引用：** [Migration from v1](../07-guides/Migration-from-v1.md)、[Naming-Conventions](../02-architecture/Naming-Conventions.md)  
**版权：** © Orkestron.AI  
**许可：** Apache-2.0

---

# 1. 目的

本文档定义**语义迁移标准（SMS）** - 元模型从一个版本、结构或词汇转向另一个时，*不丢失、也不悄然改变含义*所须遵循的规范性规则。

[Migration from v1](../07-guides/Migration-from-v1.md) 指南把迁移引入为一项演进式的三层活动，并把 SMS 称作它未来的形式化。本文档把这一概念落实：它规定迁移层级，把每次迁移记录为可追溯的[事件](../04-core-concepts/Event.md)，定义一份**迁移清单**，并确立这条不变量：*含义不得在没有显式迁移事件的情况下改变*。

---

# 2. 适用范围

本规范适用于：

- 元模型、bundle、层、对象、属性、关系、事件、契约与投影跨版本的迁移；
- 概念的重命名、拆分、合并与重新归类；
- 仓库与文档的结构性重组；
- 已迁移模型的联邦重新绑定。

它不定义用于持久化迁移记录的存储技术，也不定义人工评审流程（见 [Migration from v1](../07-guides/Migration-from-v1.md)）。它所依赖的语义指纹与规范化定义于 [MMAS-Interchange](../02-architecture/MMAS-Interchange.md)。

---

# 3. 迁移的三个层级

对迁移的思考必须分三个不同层级进行，它们可以各自独立、以不同速度推进：

- **结构迁移** - *仓库与文档的结构*：目录布局、文件组织、文档标识符与文件头。结构性变更可以是无声的：它本身并不改变含义。
- **语义迁移** - *术语、概念、关系与规则*：某个概念如何被重命名、拆分、合并、重新归类或重新定义。语义变更不得无声（见第 5 节）。
- **联邦迁移** - *已迁移模型如何与其他宇宙互动*：重新绑定信任、身份、语义映射、契约与投影同步，使该模型得以重返更广的生态。

一次完整的迁移必须处理这三个层级。结构迁移搬动文件；语义迁移保住文件之内的含义；联邦迁移恢复该模型与他者的关系。

---

# 4. 迁移作为可追溯、可逆向解释的操作

一次迁移必须记录为一个或多个不可变的[事件](../04-core-concepts/Event.md)，其类别为*语义事件*（在适用时还包括*生命周期事件*）。每个迁移事件都必须声明：

- 它的主体 - 正在被迁移的制品；
- **源版本**与**目标版本**；
- 指向治理它的**迁移清单**（第 6 节）的引用；
- 它的[溯源](../02-architecture/Traceability.md) - 由谁执行迁移、依据何种权威。

迁移必须：

- **可追溯** - 每一处变更都必须能通过迁移事件及其清单，从来源一路跟到结果；
- **可逆向解释** - 先前状态、理由与映射都必须被记录，使该变更可以被理解，并在映射可逆时被回退。SMS 并不要求每次迁移都能反向*执行*；它要求每次迁移都能反向*解释*。

对某次迁移的更正，本身也必须表达为引用被更正事件的新迁移事件。迁移事件一经记录，就不得被编辑或删除。

---

# 5. 无声改变含义的禁令

含义不得在没有显式迁移事件的情况下改变。

具体而言：

- 凡改变任何概念[语义指纹](../02-architecture/MMAS-Interchange.md)的变更，都必须伴随一个迁移事件，以及一条对其加以归类的迁移清单条目。
- 重命名某个概念必须产生新的[正典语义名称（CSN）](../02-architecture/Naming-Conventions.md)；旧的 CSN 不得被悄然改写，而旧 → 新的映射必须记入清单。
- 只影响非语义内容（显示名称、描述、文档、文件位置）的变更不得改变指纹，并且可以作为结构迁移执行，无需语义迁移事件。

这种不对称是刻意的：**结构性变更被允许无声，语义性变更则不被允许。**

---

# 6. 迁移清单

每一次语义迁移都必须由一份机器可读的**迁移清单**加以治理，它以声明式的方式描述含义如何从一个版本被带到下一个版本。清单必须包含：

| 字段 | 含义 |
|-------|---------|
| `fromVersion` | 元模型的源版本。 |
| `toVersion` | 元模型的目标版本。 |
| `fromFingerprint` | 源模型的[语义指纹](../02-architecture/MMAS-Interchange.md)。 |
| `toFingerprint` | 目标模型的语义指纹。 |
| `conceptMappings` | 已变更概念的有序集合，每一项把一个源 CSN 映射到其目标 CSN 以及一种变更类型。 |
| `compatibility` | 整体的兼容性归类（第 7 节）。 |
| `events` | 指向落实本清单的那个或那些迁移事件的引用。 |
| `provenance` | 清单的作者、权威与创建时间。 |

`conceptMappings` 中的每一项都必须声明一种**变更类型**：`renamed`、`split`、`merged`、`reclassified`、`redefined`、`added`、`deprecated` 或 `removed`，连同它所关联的源 CSN 与目标 CSN。未发生变化的概念无需出现；未出现在 `conceptMappings` 中必须意味着*含义保持不变*。

迁移清单本身也必须能表达为 [MUIF](../02-architecture/MMAS-Interchange.md)，从而像任何其他制品一样被交换、取指纹与校验。

---

# 7. 兼容性归类

每次迁移都必须声明一种兼容性归类，与 [Versioning](../02-architecture/Versioning.md) 中的语义变更分类保持一致：

- **兼容** - 没有任何概念改变含义；源模型的消费方无需适配即可消费目标模型。模型指纹只可能因追加式、非破坏性的概念而改变。
- **有条件兼容** - 含义得以保留但表示形式改变（例如带有已记录 CSN 映射的重命名）；消费方可以通过清单中的映射继续沿用源模型。
- **破坏性** - 至少一个概念改变了含义、被移除，或以损失区分度的方式被合并；消费方必须依照清单的 `conceptMappings` 进行适配。

该归类必须可从 `conceptMappings` 推导得出，并且必须与语义指纹的变化保持一致。

---

# 8. 正典身份的保全

迁移不得破坏**正典身份**。

- 对象、关系、事件或契约的稳定身份必须原封不动地经受住迁移，即便其 CSN 或显示名称发生变化。
- 当某个概念被拆分时，每个产生出来的概念都必须声明它从原始身份派生而来；当若干概念被合并时，产生出来的概念必须引用它所吸收的每一个源身份。
- 历史[事件](../04-core-concepts/Event.md)与先前版本必须继续可得，且不得被迁移改写。

正是身份的连续性，才使[语义谱系](../02-architecture/Traceability.md)得以跨越版本边界被追踪。

---

# 9. 完整示例：v1 星系 → v2 命名空间

v1 到 v2 的正典演进，把 v1 的组织性概念*星系*重命名为 v2 的[命名空间](../02-architecture/Naming-Conventions.md)。含义 - *概念如何被组织与发布* - 得以保留；改变的只是名称及其治理地位。这是一次**有条件兼容**的语义迁移。

迁移清单的梗概：

```text
fromVersion     : 1.4
toVersion       : 2.0
fromFingerprint : sha256:<source>
toFingerprint   : sha256:<target>
compatibility   : Conditionally Compatible
conceptMappings :
  - source: galaxy.<x>          target: namespace.<x>     kind: renamed
  - source: object.<x>          target: metaObject.<x>    kind: renamed
  - source: identity.<x>        target: canonicalIdentity.<x>  kind: renamed
  - source: projection.<x>      (unchanged — omitted)
events          : [ evt:migration/1.4→2.0/namespace ]
provenance      : { author: <steward>, authority: <MUC>, at: <time> }
```

落实它的迁移事件（语义事件）：

```text
id        : evt:migration/1.4→2.0/namespace
type      : SemanticEvent (migration)
subject   : metaModel:<id>
payload   : { manifest: <manifest-ref>, kind: renamed, from: galaxy, to: namespace }
causality : [ evt:release/2.0 ]
provenance: { actor: <steward>, authority: MUC, source: SMS }
```

由于这次重命名被记录为带有 `galaxy.* → namespace.*` 映射清单的显式迁移事件，v1 模型的消费方可以把任何 v1 星系 CSN 解析到它的 v2 命名空间 CSN，该变更可逆向解释，正典身份也跨越边界得以保全。没有任何含义被无声改变。

---

# 10. 校验

迁移在满足以下条件时符合本规范：

- 每一次语义迁移都被记录为不可变的迁移事件；
- 存在一份迁移清单，其中含有两枚指纹、对每个已变更概念的完整 `conceptMappings` 集合，以及与指纹变化一致的兼容性归类；
- 没有任何概念在缺少对应迁移事件的情况下改变含义；
- 正典身份在迁移过程中得以保全；
- 历史版本与事件仍然可得且未被改写。

适用的校验级别见 [Validation](../02-architecture/Validation.md)。

---

# 11. 架构不变量

- 含义不得在没有显式迁移事件的情况下改变。
- 每一次语义迁移都必须由一份迁移清单加以治理。
- 迁移事件必须不可变；更正必须是新的事件。
- 正典身份必须原封不动地经受住迁移。
- 兼容性归类必须与语义指纹的变化保持一致。
- 结构迁移可以无声；语义迁移不得如此。

---

# 未来方向

本文档就地确立了**语义迁移标准（SMS）**这一概念。一份专门的 SMS 规范可以在此之上扩展：一套完整的迁移事件类型与变更类型词汇表；把迁移清单作为一等 [MUIF](../02-architecture/MMAS-Interchange.md) 制品的规范性模式；面向可逆迁移的机器可验证可逆性规则；跨宇宙的迁移编排，使上游模型迁移时联邦伙伴能够自动重新解析 CSN；以及能够证明没有任何含义在缺少记录事件的情况下发生改变的合规测试向量。

---

# 结语

> 迁移不是过往含义的丧失，而是某个含义走向下一形态的有据可查的过渡。SMS 让这一过渡变得显式：每一次含义的改变都在身后留下一个事件，每个事件都指向一份清单，而每份清单都让任何人都能重建出究竟改变了什么、为什么改变，以及如何回到从前。