CHECK THEN WRITE60,461 / 100,000
先检查，再分别写入
0.60461两个请求都先看到余额 100。每个请求单独都不超过 100，因此都获批；当 a + b > 100 时记为超额承诺。
真实抽样的合成反例TOWOW SYNTHETIC RESULT · R2
余额只有 100，两个请求都说“够”。
当检查和写入被拆成两个时刻，两个请求可以同时看到同一份旧余额，也可以分别得到一个看起来完全正确的批准。
在 10 万组合成请求里，这个简单模型出现了 60,461 次超额承诺。60.461% 不是现实事故率，它是一个被刻意暴露出来的并发反例。
- 100,000
- 组合成请求对
- 60,461
- check-then-write 超额承诺
- 0
- 理想 reservation 编码结果
设计结论
草稿可以最终一致。稀缺资源的最终承诺，必须有一个唯一作数的时刻。
01 · THE SYNTHETIC WORLD
先把模型说清，再看漂亮数字。
这是 2026-07-24 的历史合成生成器，不是生产系统日志，也没有调用语言模型。它只问一个窄问题：两个请求同时读取旧余额时，分离的 check 与 update 会发生什么。
- B = 100
- 共享余额固定为 100。
- a, b ∼ U(10,100)
- 两个请求量独立来自 10 到 100 的连续均匀分布。
- 100,000 pairs
- 生成 10 万对请求，用样本比例估计冲突概率。
- seed 20260724
- 四项历史实验共用一个 RNG，调用顺序会影响精确复现值。
02 · WHAT THE TWO ARMS ACTUALLY DID
一个臂真的抽样，另一个臂直接写了 0。
这条差异决定了我们可以怎样表述结果。check-then-write 臂进行了数值抽样；reservation 臂没有运行数据库或并发事务。
IDEAL RESERVATIONnp.zeros(trials)
理想线性化预留
0代码把 reservation 的 overspend 数组直接设为全零，用来表达“不允许成功预留总额超过 B”的模型不变量。
按构造为 0，不是实测为 0ANALYTIC CHECK≈ 0.604938
解析概率
49 / 81几何面积给出精确概率。蒙特卡洛值 0.60461 与解析值接近，说明抽样结果符合这个生成模型。
校准生成器，不验证产品最重要的纠正
不能写“serializable reservation 在 10 万次并发压测中零故障”。实验里没有数据库、锁、事务隔离、线程、进程竞争或故障注入。
03 · THE MISSING LINEARIZATION POINT
每个局部判断都对，合起来仍然错。
问题不是某个请求撒谎，而是两个批准之间没有一个共同作数的时刻。
- READ 01
请求 A 读取余额 100。请求 B 也读取同一个旧余额 100。
- CHECK 02
A 的请求量不超过 100，所以通过。B 的请求量也不超过 100，所以通过。
- WRITE 03
两个局部批准分别进入写入路径，没有先为对方保留容量。
- CONFLICT 04
当 a + b > 100，两个单独正确的判断共同制造了超额承诺。
“我检查时还有余额”不是最终承诺的证据。真正需要证明的是：在我作数的那个瞬间，这部分容量已经排他地属于这次承诺。
04 · WHY THE NUMBER IS ABOUT 60.5%
60.461% 不是黑盒指标，可以直接算出来。
把 a 与 b 都减去 10，得到边长为 90 的正方形。安全区域 x + y ≤ 80 是一个直角三角形，剩下的区域就是超额承诺。
历史生成器结果
60,461 个样本满足 a + b > 100。
解析概率 0.604938…
(8100 − 3200) / 8100 = 4900 / 8100。
两者接近不是现实有效性的证明。它只说明历史抽样与这套均匀分布、两个请求、固定余额的数学模型一致。
05 · A REPRODUCTION TRAP
同一个 seed，单独重跑却不是同一个数字。
历史脚本让四项实验共享同一个 RNG，并把并发实验放在最后。若只用 seed 20260724 单独调用这一项，会得到 60,370 / 100,000，也就是 0.60370。按原四项调用顺序消费随机数，才会重现 0.60461。
- 01
历史汇总 CSV
0.60461
- 02
单项同 seed 重跑
0.60370
- 03
按完整 RNG 顺序重放
0.60461
- 04
10 万对原始 a,b
未保存
- 05
代码、seed 与摘要
仍可核对
因此可以说“由代码与 RNG 顺序重建”，不能说“逐行审计了当时保存的原始抽样”。重建数据也不应冒充原始数据。
06 · WHAT ZERO WOULD REQUIRE IN REALITY
一个不变量，需要一个真实机制来守。
理想 reservation 的归纳逻辑很清楚：只有在剩余容量足够时才原子增加 reserved，总成功预留量就不会超过 B。现实系统还需要证明这个原子边界真的存在。
- 01
Reserve
排他地占住容量
- 02
Commit
把预留变成最终承诺
- 03
Release
失败或取消时归还容量
- 04
Expire
处理遗失与超时预留
- 05
Recover
跨故障与重试保持顺序
如果 reserve 只是普通内存字典里的顺序读写，它仍不能证明跨线程、跨进程、跨数据库或跨故障域的一致性。
07 · TOWOW × FLOWNESS
关系协议决定什么能承诺，Harness 证明承诺发生了什么。
Commitment 之前先绑定资源与 Authority
稀缺资源不能只靠各方陈述可用。关系需要明确谁有权预留、预留哪个版本的资源、何时转为承诺，以及失败后谁能释放。
保留 reserve、commit、release 的证据链
EventLog、Commit Gate 与目标端读回可以保存每一步的因果与结果，但 Harness 本身不能把一个非原子后端魔法般变成原子后端。
两条线组合后，系统既要知道承诺的关系含义，也要从真正拥有容量的目标系统取得新鲜证据。
08 · CLAIM BOUNDARY
这个反例很强，但它的半径很小。
可以说明
- check 与 update 分离会产生明确的超额承诺反例。
- 在这套特定分布里，冲突不是稀有边角情况。
- 真正线性化的 reservation 可以通过不变量阻止总预留超过容量。
- 稀缺资源的最终 Commitment 需要原子预留或等价强度机制。
不能说明
- 不能说现实系统的超卖率是 60.461%。
- 不能说某个数据库、平台或 ToWow 实现已经做到零超卖。
- 不能推断性能、可用性、跨区域容错或故障恢复。
- 不能把一个合成并发反例提升为产品闭环或商业有效性证据。
材料与证据等级
现存材料包括生成器代码、固定 seed、历史调用顺序、两行汇总 CSV、manifest 副本与 SHA-256 校验。10 万对原始请求、逐次接受顺序、事务日志、并发 schedule 与运行环境锁未保存。
09 · NEXT EXPERIMENT
下一次要跑的，不是另一个全零数组。
真实比较需要 barrier 强制并发交错，实际运行 check-then-write 与数据库事务两臂，并保存 commit、abort、retry、锁等待、隔离级别、延迟、故障恢复和多随机种子结果。