diff --git a/docs/experiment_round38_backoff0.json b/docs/experiment_round38_backoff0.json
index c3945c8..cca0227 100644
--- a/docs/experiment_round38_backoff0.json
+++ b/docs/experiment_round38_backoff0.json
@@ -33,6 +33,8 @@
     "gap_margin": 0.0,
     "cert_batch": 1,
     "steps": 1,
+    "z_scale": 1.0,
+    "len_w": 0.0,
     "backoff": 0,
     "max_sec": null,
     "seed": 0,
@@ -67,7 +69,14 @@
     "speed_ratio_max": 1.0000101327896118,
     "over_vmax_rate": 0.0,
     "accel_ratio_p95": 1.0000016689300537,
-    "accel_ratio_max": 1.0000101327896118
+    "accel_ratio_max": 1.0000101327896118,
+    "reverse_p50": 0.24741201102733612,
+    "reverse_mean": 0.25991496443748474,
+    "reverse_moving_p50": 0.32581019401550293,
+    "moving_share_p50": 0.9587156176567078,
+    "brake_rate_mean": 0.10028044879436493,
+    "brake_rate_p50": 0.0051282052882015705,
+    "n_plans_mean": 195.0
   },
-  "simulation_wall_s": 329.1139315000037
+  "simulation_wall_s": 319.19268320000265
 }
diff --git a/docs/探索日志.md b/docs/探索日志.md
index b516f37..f025c90 100644
--- a/docs/探索日志.md
+++ b/docs/探索日志.md
@@ -108,6 +108,13 @@
 - **对 `backoff` 的预期与判据**：全拒意味着"连第 1 步的端点或中点已经穿进障碍"，缩步能不能救取决于**穿得有多深**（穿 0.1 mm 救得回，穿 3 mm 救不回）。这个数转储里没记（只记被选中那条），所以直接由 `backoff_mean`/`reject_all_mean` 来量：
   `reject_all_mean ≈ 原全拒次数`（=backoff_mean+brakes_mean，与轮次 33 cap 的 19.55 可比），`backoff_mean/(backoff_mean+brakes_mean)` 就是"缩步能救回的比例"。这是补跑（#22）要读的第一个数。
 
+## 控制臂对表：22/22 键逐位复现 + 仪表预测精确命中（轮次 42）
+
+- `--backoff 0 --cert_batch 1 --inc_cap 1` 重跑轮次 33 cap 配方：**两文件共有的 22 个指标键全部相等，差异集合为空**（第三次确认批量认证分支重写没有改变行为）。
+- **仪表互验精确命中**：这个控制臂的 `reverse_p50 = 0.2474`，而我先前用轮次 33 cap 转储、按 `rollout` 同窗口离线重算的预测值是 **0.247**（那次还给出"到达组 0.265 / 未到达组 0.233"）⇒ 线上指标与离线重算在三个小数位上对齐，之前 1.575 那批读数确实只是"未除 6 的旧口径"。
+- 控制臂的 §9.2 判据读数（第一次用真分母）：**`brake_rate_mean = 10.03%`、`p50 = 0.51%`、`n_plans = 195`、`moving_share = 95.9%`** ⇒ "<2% 推理周期"在均值上差 5 倍、在中位上已达标，再次是长尾。
+- 待读（正在跑）：`backoff=1/2/3` 的 `backoff_mean / reject_all_mean` 转化率，按预注册规则判：10–20% ⇒ 缩步只是慢一点撞，到达不动，主攻转向 #24；>60% ⇒ 直接吃到那 63/109 的冻住时间。
+
 ## "冻住"的真实形态：不是堵死，是每题约 30 次、每次 1.8 步的反复试探（轮次 42，纯读转储）
 
 - 先自纠一次框架：我按"≥10 步连续零运动"找长冻结，结果 B 类 74 题里只有 9 题有这样的段、C 类 32 题只有 3 题。原因很直白：`commit_n=2` 时**一次全拒只站 2 步**，要连成 10 步得连续 5 次全拒。所以"长冻结"这个说法对这份配置基本不成立，改测"停顿事件的累计与分布"：