crucible-research-foundations

Research Foundations — 6 epistemic disciplines

Self-Evolving Skill：このスキルは使用を通じて改善されます。ある規律のガイダンスが実際にうまく機能しなかったり、新たな落とし穴が見つかったりした場合は、該当するセクションを更新し、references/evolution-log.md に追記してください。先送りしないでください。

以下の順に読んでください。最初の3つ（因果性、ラベル、ヌル）は最も難しい前提条件です。いずれかに違反すると、その後の結果はすべて気づかれないまま無効になります。

---

1. 因果特徴量の不変条件（bars[:i]）

トリガー／判断バー i で使用するすべての特徴量 f[i] は、bars[0:i] のみを使って計算できなければなりません。bars[i] や bars[i+1:] を使ってはいけません。違反すると先読みバイアスが生じ、分析結果は気づかれないまま無価値になります。

標準パターン：

for i in range(n):
    lo = max(0, i - window)
    wind = values[lo:i]  # EXCLUSIVE upper bound — no peeking
    f[i] = compute(wind)

lo:i（終端を含まない）であり、lo:i+1 ではないことに注意してください。この規律は「インデックスが1つずれているように感じます」が、これが正しい方法です。

検証テスト（新しい特徴量関数ごとに追加してください）：

def test_causality(fn, n=1000):
    bars = generate_test_bars(n)
    f_orig = fn(bars)
    bars_mod = bars.copy()
    bars_mod[500:] *= 2  # perturb the FUTURE
    f_mod = fn(bars_mod)
    assert np.array_equal(f_orig[:500], f_mod[:500]), "look-ahead detected"

バグが潜んでいる兆候：あり得ないほどきれいな結果（FXで tw > 10 bps、勝率 > 70%、OOS が IS と完全に一致するなど）。

詳細なリファレンス：findings/methodology/10-causal-feature-invariant.md。

---

2. ラベル漏洩（バー単位のスケーリングでウィンドウ漏洩を防ぐ）

将来ラベルは、ウィンドウ全体のスケールではなく、トリガーバー自身のレンジを基準にスケーリングしなければなりません。ウィンドウ相対ラベルは同語反復になります。

落とし穴：fwd+H = UP when close[i+H] - close[i] > window.span/20 とラベル付けすると、close[i] が window.min に近い（loc=B）場合、fwd=UP はほぼ自動的に決まります。エージェントは偽の「シグナル」を報告してしまいます。

対策：バー単位のトリプルバリアラベルを使用します。

r = high[i] - low[i]   # THIS bar's range, not window's
tp_level = close[i] + tp_mult * r
sl_level = close[i] - sl_mult * r
# walk forward, exit at first tp/sl/expiry

この落とし穴にはまった兆候：見かけ上のシグナルが loc の五分位に沿って単調に強まり、隣接セルをテストすると崩れます。

詳細なリファレンス：findings/methodology/02-label-leakage-bar-local-scaling.md。

---

3. シャッフルヌルの設計（3種類のヌル — 適切なものを選ぶ）

シャッフルヌルテストは信頼する前に必須ですが、何をシャッフルするかは設計上の判断です。

仮説の種類	何をシャッフルするか	セッションの例
「特徴量 X が結果を予測する」	特徴量の値	Phase F-B（誤ったヌルを使い、実在するシグナルを「反証」した）
「トリガーパターンが情報のあるタイミングで発火する」	トリガーマスクをシャッフルする（発火率を保ち、位置を移動する）	Phase C（ngram_triple_fast_up を z=+5.74 で検証した）
「フィルターが選択を改善する」	フィルターを通過するトレードをシャッフルする	Phase L-C（フィルターを N 件のランダム抽出と比較して評価した）

ルール：「対立仮説を一文で述べると？」と自問してください。それを述べられないなら、何を検証しているのかわかっていません。

よくある間違い：

• トリガーパターンの検証に特徴量シャッフルを使う → パターンが依存する時間構造を壊す → 実際のシグナルがシャッフルしたノイズより悪く見える
• ヌルが緩すぎる（ヌルの標準偏差が観測効果に比べて非常に大きい） → 統計的検出力がない
• ヌルが厳しすぎる（置換回数が少なすぎる） → z 推定値の信頼性が低い。z<3 では ≥100、z<2 では ≥1000 を使用する

詳細なリファレンス：findings/methodology/03-shuffled-null-design.md。

---

4. エージェントによる有意性の補正（zスコアは2～3倍過大評価されます）

LLM エージェントは、体系的に z スコアを過大評価します。エージェントが報告する p 値は上限値として扱ってください。

過大評価のパターンは2つあります：

1. 選択結果を単一の検定として報告する：エージェントが25個のバリエーションを試した（または17,280通りから最上位の組み合わせを選んだ）うえで、勝者のインサンプル z を、あたかも検定が1回だけだったかのように報告します。勝者は仮説であり、発見ではありません。試行回数の補正（Bonferroni、sqrt(2 ln K) による帰無分布の最大値、Deflated Sharpe Ratio、最小バックテスト期間（MinBTL）、FDR/FWER、e-LOND）でこれを修正しないでください。このリポジトリでは、それらを計算、報告、順位付け、引用していません（issue #35）。代わりに、勝者（ルール、しきい値、ウィンドウ）を登録し、どのバリエーションも選択に使用されていないデータで再検定して、その z を報告してください。
2. 標本平均の z と二項比率の z を混同する：N=840 で 53.5% 対 50% の場合、z≈4.2 ではなく z≈2.0 です。

