# 数据、版本与变更 (/docs/architecture/data-and-versions)

## 用同一种引用方式连接不同对象 [#用同一种引用方式连接不同对象]

各模块保留自己的数据结构，共享少量基本信息：组织、项目、对象类型、对象 ID、版本和来源。

例如，一个仿真结果引用“实验 EXP-014 的第 2 版分析”，而不是只写“参考最新实验”。这里的编号仅作说明。

| 信息 | 解决什么问题 |
| --- | --- |
| 对象 ID | 它究竟是哪份实验、哪条物流或哪个成果？ |
| 版本 | 当时用了哪一版？ |
| 所属项目与组织 | 谁拥有它，谁能看见？ |
| 来源与依赖 | 数据从哪里来，改变后影响谁？ |
| 状态与时间 | 它是草稿、已确认还是已被替代？ |

## 数字需要带上上下文 [#数字需要带上上下文]

除了数值，还需要单位、物理量、计算基准、工况和来源。例如质量分数与摩尔分数、干基与湿基、绝压与表压，不能只凭列名猜测。

根据数据类型补充测量方法、检出限、不确定性或适用范围。缺失值与零值分开；没有记录不确定性，也不意味着不确定性为零。

单位转换可以自动执行，但原始值和转换依据要保留。来源互相矛盾时形成待处理问题，不能直接取平均值覆盖。

## 四类记录，四种变化方式 [#四类记录四种变化方式]

| 记录 | 如何变化 |
| --- | --- |
| 计划和模型 | 可编辑草稿；确认后形成可引用版本 |
| 实验事实与原始文件 | 保留原记录；更正通过新修订说明 |
| 分析和计算结果 | 每次运行生成新结果，引用固定输入 |
| 对外发布包 | 固定内容清单；更新通过下一次发布 |

每次变化都能区分“补充事实”“纠正录入”“重新分析”和“改变方案”。

## 并发修改怎么处理 [#并发修改怎么处理]

工程师和 Agent 提交变更时携带基准版本。若目标已经被其他人修改，系统返回冲突和差异，由提交方重新比较并校验。

允许部分接受提案，但剩余内容应重新形成基于最新状态的提案。回退也会生成新的版本记录，保留已发生的实验和历史交付。

## 依赖变更后会发生什么 [#依赖变更后会发生什么]

“输入已变化”“正在重算”“计算失败”“待专业复核”和“已更新”是不同状态。

系统沿已登记的依赖关系提示影响，按项目规则触发可自动执行的任务。涉及专业判断的条目进入待复核。

跨模块更新允许逐步完成。界面展示哪些结果已经更新、哪些仍对应旧输入，避免把不同工况结果混成一个看似一致的版本。

## 发布时固定什么 [#发布时固定什么]

发布包保存明确的对象与文件清单：需求、设计基础、关键实验依据、模型和计算结果、报告、图纸、待解决事项。

组装时检查各项引用是否相容；发布后内部继续编辑不会改变这份清单。发布快照是对外讨论的稳定基础。