Skip to content

decisions.md

Latest commit

 

History

History
728 lines (551 loc) · 47.6 KB

decisions.md

File metadata and controls

728 lines (551 loc) · 47.6 KB
Raw

意思決定ログ

D-001: observation policy を core に入れない

状態: 採用

理由:

  • PF+RobustClear は安定だが局所最適
  • PF3D-BVH+BlockedOnly は高利得だが不安定
  • fixed full-mix は両者をうまく統合できていない

決定:

  • observation policy は python/gnss_gpu/ に入れず、experiments/ で比較する
  • core は expert 実装だけを持つ

D-002: fixed full-mix を mainline 候補から外す

状態: 採用

根拠:

決定:

  • blocked + clear の固定 simultaneous mixture は実験対象には残す
  • ただし採用候補からは外す

D-003: 現在の main experimental baseline は always_robust

状態: 採用

理由:

  • full 6 positive segment では PF+RobustClear が最も安定
  • 論文主張としても安全

決定:

  • mainline で比較するときの基準は PF+RobustClear
  • always_blocked は高利得枝として明示的に別管理する

D-004: disagreement_gate は pilot winner だが採用候補にはしない

状態: 不採用

根拠:

理由:

  • disagreement_m 単独では blocked-rich Tokyo と clean Nagoya を分け切れない
  • tokyo/run1, nagoya/run1, nagoya/run3 で false positive が多い

決定:

  • disagreement_gate は「pilot で見つかった局所有望案」として残す
  • 採用候補からは外す
  • 次の探索では、false positive を抑える veto / persistence を追加する

D-004b: clock_veto_gate は tuned full-6 winner だが holdout では採用しない

状態: 不採用

根拠:

理由:

  • tuned dump に対する overfit の可能性が高い
  • nagoya/run2 のような unseen holdout で still false positive が出る

決定:

  • clock_veto_gate は current gate family の exploratory variant として残す
  • 採用候補からは外す
  • baseline は引き続き always_robust

D-005: richer gate は「複雑だから採用」しない

状態: 採用

理由:

  • rule_chain_gate と weighted_score_gate は feature 数が多い
  • full 6 では rule_chain_gate が disagreement_gate より良いが、それでも always_robust を超えない
  • 可読性 proxy も悪い

決定:

  • feature を増やした strategy は、精度が改善したときだけ残す
  • 改善しない複雑化は捨てる

D-006: ドキュメントは比較軸ごとに分ける

状態: 採用

決定:

D-007: 「正解実装」を作るのではなく dump と evaluator を先に作る

状態: 採用

理由:

  • 同じ input dump を使えないと、variant 間の比較が壊れる
  • 重い PF forward を毎回書き直すと探索速度が落ちる

決定:

D-008: global baseline は always_robust を維持する

状態: 採用

根拠:

決定:

  • 実験の global baseline は always_robust のまま維持する
  • 新しい strategy はまずこの baseline を full validation で上回る必要がある

D-009: pilot winner を採用根拠にしない

状態: 採用

理由:

  • disagreement_gate は pilot では最良だったが full 6 では崩れた
  • この差を明示しないと、探索プロセスが「都合のよい区間選び」に戻る

決定:

  • pilot は候補生成にだけ使う
  • docs の採用判断は full validation ベースで書く
  • experiments.md では pilot と validation を明示的に分離する

D-010: tuned full-6 winner も holdout を通るまで採用しない

状態: 採用

理由:

  • clock_veto_gate は tuned full 6 では最良だったが holdout 6 では落ちた
  • full validation だけでは still tuning leak を防げない

決定:

  • 採用判断は pilot -> tuned full -> holdout の3段階で行う
  • holdout を通らない strategy は exploratory のまま据え置く
  • paper-facing method は holdout 通過済みのものだけ候補にする

D-011: pure blocked-switch family は mainline 候補にしない

状態: 採用

根拠:

決定:

  • pure blocked-switch family は mainline 候補にしない
  • 次に追加する family は blocked-switch の閾値微調整ではなく、別の設計思想にする
  • family search は tuned/holdout 両方で回してから判断する

D-012: dual_mode_regime_gate は first real holdout survivor として残す

