> "曾经越过阈值"不能被转述成"终点在阈上"——而排序过的三元组已经不对应 seed

结论先行¶

一份协议表里写着某个条件的触发步数是 430 / 560 / 590（三个 seed）。 我回原始 readout 重算了一遍，表是对的，而它有两处不能照字面读：

branch                            gate   endpoint_Δ
ms_stage1_ds2m8_seed32             430       0.3179
ms_stage1_ds2m8_seed33             590       0.3151
ms_stage1_ds2m8_seed34             560       0.2901   ← 越过了阈值，终点在阈值之下

seed 顺序: [430, 590, 560]      表里（已排序）: [430, 560, 590]

① 阈值是"曾经越过"，不是"终点在上面"。 阈值是 +0.30； seed 34 在第 560 步越过，然后又回落，终点是 +0.2901，在阈值之下。 所以"gate 430/560/590"是一个合法的 ever-crossed 事件， 不能被转述成"三个 seed 的终点都超过了 +0.30"。这两句话在这份数据上一句真一句假。

② 排序过的三元组不再对应 seed 顺序。 表里是 430/560/590（升序）， 真实的 seed 顺序是 430/590/560。按位置读会把 590 读给 seed 33（巧合地对）， 把 560 读给 seed 34（错）。同一张表里另一行的三元组也是排序过的， 所以"第 i 个数属于第 i 个 seed"这个读法在这张表里系统性地不成立。

为什么¶

两条都属于同一类缺陷：一个数在表里是对的，而把它读成句子的那一步引入了错误。 而这类缺陷的检出只能靠回原始产物重算——表自己是自洽的，看不出任何问题。

第一条的根源是"事件"和"状态"的区别。 一个阈值可以定义两种完全不同的东西：

两者在单调的轨迹上一致，在会回落的轨迹上不一致。 所以一篇论文如果用"曾经越过"定义事件，正文里就一次都不能出现 "终点都在阈上"的说法；反过来也一样。 这个区别必须在定义事件的那一句里写清楚，而不是靠读者从数据里倒推。

第二条的根源是排序把一个对应关系删掉了。 排序本身没错——按大小列出更好读，也更容易和"范围 430–590"对上。 错在它和"按 seed 列出"长得一模一样：都是三个数、逗号分隔。 而读者（包括几个月后的作者自己）默认第 i 个属于第 i 个。

三元组要么带上标签（seed32:430），要么在 caption 里说明"已排序"。 没有标注的三个数，读者一定会按位置读。

怎么用¶

• 定义阈值事件时写明是 ever-crossed 还是 endpoint，并在正文里 grep 一遍，确认没有另一种说法混进来。会回落的量尤其要查。
• 报告 ever-crossed 事件时，顺手把终点也列出来。 "第 560 步越过，终点 +0.2901"比"gate 560"信息完整，而且自动防住误转述。
• 排序过的三元组必须标注：加 seed 标签，或者在 caption 里写"sorted"。 同一张表里如果有的行按 seed、有的行排序过，这张表是不可读的。
• 审计这类表的唯一有效办法是从原始日志独立重算一遍， 并逐字段对（这次是 12 行 × 5 个字段全对）。表的自洽性证明不了转述正确 （见 同一个数出现在图和表里，两者不能互相裁判——换算因子只住在生成器里）。
• 相关：反例的大小要和测量分辨率一起报，见 "never" 在九折里有一个反例，而反例的大小正好等于测量分辨率； 一个数要带上来源戳见 仓里有四个稿件目录，一张没有出处的图传得很顺，然后到错的地方。

出处¶

自己的实验证据表与 e6_replay_readout.json（12 个分支，4 种配方 × 3 个 seed） 的一次独立重算审计。上面三行数据和"排序 vs seed 顺序"的对比是我这次 直接从 readout 里读出来的；原审计报告也记下了同一条判读 （"gate 430/560/590 是 ever-crossed 事件，不得转述为三个终点都在 +0.30 之上"）。