Orisumi身份、时间与更新
业务规则决定身份和粒度，每个版本有自己的保存时间，更新形成新版本，独立的陈述形成新观测
背景
观测可能在事实进行中形成，随后不断延长；填错的边界或时区需要纠正。传输会重试，响应会丢失，两个写入方可能同时更新同一份内容，来源还可能缺少时间。
没有统一规则，同一个事实会重复保存，重试会变成多次修改，旧值会被覆盖，读取方也分不清“同一实体的更新”和“另一份观测”。
决定
- 业务规则决定实体身份和粒度。
- 事实时间未知时保持未知。
- 后端在首次保存每个版本时赋值保存时间。
- 同一实体的更新形成新版本。新版本可以补全，也可以纠正。
- 独立的陈述形成新的 Observation。Observation 的后续版本由同一个 Observer 形成。
- 新版本必须基于当前版本。基于旧版本的写入是冲突，由写入方重新处理。
- 重试沿用 VersionId。重复提交已保存的版本不形成新版本。
理由
只有业务规则能说明来源的含义，例如两次读数之间应用是否一直在前台。后端按内容合并或拆分，会把巧合当成同一个事实。
保存时间回答“后端什么时候保存了这一版”。实体首次保存的时间就是首版的保存时间。
旧版本已经保留，禁止纠正不能进一步保护历史，只会逼写入方删除重建或绕开模型。所以新版本可以延长时段，也可以修正错误，只需自身合法。
纠正不改变责任归属。Observer 只更新自己的观测；别人的确认、否定和模型的重新处理都是新的 Observation。
一条版本链让当前版本唯一。重试如果换新的 VersionId，响应丢失就会把一次保存变成两次变化，所以重试沿用原 VersionId。
放弃的方案：
- 后端按内容去重或合并。 内容相同不说明是同一次观测，内容从 A 改成 B 再改回 A 也有独立意义。
- 用其他时刻填补未知的事实时间。 读取方会分不清“确实在这一刻”和“不知道是什么时候”。
- 已保存的观测只能单调补全。 历史已由版本保留，这条限制只会阻止纠正。
- 按客户端时间戳决定当前版本。 时钟不同步时，晚到的旧写入会覆盖新内容。
- 在 Core 中定义纠正和撤回操作。 纠正就是新版本，撤回是另一个 Observer 的否定或用户的删除。
代价
- 需要沿用的 EntityId 必须持久保存，例如程序实例和进行中的时段。
- 写入方要知道自己基于哪个版本，并处理冲突。
- 重试要保存原 VersionId。
- 当前内容可能被纠正，需要当时的内容时按版本读取。