状態: 条件付き採用

根拠:

決定:

  • dual_mode_regime_gate は first real holdout survivor として残す
  • ただし current best family の座は固定しない
  • 次の改善対象は tokyo/run1 false positive の削減

D-013: quality_veto_regime_gate を current best state-free family とする

状態: 中間採用

根拠:

理由:

  • dual_mode_regime_gate の close branch に satellite_count と robust_p95_abs_residual を加えるだけで、tokyo/run1 の false positive を減らせた
  • その結果、holdout survivor の性質を保ったまま tuned 微悪化を反転できた

決定:

  • quality_veto_regime_gate は current best state-free family とする
  • global baseline は still always_robust
  • 次の探索は quality_veto_regime_gate を seed に続ける

D-014: hysteresis_quality_veto_regime_gate を current best generalizing experimental family とする

状態: superseded

根拠:

理由:

  • quality_veto_regime_gate の candidate を stateful に保持すると、tokyo_run3_seg974 のような blocked regime の短い off gap を bridge できる
  • その結果、holdout と tuned の両方で quality_veto をさらに上回った

決定:

  • current best generalizing experimental family は hysteresis_quality_veto_regime_gate
  • quality_veto_regime_gate は state-free seed として残す
  • 次の探索は richer temporal state を足す方向に進める
  • この判断は後続の D-016 で rescue_branch_aware_hysteresis_quality_veto_regime_gate に更新された

D-015: branch_aware_hysteresis_quality_veto_regime_gate を balanced exploratory family として残す

状態: superseded

根拠:

理由:

  • close false positive と far true positive は必要な persistence が違う
  • enter だけでなく exit も branch ごとに分けると、holdout は hysteresis とほぼ同等のまま tuned をさらに改善できた
  • ただし holdout-first selection では hysteresis_quality_veto_regime_gate の 65.57 m にまだ届かない

決定:

  • branch_aware_hysteresis_quality_veto_regime_gate は balanced exploratory family として残す
  • holdout-first の current best generalizing family はこの時点では hysteresis_quality_veto_regime_gate を維持した
  • 次の探索は branch_aware に close-singleton rescue を足す方向に進める

D-016: rescue_branch_aware_hysteresis_quality_veto_regime_gate を current best generalizing experimental family とする

状態: superseded

根拠:

理由:

  • branch_aware の弱点は holdout で有益な close singleton を取り逃すことだった
  • close singleton をすべて復活させると train が崩れるが、clean singleton だけ rescue すると hysteresis と同じ holdout を維持しつつ train をさらに改善できた
  • selection rule を holdout RMS -> holdout P95 -> train RMS の順で見ると、rescue_branch_aware... は hysteresis と同値の holdout で train がより良い

決定:

  • current best generalizing experimental family は rescue_branch_aware_hysteresis_quality_veto_regime_gate
  • hysteresis_quality_veto_regime_gate は simpler stateful baseline として残す
  • branch_aware_hysteresis_quality_veto_regime_gate は intermediate exploratory family として残す
  • 次の探索は rescue_branch_aware に negative-evidence か active-branch transition を足す方向に進める
  • この判断は後続の D-017 で negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate に更新された

D-017: negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate を current best generalizing experimental family とする

状態: superseded

根拠:

理由:

  • rescue_branch_aware は holdout gain を回復したが、tokyo_run2_seg1008 では close rescue 後の false persistence がまだ残っていた
  • active close が candidate を外れた epoch で robust_p95_abs_residual 系の negative evidence を見ると、その false persistence だけを切れる
  • その結果、holdout 65.57 -> 65.54 m, tuned 79.53 -> 79.47 m と両 split で strictly 改善した

決定:

  • current best generalizing experimental family は negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate
  • rescue_branch_aware_hysteresis_quality_veto_regime_gate は simpler rescue baseline として残す
  • 次の探索は negative-exit を richer evidence に広げるか、active-branch transition を明示化する方向に進める
  • この判断は後続の D-018 で entry_veto_negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate に更新された

D-018: entry_veto_negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate を current best generalizing experimental family とする

状態: 条件付き採用

根拠:

