Jyotisha/docs/research/rectification_minute_resolution_closure_2026_09_14.md

生时校正「候选分不开」两轮研究的结论页（2026-09-14）

这一页是索引与定论。下次有人想从"打分权重不够"或"簇合并把候选并没了"出发再查一遍之前，先读这页。 口径：ayanamsa raman、node mode mean，步长 2 分钟，样本 references/real_case_calibration/minute_rectification_holdout_v4.json（20 例公开 Rodden-AA，每例 ≥7 件带年月事件、≥4 个领域）。不得与上游 true-node 数字直接对比。

0. 起因

真机反复出现：带年月的选择题问完，仍剩 4–5 个候选并列（例如相对可能性 26% / 26% / 20%），用户只能蒙。 最初的假设有三个，两轮离线测量后两个被证伪、一个被缩小。

原始假设	结论
A. 打分尺度对分钟不敏感（窗内恒定项 ≈ 11.5 分 vs 随分钟变化项 ≈ 2.1 分，约 5:1），加权重就能拉开	证伪：五个改法三档半径无一过门
B. 交付区间宽度永远等于整个搜索窗（簇合并"从不丢簇"）	证伪：那是不含淘汰的测量口径产物；线上含淘汰后是 15 / 33 / 56 分钟
C. 上游 yinduzhanxing 有我们缺的技法	证伪：校正相关增量为零；上游自己也停在"整窗零淘汰"

1. 已经定论的事实

1.1 交付区间宽度：没有想象中糟，真值也从没丢

按线上口径（unionStillValidRange = 未淘汰且落后头名不足 8 分的簇覆盖并集），答完六题后：

搜索半径	不含淘汰的并集（旧口径）	线上真实宽度中位	真值落在交付区间
±10	21	15	20/20
±30	61	33	20/20
±60	121	56	20/20

1.2 簇合并根本没运行过

cap_clusters_by_adjacent_merge 的 docstring 写着 "Keep the whole window…merge adjacent weak ones"，容易让人以为弱簇被并回整窗。实测三档半径上合并次数中位都是 0：步长 2 分钟时候选最多 61 个，低于 MAX_PUBLIC_CLUSTERS = 64，函数压根不触发。真值簇独立率三档都是 20/20。

→ 「簇合并把候选并没了」是假线索，不要再从这里查。

1.3 加权重类改法：全部不过门

改法	结果
R1 分盘项除数（2·len → len / √len / 2）	只在 ±10 提升头名命中 0.35→0.45，宽窗消失
R2 去底座（每事件减窗内最小值）	命中与宽度都不动，仅引擎熵略降
R3 KP 宫头子主计分	±10 命中 0.35 → 0.20（权重越大越差）。不是假阴性：20/20 例窗内子主确实变 5–9 次
R4 年精度事件改边际似然（max / lse）	max 命中升到 0.50，但并列率 0.05 → 0.50，把峰值摊成平手
R5 动态签名层	命中下降或持平，熵上升
W1 提高簇上限 / W2 按分差拒绝合并	无收益（见 1.2，合并不触发）
W3 交付区间改分位覆盖	±10 / ±60 能收窄且覆盖不降，但 ±30 有一例把真值挤出区间 → 按红线不放行

1.4 问答链本身是有效的

基线引擎头名簇命中只有 0.35 / 0.15 / 0.10；按真值方向回放六题后升到 0.80 / 0.55 / 0.35。 也就是说：问对题是有用的，瓶颈不在"问了没用"。

2. 还没解决的，只剩一件

区间内部的候选并列。 真机 26% / 26% / 20% 属于这一类：宽度已经收窄，但区间里前两名分数相等。 两轮实测的共同结论是：靠调打分尺度拉不开。要真正分开，只有两条路——

1. 用户再提供带年月的新经历（这是目前唯一被证明有效的信息源）；
2. 接受并列，把它诚实地呈现成"这两分钟分不开"，而不是给一个看似有推荐的代表分钟。

第 2 条已经在产品侧落地（风格参考题前置、并列时说明"按现有信息分不开"）。

3. 产品决策存档

• 2026-09-14：KP 宫头子主参与评分（产品负责人拍板，推翻 BUG-325 防复发条里的"不得把 KP 观察计分"）。方向仍然有效，但 R3 实测表明默认权重不能直接上线，需要单独标定后再谈实现单。

• 2026-09-14：风格题（D9/D10）在出交付卡之前必问（放宽版 A），仍然不淘汰候选、只做 ±1 排序微调；并删除了风格题的事件锚点闸，保留"候选在该分盘上上升星座 ≥2 种"的区分力门。

• 2026-09-14：领域门槛暂不收紧。 上游 R3 要求淘汰与定案需 ≥3 个领域，本仓是 MIN_ACCEPTANCE_DOMAINS=2（scripts/rectification/decision_policy.py:35）。产品决定先不动，等 BUG-689（交付卡上邀请补经历）上线、有真机数据后再评估——那之后用户更容易补到第三个领域，收紧的代价更小。现在收紧会与「永远给结果」的口径冲突。

4. 明确不采用

上游 scripts/ashtakavarga.py 的 PL9_BAV_CELL_OVERRIDES——为对齐某份 PDF 硬编码覆写特定行星/星座的 bindu 值。那是对答案，不是算法修正。

5. 索引

文档	内容
docs/research/upstream_rectification_gap_2026_09_14.md	与上游 yinduzhanxing 的逐项能力对照、许可证边界
docs/research/minute_resolution_2026_09_14.md	第一轮：R1–R5 打分尺度测量（文末有勘误，务必读）
docs/research/cluster_width_2026_09_14.md	第二轮：宽度口径校正、簇结构画像、W1–W3
docs/research/holdout_v4_build_2026_09_14.md	v4 封存基准的构建与标注协议
docs/research/precision_gate_2026_09_14.md	出题闸门分档与 M1b 分盘配权。勘误：M1b 的 V1/V2 标为未测（与 V0 数字完全相同，且 V0 采集未打分盘标签）；V3 结论保留
scripts/research/minute_resolution_sweep.py / cluster_width_probe.py	两轮的测量脚本（离线，未接生产）
tests/test_minute_resolution_research.py / test_cluster_width_research.py	两轮脚本的回归测试

6. 给下一个人的三条提醒

1. 先确认指标口径再下结论。 第一轮的头条结论就是被"不含淘汰"的宽度口径带偏的；第二轮 M0 才把它纠回来。
2. 不要从 docstring 推断行为。 簇合并那条假线索就是这么来的——实测它从未触发。
3. 真值覆盖率优先于区间宽度。 把区间做窄很容易，把真实分钟挤出去是更严重的错误（AGENTS.md Part B B4）。W3 就是卡在这一条。