必ず確認してください：

• エージェントは報告対象を示す前に何個のバリエーションを試しましたか？1個より多い場合、報告されたルールは未使用データで確認されていますか？
• z を自分で再計算してください：(real - null.mean) / null.std
• 仮説（ルール、しきい値、ウィンドウ）は実行前に固定されていましたか？試行回数ではなく、モデルそのものの簡潔さを評価してください。

信頼性のしきい値：

• z > 5、N > 500：実在する可能性が高く、追加検証が必要です
• z が [3, 5]：有望です。ゲート検証が必須です
• z が [2, 3]：疑わしいため、隣接セルの勾配と帰無検定が必要です
• z < 2：帰無として扱ってください

完全なリファレンス：findings/methodology/09-agent-significance-corrections.md。

---

5. 記録管理の規律（追記専用台帳 + 監査フォルダー）

すべての調査は、肯定的な結果であっても帰無結果であっても、永続的で見つけやすい記録を残す必要があります。

3層アーキテクチャ：

findings/
├── evolution/
│   ├── evolution.jsonl              # append-only ledger
│   └── audits/
│       └── YYYY-MM-DD-slug/
│           ├── CLAUDE.md            # navigator
│           ├── verdict.md           # plain-English conclusion
│           ├── CHRONICLE.md         # narrative (for major findings)
│           ├── <reproducer>.py      # script that regenerates headline numbers
│           └── <artifact>.json      # raw telemetry
└── methodology/                     # universal principles

台帳エントリのフィールド：id、date、status、supersedes、superseded_by、headline、key_numbers、evidence（ファイルパス）、sha256_results。

supersedes のパターン：後の知見が以前の知見に取って代わる場合は、supersedes: "OLD-ID" を指定した新しいエントリを追加し、古いエントリを superseded_by: "NEW-ID" で更新します。古い監査フォルダーは削除しないでください。

完全なリファレンス：findings/methodology/07-record-keeping-discipline.md。

---

6. 放棄する前の事後分析

シグナルが無効だと結論づける前に、すべての取引にエントリー前の因果的特徴量を加え、個々の損失に対するフィルターを探してください。「ときどき機能する」シグナルは、フィルターで改善できるシグナルであることがよくあります。

パイプライン：

1. 全履歴でシグナルを実行し、N件の取引結果を収集します
2. 各トリガーバーで約20～30個の因果的特徴量を計算します
3. 取引ごとの Parquet + CSV を出力します（1取引につき1行）
4. 複数の視点を持つエージェントに渡します（スキルBを参照）
5. 各エージェントが、勝者と敗者を分けるフィルターを探します
6. シャッフル帰無分布に対してフィルターを評価します（§3を参照）

損失除去選択性の指標：losers_killed / max(1, winners_killed)。< 1.0 = 有害、1.0～1.2 = 限定的、1.2～1.5 = 有用、> 1.5 = 強力。

セッションの例：ベースラインの +0.178 bps → Phase-L フィルター適用後は +0.514 bps。特徴量拡充に基づくフィルター探索により2.9倍改善しました。

完全なリファレンス：findings/methodology/06-per-trade-enrichment-postmortem.md。

---

確認数（暫定、セッション ca9d7ffa 時点）

原則	確認数	備考
1. causal-feature-invariant	18+（全フェーズ）	基本原則です。証明がない限り、削除しないでください
2. label-leakage	2	「下部で棄却率が低い」という見せかけの現象を直接検出しました
3. shuffled-null-design	4	フェーズ F-B の誤った帰無設計、フェーズ C の正しい帰無設計、フェーズ L のフィルター帰無設計、フェーズ M の管理帰無設計
4. agent-sig-corrections	5+	組合せ論、遷移の非対称性、取引管理の各エージェントが、いずれも効果を過大評価しました
5. record-keeping	5 件の記録項目	NGRAM3FU-STRADDLE の全履歴
6. post-mortem	1	フェーズ L でフィルターを特定しました。他のキャンペーンで再確認する必要があります

confirmed が多いほど、信頼性が高くなります。原則 6 は確認が 1 回のみのため、暫定として扱ってください。

---

実行後の振り返り

このスキルを実行した後、次の点を確認してください。

1. 原則を適用してバグや誤検知を発見しましたか？該当する原則の confirmed 数を上の表で増やし、検出されたセッションを references/evolution-log.md に記録してください。
2. 原則が誤ったガイダンスを示しましたか？表でその評価を下げ、references/archive/ に superseded_by ポインターと resurrect_if: 条件を追加してください。
3. 既存の原則でカバーされていない新たな落とし穴はありましたか？ここに新しいセクションを作成し、進化ログに追記してください。
4. 何も記録せずに先へ進まないでください。このスキルの価値は、現実から得られた修正を反映して初めて高まります。