理由:

  • negative_exit_rescue_branch_aware は tokyo_run2_seg1008 の false close persistence を切れたが、tokyo_run1_seg1463 では non-rescue close entry の 3-epoch false activation がまだ残っていた
  • close sustain 条件そのものは holdout で効いているので崩したくない。一方で close entry だけを robust_p95_abs_residual <= 50 に絞ると、その false activation だけを消せる
  • その結果、holdout は 65.54 m / 81.22 m で据え置きのまま、tuned は 79.47 -> 79.41 m と strictly 改善した

決定:

  • current best generalizing experimental family は entry_veto_negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate
  • negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate は simpler negative-exit baseline として残す
  • 次の探索は entry veto を p95 単独から richer evidence に広げるか、active-branch transition を明示化する方向に進める

D-019: strategy gate の実装・探索フェーズを凍結する

状態: 採用

根拠:

理由:

  • final neighborhood sweep の gain は holdout 0.009 m, tuned 0.061 m で、promotion threshold 0.1 m を下回る
  • current family の近傍では改善が続いていても、論文主張や表の結論を変えるほどの差は出ていない
  • これ以上の gate family 追加は、探索コストに対して paper / result 整理の機会費用が高い

決定:

  • strategy gate の実装・探索フェーズはここで凍結する
  • safe baseline は always_robust
  • exploratory best は entry_veto_negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate
  • 以後の作業は paper / figure / table / limitation 整理を優先し、新 family の追加は行わない
  • 例外は holdout 0.1 m 以上の改善見込みが事前に示せる場合だけとする

D-020: UrbanNav は external validation として固定し、現時点では limitation を正直に出す

状態: 採用

根拠:

理由:

  • PPC だけでは strong accept に必要な external validity が弱い
  • ただし UrbanNav で method を再 tuning すると external validation の意味がなくなる
  • fixed setting の UrbanNav 結果は、現在の PF family が cross-dataset で一貫して勝つわけではないことを示している

決定:

  • UrbanNav は external validation 専用セットとして固定する
  • paper では PPC を design / ablation / holdout、UrbanNav を external validation と明示的に分ける
  • UrbanNav の結果は「method limitation を含む honest result」として載せる
  • 現時点では EKF を UrbanNav external baseline の best classical method とみなす
  • PF と PF+RobustClear の UrbanNav 結果は main accuracy claim ではなく limitation / discussion に寄せる

D-021: UrbanNav multi-GNSS は loader artifact を潰した上で diagnostic track に分離する

状態: 採用

根拠:

理由:

  • 以前の「UrbanNav は GPS-only しか使えない」という理解は dataset limitation ではなく measurement path の実装 limitation だった
  • ただし、loader artifact を潰しても G,E,J はまだ stable result ではない
  • 問題は gate family ではなく、multi-GNSS measurement / ISB / robust-estimation path にある

決定:

  • UrbanNav G,E,J は main paper の external result ではなく diagnostic track として扱う
  • main external comparison は引き続き G の fixed-eval を使う
  • 次に external 側で投資する実装は、新 gate ではなく multi-clock / robust multi-GNSS measurement stabilization とする

D-022: UrbanNav multi-GNSS の first promotable idea は residual/bias veto family

状態: 中間採用

根拠:

理由:

  • UrbanNav multi-GNSS の問題は「multi が効かない」ことではなく、「少数の catastrophic epoch が raw solution を壊す」ことだった
  • solution_gap 単独 veto より、measurement residual と ISB spread を直接見る veto の方が明確に強い
  • best candidate は use_multi_frac ≈ 99.3% で、multi の利点をほぼ保ったまま極端な epoch だけ弾ける
  • best veto は common-epoch では EKF-G も明確に上回る。ただし >500m を完全には 0 にできない

決定:

  • UrbanNav multi-GNSS 側の next core candidate は residual/bias quality veto
  • 逆に、UrbanNav external を改善するために複雑な PF gate family を増やす方針は採らない
  • 次に昇格を検討するなら、experiment script の veto を run_wls または MultiGNSSSolver 周辺の最小 hook に落とす

D-023: UrbanNav external main table は trimble + G,E,J に切り替える

