10 · 运营与治理
10.1 · 参数三态治理
系统中的每个参数都被登记并指派恰好一个治理状态：冻结（永久确定，只能通过完整的方法变更流程改变）、初始（初始生产有效：该值就是生产值，校准研究可稍后通过方法变更流程提议变更）与停用（保留但未激活）。注册表是版本化的，每个已发布工件记录它在哪个参数版本下计算。三态纪律使 V1 权重诚实：它们不是“等待校准的占位符”—— 注册表的初始状态是生产有效的——但校准之门是一个正式流程，而非静默微调。
10.2 · 版本向量
可复现要求每个计算携带自己的来源。系统维护六个版本向量，每个在其域变化时递增，每个已发布工件携带完整元组：
表 9. 版本向量：每个已发布工件携带完整元组，使“在什么之下计算了什么”是机械的。
| 版本 | 域 | 何时递增 |
|---|---|---|
| 超参数 | 任何参数改变状态或值 | |
| 成员 | 纳入或影子集合变化 | |
| 公式 | 任何构成公式变化 | |
| 治理决策 | 一条经裁决决策被记录 | |
| 旗舰计算 | 旗舰公式或其输入版本化 | |
| 来源定义 | 一个来源被添加、互换或弃用 |
元组的两个性质重要。第一，元组在时间上单调：版本从不减小，所以元组是计算上的全序，“比较两个快照”是良定义的。第二，元组的粒度足够细，足以实现局部化：来源互换改变 而不隐含方法变更，读者无需对每个公式做 diff，原则上就能看到发生了哪一种变化。版本元组是本文可复现姿态的操作形式。
10.3 · 结算日历与窗口
系统在两个收盘窗口（UTC 04:00–07:00 与 16:00–19:00）中以相同结构、两窗口等权每日结算两次。锚在结算之间冻结；实时信号在收盘窗口内只衰减（无注入、无更新），收盘窗口内到达的事件在下次开盘批量结算。重新开盘被公告。日历是一个治理对象：改变窗口数量或位置是一次带版本条目的方法变更。两个窗口的设计理由在第 5.7 节陈述：它们包住两个半球的主要活动时段，并界住锚在一天内的陈旧上界。
10.4 · 动态成员操作
成员变化遵循纳入规则（第 3.4 节）与既定操作路径：候选在一个结算被评估；若被接纳，接纳在下一次结算生效并连同其理由与 递增一并披露；不回溯纪律（第 3.5 节）防止任何追溯重述。当一次接纳改变归一化极端时，机械重估由 BR-01 桥接（第 6.10 节）处理，它把变化的机械部分与基本部分分离。影子状态是中间层级：一个影子单位被评估并展示，但不定义归一化极端、不进入居中均值（第 3.3 节），这让系统在候选的接纳能移动尺度之前积累关于候选的证据。
10.5 · 暂停、挂起与恢复
完整性事件由分级机制处理。在字段层面，一个疑似错误值被挂起待复核，同时最近的合法值继续使用（第 9.1 节）。在结算层面，如果形式计算无法被证明完整、有效且可复现——一次 P0 级完整性失效——候选结算被挂起，不提交新的形式版本，最后的已确认状态以“结算延迟”通知继续发布；系统在后台继续采集与重算。在实体层面，单个智原可因仲裁委员会的决定被暂停（盘中与结算时冻结），而不改变其成员状态——暂停是一个报价/治理状态，而非成员状态。恢复要求演示根因、可证明的安全边界、幂等重算与通过的不变量检查。分级机制的设计目标是让故障被隔离在包含它的最小域中（表 7 的残余风险是该设计的输入）。