因果传播网络

事件需要裁决，事实需要传播。

因果层的本质是时间的隐喻，事件是因果层的最小单位。

在这个闭环中，事件是输入，事实是输出，传播让输出成为下一轮输入。因果层通过不断运转这个循环，把外部世界的无序变化，整理成系统内部可追溯、可解释的历史。

事件与事实

事件是尚未被世界接受的变化请求。它可以来自外部输入，也可以来自因果层内部的传播。

事实是事件经过裁决之后，被正式承认进入历史的关系变化。

两者的区别至关重要：

事件可以冲突、可以无效、可以被丢弃
事实一旦成立，就不会被原地改写，后续变化只能以新事实追加

这意味着因果层维护的不是「当前状态」，而是一条持续增长的历史链。状态只是这条链在当前时刻的投影。

状态模型:         因果模型:
hp = 100         damage_taken
hp = 80          hp_depleted
hp = 0           entity_dead

参见因果层

裁决与传播

因果层通过两类规则运行：

裁决规则：决定事件能否成为事实。从应用层视角看，它就是一条计算规则：
```
(event, history) => Fact | null
```
它包含两个环节：
- 资格审查：检查事件是否满足生效条件；
- 事实生成：根据输入生成事实内容。
传播规则：决定事实会产生哪些新事件，推动下一轮循环。

裁决规则本质上是无状态的纯函数。给定一个事件和当前事实历史，它输出新事实或拒绝。事件何时到达、是否并发、是否冲突，都不是它需要关心的事。

从时间观上看，因果层不承认"同时"。所有看似同时发生的事件，在进入裁决前都已被排序机制整理成一条序列；裁决规则看到的永远是一个接一个的输入，而不是并发。这与函数式编程的世界观相通：没有真正的同时，只有输入到输出的映射。

锁、CAS 等并发原语，诞生于冯诺依曼的共享内存模型：多个执行流同时读写同一块内存，必须用它们来保护这块内存不被破坏。但是在面向因果的视角中，竞争与顺序由系统排序机制处理，这部分并发原语是不需要的，只要在应用层，不应该暴露具体的并发原语。

工程实现细节

排序机制的实现层次：

冯诺依曼架构层面：重新设计硬件原生支持事件排序，理想情况无锁。
语言 / 运行时层面：单线程事件循环天然无锁；多线程运行时内部可能仍需锁。
分布式层面：通过消息队列和共识协议达成全局顺序。

应用层应该保持始终无锁；底层是否无锁取决于实现。这种事件驱动结构与 Actor 模型相似，但 Actor 规则分散在每个 Actor 中，双世界理论强调统一事实历史与最终因果一致性。工程上可以用来参考。

以游戏里的一次攻击为例：

玩家按下攻击键
        ↓
attack_requested（事件）
        ↓
裁决规则（计算规则）：
  ├── 资格审查：目标在范围内？技能冷却？敌人闪避判定？
  └── 事实生成：攻击力 × Buff加成 − 敌人防御力 = 伤害值
        ↓
damage_applied（事实）
        ↓
传播：death_check_requested（事件）
        ↓裁决规则（计算规则）：
  ├── 资格审查：hp 是否小于 0？是否免疫致命伤害？是否可以复活？
  └── 事实生成：确定死亡事实与相关派生值
        ↓
entity_dead（事实）
        ↓
传播：触发亡语、QTE、生成掉落物、更新任务、获取经验、触发升级、触发新剧情（新事件）

裁决与传播的关系：

裁决把不确定性收敛成事实；传播让事实重新打开不确定性。

工程约定

层次	职责	实现者
业务规则层	计算规则、传播规则、感知层	业务开发者
因果运行时层	原子排序机制、规则调度	框架 / 中间件