状態: 採用

根拠:

理由:

  • 旧 G-only UrbanNav external では EKF が best だったが、これは loader artifact と GPS-only measurement path に強く制約されていた
  • loader fix と G,E,J external rerun の後では、PF family が両 run で EKF を上回り、tail 指標でも優位になった
  • residual/bias quality veto は “最小昇格抽象” としては正しいが、それ自体は best external method ではない

決定:

  • main UrbanNav external table は trimble + G,E,J の fixed eval に切り替える
  • PF+RobustClear-10K を current best external method、PF-10K を close ablation baseline とする
  • WLS+QualityVeto は promoted core utility として残すが、main accuracy result の主役にはしない
  • D-020 と D-021 の「UrbanNav external は EKF best / G,E,J は diagnostic only」という結論は、現時点では superseded とみなす

D-024: paper packaging は fixed asset builder に集約する

状態: 採用

根拠:

理由:

  • strong accept に近づく局面では、新しい variant 追加より “何を main result として見せるか” の固定化が重要
  • 現在の strongest line は PPC holdout, UrbanNav trimble + G,E,J external, BVH systems
  • paper-ready asset を script 再生成にしておくと、本文更新や GitHub Pages 更新で数字の不一致を防げる

決定:

  • paper 本文・GitHub Pages・図表作成は build_paper_assets.py の出力を基準にする
  • paper_main_table.md を manuscript table の土台にする
  • main figures は少なくとも paper_ppc_holdout.png, paper_urbannav_external.png, paper_bvh_runtime.png の 3 枚で固定する

D-025: UrbanNav external breadth は fixed-window analysis で補強する

状態: 採用

根拠:

理由:

  • main external table はすでに PF+RobustClear-10K 優位だが、run-average 2 本だけだと “lucky sequence” 批判が残る
  • fixed-window analysis は new tuning を持ち込まず、既存 epoch dump から external robustness を細かく再評価できる
  • geography の広さはまだ Tokyo-only だが、少なくとも gain が局所的な artifact ではないことを示せる

決定:

  • main external claim は引き続き full-run table に置く
  • ただし rebuttal / appendix / supplemental では window-level win-rate を併記し、「2 run mean だけ」という弱点を薄める
  • “broad deployment-level generalization” はまだ主張しないが、“external gain is not concentrated in a single interval” は主張してよい

D-026: Hong Kong 2019-04-28 は現時点では negative control として扱う

状態: 採用

根拠:

理由:

  • Hong Kong 2019-04-28 では利用可能 nav が GPS-only で、median 6 satellites の low-satellite regime になっている
  • この設定では current PF family は Tokyo trimble + G,E,J のようには一般化しない
  • したがって残る外部妥当性の弱点は “Tokyo run average only” ではなく、“multi-GNSS repaired regime を超えた geography transfer” である

決定:

  • main paper table と main figure は引き続き Tokyo trimble + G,E,J external を使う
  • Hong Kong 2019-04-28 は supplemental / limitation / future-work 向けの external control として保持する
  • 次に geography を本当に広げるなら、Hong Kong 側でも mixed-nav path を確保するか、別の multi-GNSS external sequence を追加する

D-027: EKF anchor rescue は safety variant として残すが mainline には昇格しない

状態: 採用

根拠:

理由:

  • EKF anchor rescue は geography transfer 時の catastrophic collapse を止める safety policy としては有効
  • しかし current main external setting では unnecessary intervention が増え、Tokyo external の主結果を壊す
  • したがって “global best PF method” ではなく “failure-recovery utility” として扱うのが妥当

決定:

  • current main UrbanNav external method は引き続き PF+RobustClear-10K
  • PF+EKFRescue-10K と PF+RobustClear+EKFRescue-10K は supplemental safety variant として保持する
  • paper では、Hong Kong negative control を完全に捨てるのではなく、「raw PF collapse を止める補助 variant はあるが、mainline winner ではない」と正直に書く

D-028: PF+AdaptiveGuide-10K は cross-geometry mitigation として残すが main table は置き換えない

状態: 採用

根拠:

