Hacker用户今天续费了，还能解释昨天那封催缴邮件吗？
一次判断要能重现，除了规则本身，还需要当时交给它的那份数据。
客服问昨天为什么发了催缴邮件。你打开用户资料，看到「已续费」。这份资料能回答现在能否使用服务，要还原昨天的决定，还差一条带时间的信息。
给事实带上时间
Rich Hickey 在《The Value of Values》里区分了一个事实和后来的变化。套在这个例子上，「昨天到期」和「今天续费」可以同时成立。如果每次只覆盖当前状态，过几天就很难知道那封邮件寄出时，系统掌握了什么。
you can't update a fact is because you can't change the past回看原片 22:20–22:25 →
两个版本可以共用大部分内容
另一场演讲回答实现上的疑问：保留旧版，是不是每次都得复制整份资料？持久化数据结构可以让两个版本共享没有变化的部分。旧版继续指向原来的值，新版指向修改后的值，两次读取各有明确的对象。
the next version of the value shares a lot of structure with the prior version回看原片 40:03–40:20 →
知道发生了什么，还缺哪条规则才能还原当时？
在事件溯源中，把已发生的事件按顺序交给投影，才能得到某个时点的状态。写着「刚停机」的一行记录也说明这个区别：在 MIT 的反应堆课程中，氙是运行中积累的中子吸收体，当前材料状态与此前运行有关。前一个系统可以定义怎样重放离散事件；后一个过程还涉及随时间演化的物理量。两段材料合在一起提醒我们，日志里即使存了时间，也还要问是否记录了重建所需的初态、输入和演化规则。
对照原文与时间戳
current state is a left fold of previous behaviors回看原片 6:13–6:20 →
Xenon-135 is one of the best neutron absorbers there is.回看原片 9:03–9:06 →
you'll reach the xenon equilibrium level where it will build to a certain level that will counteract the reactivity回看原片 9:50–10:00 →
两份历史值，要复制两份内存吗？
Hickey 给 Java 程序员讲不可变数据时，从读者需要记住哪些锁说起。不变的值减少了协调读取的负担。Puente 把实现问题往下挖：树上一次小改动可只复制从根通向改动位置的路径，未改分支在新旧版本间共享。这能解释「保留旧值为什么可能便宜」，却不会替应用记录哪个版本触发过一封催款邮件。那份业务关联仍由应用保存。
对照原文与时间戳
have everybody remember what the locking model is回看原片 6:05–7:55 →
most of the data structure is shared between all these values回看原片 8:39–8:46 →
七月份的报表，重算后还能叫同一份吗？
Hickey 的收益管理例子从过去的销售事实推导价格。Kleppmann 的物化视图让派生结果更便宜地读取，代价是基础数据一变就要维护结果。若历史订单和定价规则后来都改过，今天的视图只能回答按今天规则会得到什么。要复现当时给出的价格，需要同时保存输入事实和规则版本，或者直接保存当时的输出。
对照原文与时间戳
produces pricing information回看原片 10:38–14:28 →
query's already been done ahead of time回看原片 16:29–16:34 →
资产已经卖出，哪一天的钱才算数？
这段日本经济史讲解把资产出售、可提款日期与物价变化拆开。若卖价在名义账本上没变，在通胀期间延后支取仍会改变最终能买到的东西。给一笔交易建立时间线：哪天定价，哪天允许动用，选哪天的物价换算。回答「当时家族还剩多少财富」必须先说明自己查的是时间线上的哪一个值。
对照原文与时间戳
Land reform during and after the war回看原片 15:01–15:06 →
they were not allowed to withdraw回看原片 15:16–15:21 →
这里还有一个需要自己做的决定：该保存哪些版本、怎样把版本对应到业务时间。结构共享能降低保留版本的代价，应用仍要记录那封邮件用了哪份资料。这样，把旧资料和当时日期交给判断规则，才有机会复现昨天的结果。