理由:

  • 弱点は「guide が効かない」ことではなく、「同じ guide policy を全 regime に固定すると壊れる」ことだった
  • sparse single-constellation では reference velocity が本体で、multi-GNSS repaired regime では robust-clear + guide-init が safer
  • ただしこの adaptive split はまだ Tokyo full external main table で再検証しておらず、current paper headline を置き換えるには早い

決定:

  • PF+AdaptiveGuide-10K は cross-geometry weakness を減らす supplemental variant として保持する
  • current main UrbanNav external method は引き続き PF+RobustClear-10K
  • paper では PF+AdaptiveGuide-10K を “Tokyo mainline を置き換える headline method” ではなく、“Hong Kong collapse を raw PF without rescue よりずっと狭くする regime-aware mitigation” として書く

D-029: full-run UrbanNav では PF+AdaptiveGuide-10K を mainline に昇格しない

状態: 採用

根拠:

理由:

  • 3k subset では見えた adaptive gain が full-run Shinjuku では維持されなかった
  • つまり adaptive guide は cross-geometry mitigation としては有効だが、Tokyo main external setting の global winner ではない
  • paper main table を差し替えるには、RMS と P95 の両方で PF+RobustClear-10K を明確に超える必要がある

決定:

  • current main UrbanNav external method は引き続き PF+RobustClear-10K
  • PF+AdaptiveGuide-10K は supplemental result として残す
  • GitHub Pages / paper main assets は現状の PF+RobustClear-10K 主体のまま維持する

D-030: Odaiba reference/guarded の DD carrier adaptive floor は 0.18、stop-detect は 0.25 を維持する

状態: 採用

根拠:

  • exp_pf_smoother_eval.py
  • test_exp_pf_smoother_eval.py
  • odaiba_reference: 0.25 baseline は FWD 1.46 / 5.57 m, SMTH 1.38 / 5.08 m。0.18 は FWD 1.42 / 5.46 m, SMTH 1.38 / 5.02 m。
  • odaiba_reference_guarded: 0.25 baseline は FWD 1.46 / 5.57 m, SMTH 1.38 / 5.43 m。0.18 は FWD 1.42 / 5.46 m, SMTH 1.38 / 5.36 m。
  • odaiba_stop_detect: 0.25 baseline は FWD 1.19 / 4.57 m, SMTH 1.36 / 4.11 m。0.18 は FWD 1.63 / 5.50 m, SMTH 1.34 / 4.11 m。

理由:

  • coverage-hole 調査では、tracked fallback preference、ESS-only weak-DD replacement、spread-aware support-skip、contextual low-ESS epoch-median gate は full Odaiba の win にならなかった。
  • reference/guarded では単純な adaptive floor tightening が forward と smoother RMS を少し改善した。
  • stop-detect では smoother RMS は変わらない一方で forward quality が大きく悪化したため、headline best preset には入れない方が安全。

決定:

  • odaiba_reference と odaiba_reference_guarded は --mupf-dd-gate-adaptive-floor-cycles 0.18 を使う。
  • odaiba_stop_detect は --mupf-dd-gate-adaptive-floor-cycles 0.25 を維持する。
  • weak-DD 調査で追加した extra knobs は default-off の ablation surface として残すが、full-run win なしに preset へ昇格しない。

D-031: L1-L2 widelane DD pseudorange は default-off 実験 hook として残すが preset 昇格しない

状態: 採用

根拠:

  • widelane.py
  • exp_pf_smoother_eval.py
  • test_widelane.py
  • Odaiba 100 epoch smoke は SMTH P50=0.80 m / RMS=0.79 m、WL fixed pairs 568/600 (94.7%)
  • full Odaiba default WL は SMTH P50=1.83 m / RMS=4.91 m、WL used 8926/12252, fixed pairs 50042/52665 (95.0%)
  • full Odaiba conservative WL は SMTH P50=1.45 m / RMS=5.62 m
  • Shinjuku WL regression は SMTH P50=3.07 m / RMS=9.13 m
  • non-WL run_pf_smoother_odaiba_reference.sh は SMTH P50=1.34 m / RMS=4.11 m で維持

理由:

  • WL integer fix 自体の成立率は高いが、full-run の PF smoother median は改善しなかった。
  • 現実装は GPS/QZSS L1-L2 fixed DD を epoch 単位で DD pseudorange path に差し替えるため、既存 raw DD pseudorange の Galileo constraints を落とす。
  • sigma を弱めても current best SMTH P50=1.14 m には届かず、RMS/回帰条件が悪化する。
  • smoke の submeter は局所区間の結果で、full Odaiba の headline 指標へ一般化しない。

決定:

  • --widelane hook と gnss_gpu.widelane module は default-off の実験 surface として残す。
  • odaiba_best_accuracy は変更しない。
  • odaiba_widelane preset は作らない。
  • 次に試すなら、epoch-level replacement ではなく row-level merge または additional likelihood として、Galileo raw DD constraints を落とさない設計にする。

D-032: Region-aware widelane gate は full-run win なしで revert

状態: 不採用

根拠:

  • widelane_gate_odaiba_sweep.csv
  • widelane_gate_validation.csv
  • Odaiba baseline odaiba_best_accuracy: SMTH P50=1.1435 m / RMS=4.3627 m
  • handoff 推奨 dd17 + ratio5: SMTH P50=1.4481 m / RMS=4.3590 m, WL used 250/12252
  • WL 実使用ケースの最良 dd17 + ratio7: SMTH P50=1.2454 m / RMS=4.9972 m, WL used 223/12252
  • dd20 + ratio3/5/7 は WL used 0/12252 で baseline 同等
  • Shinjuku dd17 + ratio7 は WL used 0/20127 で baseline と同一、SMTH P50=2.286 m / RMS=7.548 m
  • run_pf_smoother_odaiba_reference.sh は SMTH RMS=4.112 m で <=5.10 m guard を維持

理由:

  • 「強い DD epoch だけ WL 適用」の仮説は full Odaiba で current best を超えなかった。
  • DD support を強くすると WL 適用 epoch が少なくなり、dd20 では完全に baseline へ戻る。
  • DD support を緩めると WL は使われるが、P50 が 1.29-1.69 m まで悪化する。
  • 最も近かった dd17 + ratio7 でも current best から +0.10 m 以上悪く、submeter には届かない。

決定:

  • odaiba_widelane_gated preset は作らない。
  • region-aware WL gate CLI/logic/test は negative result として revert する。
  • codex9 の base --widelane hook は D-031 のとおり default-off 実験 surface として残す。

D-033: Phase 1 per-particle NLOS rejection は preset 昇格しない

状態: 不採用

根拠:

  • per_particle_nlos_phase1_summary.csv
  • per_particle_nlos_phase1_sweep.csv
  • Odaiba baseline odaiba_best_accuracy: SMTH P50=1.14 m / RMS=4.36 m
  • default Phase 1 (undiff PR 30 m, DD PR 10 m, DD carrier 0.5 cyc): SMTH P50=64.07 m / RMS=91.98 m
  • specified all-gate sweep (DD PR in {5,10,15,20} m, DD carrier in {0.3,0.5,0.7} cycles): best SMTH P50=59.62 m / RMS=63.12 m
  • no-undiff variant (DD PR 10 m, DD carrier 0.5 cyc): SMTH P50=6.75 m / RMS=8.92 m
  • safest DD-carrier-only variant (DD carrier 0.3 cyc): SMTH P50=1.38 m / RMS=4.61 m
  • Shinjuku DD-carrier-only regression: SMTH P50=2.35 m / RMS=7.95 m, below the <9.5 m RMS guard but not an Odaiba win
  • run_pf_smoother_odaiba_reference.sh: SMTH RMS=4.11 m, existing reference guard maintained

理由:

  • Per-particle rejection is not free: particles can explain different satellite subsets, which preserves diversity but also lets wrong modes survive in weak-DD sections.
  • A minimum-inlier fallback is required to avoid reject-all particles, but even with that guard the Odaiba median degrades.
  • DD carrier-only is stable enough as an ablation surface, but it does not beat current best or reach submeter.

決定:

  • --per-particle-nlos-gate remains a default-off experimental hook.
  • odaiba_rbpf_nlos preset は作らない。
  • odaiba_best_accuracy は変更しない。
  • 次に進むなら Phase 2 の per-particle velocity/RBPF 側で mode survival を制約する。

D-034: Solver-state lightweight wrapper を opt-in research module として追加

状態: 採用 (interface only)

根拠:

  • PR #42 (docs: tokyo/run2 8.13pp residual is an accepted modeling ceiling) が tokyo/run2 8.13 pp 残差の3つ取り組み (linear correction / hidden-high classifier / abstention) を null result としてクローズし、ceiling lift の3つの out-of-scope path を列挙した。
  • PLATEAU_BRIDGE_INTEGRATION.md "Why the residual is not closeable": 1番目の path "Solver-state lightweight wrapper" は medium-size PR であり model input contract を変更するもの。
  • 現状の product 契約 (product_deliverable/README.md §1) は rtk_* / solver_demo5_* を runtime feature から除外、6 列はすべて training target としてのみ使用。
  • experiments/_common._is_metadata_or_label が rtk_* / solver_* を gate して runtime feature 入りを防いでいる。

決定:

  • experiments/solver_state_wrapper.py を追加: 6列 (solver_demo5_ratio_{mean,p90,p95,mean_past_delta}, rtk_lock_p90_p50{,_past_delta}) の curated allowlist + SolverStateWrapper.validate / curate / runtime_feature_columns。
  • experiments/augment_window_csv_with_solver_state_wrapper.py を追加: window CSV → curated subset を sanitise した CSV を出す CLI (research input prep).
  • tests/test_solver_state_wrapper.py で allowlist / non-finite handling / default gatekeeper 不変性 を検証。
  • 既存の train_ppc_solver_transition_surrogate_stack.py / product_inference_model.py は wrapper を import せず、deployed run-MAE 1.79 pp は維持。
  • ceiling lift を実証する training script + LORO 評価は follow-up PR に分離 (target leakage 注意点を wrapper module docstring に記載済み)。

理由:

  • Path 1 を opt-in interface として確保することで、follow-up での research path を ready にしつつ、deployed contract と adopted artefact の両方を変更しない。
  • 既に existing 6 列が training target として材料化されているため、wrapper は新規 column 計算でなく allowlist + sanitiser に責任が限られ、medium-size PR として収まる。

D-035: Path 1 LORO 評価で ceiling 解消、ただし predictor の役割が "post-demo5 QA" にシフト

状態: 採用 (parallel model class として; deployed §7.16 stack は併存)

根拠:

  • experiments/train_ppc_solver_state_wrapper_loro.py で 197 windows / 6 routes の strict LORO を実行。3 variants (default GBR、no hyperparameter tuning):
    • baseline_no_solver_state (5873 features, no rtk_/solver_): run-MAE 12.39 pp / window-MAE 25.07 pp
    • treatment_with_curated_six (5879 features, baseline + curated 6): run-MAE 1.43 pp / window-MAE 5.05 pp
    • curated_six_only (6 features only): run-MAE 1.66 pp / window-MAE 4.76 pp
    • 参考: deployed §7.16 + isotonic75 + phaseguard = run-MAE 1.79 pp / window-MAE 15.85 pp
  • Tokyo/run2 (PR #42 で accepted ceiling とした 8.13 pp 残差): treatment 3.39 pp / curated_six_only 1.50 pp で ceiling lifted。
  • curated_six_only ≈ treatment_with_curated_six (差 0.23 pp)。残り 5873 features は signal 追加せず、curated 6 が dominant feature。
  • 詳細: internal_docs/product_deliverable/D034_PATH1_LORO_RESULTS.md。

注意 (tautology):

  • curated 6 は demo5 自身の ambiguity-fix-state confidence。"demo5 confidence → demo5 success" の予測は半 tautology であり、predictor は post-demo5 QA tool に役割が変わる (pre-demo5 estimator としては使えない)。
  • 用途別影響: README §2 の offline-QA / route-ranking はどちらも demo5 を実行済み前提なので両立可能。real-time / online は不可。

決定:

  • D-034 で ship した interface を活用する evaluation script experiments/train_ppc_solver_state_wrapper_loro.py + 結果 CSV experiments/results/d034_loro_results.csv + analysis doc D034_PATH1_LORO_RESULTS.md を follow-up PR (#44 想定) として ship。
  • Path 1 を parallel model class として位置づける: deployed §7.16 stack (pre-demo5 estimator) は retire しない。post-demo5 QA は別の deliverable として将来追加可能。
  • README §1 contract 文言は変更しない (default contract は依然 rtk_/solver_ を runtime から除外)。新しい model class は wrapper を opt-in した派生として記録のみ。

理由:

  • 1.66 pp run-MAE は deployed 1.79 pp を上回るが、tautology を踏まえると "別問題への新解" であって "同問題の改善" ではない。両モデルを並立させることで ambiguity を残さない。
  • §7.16 stack の elaborate transition-surrogate scaffolding (6列を target として使う) は、6列が runtime feature でないことを前提にした正当な設計。Contract change で stack の存在意義が消えるわけではない (pre-demo5 use case は依然 stack のみ対応)。

D-036: Path 1 (post-demo5 QA) を product deliverable bundle に opt-in 列として exposure

状態: 採用 (deployed §7.16 stack の側に並列、build_product_deliverable.py --path1-prediction-csv で opt-in)

根拠:

  • D-035 で path 1 を parallel model class として採用したが、product deliverable bundle (route_level_fix_rate_prediction.csv, window_level_details.csv) への露出形式は未決定だった。
  • 別ファイル (post_demo5_qa_route.csv 等) にすると operator が adopted と path1 を相互参照しづらくなる。同ファイルに path1_* 列を追加する形なら 1 行で adopted と post-demo5 QA の値を比較できる。
  • Path 1 input (d034_path1_per_window_predictions.csv) が無いケース (deployed flow で wrapper.curate(df) を回していない場合) との互換性のため、--path1-prediction-csv を渡したときだけ列が増える optional column schema にする。

実装:

  • experiments/train_ppc_solver_state_wrapper_loro.py に --per-window-output-csv flag を追加。curated_six_only variant の per-window 予測 (197 行) を experiments/results/d034_path1_per_window_predictions.csv に書き出す。
  • experiments/build_product_deliverable.py に --path1-prediction-csv flag を追加。指定時のみ:
    • window_level_details.csv に path1_pred_fix_rate_pct, path1_abs_error_pp を追加
    • route_level_fix_rate_prediction.csv に path1_pred_fix_rate_pct, path1_abs_error_pp, path1_lift_pp (= adopted_abs_error_pp - path1_abs_error_pp、正なら path1 の方が正確), path1_role_note (固定文字列で role caveat) を追加
  • 既存 deployed flow (predict.py) は --path1-prediction-csv を渡さないので、列も増えない (backward compatible)。

確認:

  • 6 routes 中 5 routes で path1 lift が −0.04 〜 −2.34 pp (path1 の方が adopted より少し悪い)。
  • Tokyo/run2 だけ path1 lift +6.63 pp (8.13 pp ceiling を 1.50 pp に圧縮)。focus windows w7/w9 (false_high)、w23-w25 (hidden_high) すべて 1-2 pp 以内に解消。
  • 全 6 routes 平均 path1 abs error: 1.66 pp (D-035 報告値と一致)。

理由:

  • 同ファイル列追加は ambiguity を最小化 (operator が lift_pp 列を見るだけで "ここでは path1 を信用すべきか" が判定できる)。
  • path1_role_note 列で各 row に "post-demo5 QA tool であって pre-demo5 estimator ではない" という caveat を埋め込み、tautology を忘れさせない。
  • --path1-prediction-csv を opt-in にすることで、real-time / online 用途の deployed flow は contract 変更なしで運用できる。

現在の未決定事項

  • always_robust と entry_veto_negative_exit_rescue_branch_aware_hysteresis_quality_veto_regime_gate を main paper でどう位置づけるか
  • strategy 差分が出る epoch をどの figure で見せるか
  • blocked score は完全に不要か、それとも veto 付きなら使えるか
  • readability/extensibility proxy をどこまで信頼するか
  • Path 2 (more PPC data) / Path 3 (architectural pivot) の優先度