paper-claim-audit

論文の主張監査：ゼロコンテキストでの証拠検証

🔒 このスキルを /loop、/schedule、CronCreate でラップしないでください。 このスキルは判定を伴います。意図的にゼロコンテキストにした新規レビュアーが、論文と証拠の整合性を評価します。この判定を一定時間ごとに再実行しても、新たな情報は得られません（変化するのは 論文または結果 が変わったときだけです）。この監査の前に必要な 外部の待機時間 をスケジュールしてください。つまり、論文の草稿が完成したら、監査を 1 回だけ 実行します。詳細は shared-references/external-cadence.md を参照してください。

論文のすべての主張が、生の証拠と一致しているか確認してください：$ARGUMENTS

このスキルが必要な理由

実行担当者は実験を行い、論文も執筆します。結果がどうあるべきかを「知っている」ため、確証バイアスが生じます。

• 84.7% を 85.3% に切り上げる
• 平均ではなく、最も良いシードの結果を報告する
• 別の実験設定の指標を引用する
• 実際の差分が 12.8% なのに「15% 改善」と主張する

事前コンテキストがまったくない新規レビュアーは、論文の記述と生のファイルを照合するだけでよいため、こうした問題を発見できます。

他の監査スキルとの違い

スキル	確認する内容
/experiment-audit	実験コードは誠実か？（偽の GT、正規化の不正）
/result-to-claim	データはこの主張を科学的に裏付けているか？
/paper-claim-audit	論文はデータを正確かつ忠実に報告しているか？

基本原則

ゼロコンテキストの、新規レビュアー。 監査担当者に渡すのは次のものだけです。

• 論文の .tex ファイル（主張）
• 生の結果ファイル（証拠）

次のものは渡しません。

• ❌ EXPERIMENT_LOG.md
• ❌ EXPERIMENT_TRACKER.md
• ❌ AUTO_REVIEW.md
• ❌ NARRATIVE_REPORT.md
• ❌ 実行担当者による要約や解釈
• ❌ 過去の監査結果
• ❌ 会話履歴

これはレビュアーの独立性よりも厳格な、ゼロコンテキストでの証拠監査です。

ワークフロー

ステップ 1：ファイルを収集する（実行担当者 — Claude）

論文ファイルと結果ファイルを、内容を読んだり解釈したりせずに特定します。

論文ファイル（主張）— パスはシェルの作業ディレクトリを基準に表示されるため、ls で検索できます。audited_input_hashes に記述するときは、以下の「提出成果物の出力」セクションに従い、論文ディレクトリを基準にしたパス（paper/ プレフィックスなし）を使用してください。

paper/main.tex                # → hash key: main.tex
paper/sections/*.tex          # → hash key: sections/*.tex
paper/tables/*.tex (if separate)   # → hash key: tables/*.tex

結果ファイル（証拠）：

results/*.json, results/*.jsonl, results/*.csv, results/*.tsv
outputs/*.json, outputs/*.csv
wandb-summary.json (if exists)
**/metrics.json, **/eval_results.json
**/config.yaml, **/args.json (experiment configs)

除外するもの（要約や解釈は含めない）：

EXPERIMENT_LOG.md, EXPERIMENT_TRACKER.md, AUTO_REVIEW*.md
NARRATIVE_REPORT.md, PAPER_PLAN.md, findings.md
Any .md file that is an executor-written summary

ステップ 2：新規レビュアーによる監査（GPT-6-Astra — 新しいスレッド、返信なし）

重要：mcp__codex__codex（新しいスレッド）を使用し、mcp__codex__codex-reply は絶対に使用しないでください。 実行のたびに、必ず新しいコンテキストを使用してください。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "ultra"}
  prompt: |
    You are a paper-to-evidence auditor. You have ZERO prior context about
    this research. You will receive only paper source files and raw result
    files. Your job is to verify that every number in the paper exactly
    matches the raw evidence.

    Paper files to read:
    [list .tex file paths]

    Result files to read:
    [list .json/.csv/.yaml file paths]

    ## Audit Protocol

    ### A. Extract Every Quantitative Claim
    For each number, percentage, comparison, or scope statement in the paper:
    - Location (section, table, caption, or inline text)
    - Exact claim text
    - The number or comparison being made

    ### B. Trace Each Claim to Evidence
    For each extracted claim, find the supporting raw data:
    - Which result file contains this number?
    - What is the EXACT value in that file?
    - Match status: exact_match / rounding_ok / mismatch

    ### C. Check These Specific Failure Modes

    1. **Number inflation**: Paper says 85.3%, raw file says 84.7%
       Rule: only standard rounding to displayed precision is allowed

    2. **Best-seed cherry-pick**: Paper says "achieves 90.2%" but
       that's the best of 5 seeds; mean is 87.1%
       Rule: check if paper specifies "average" / "best" / "median"

    3. **Config mismatch**: Paper compares Method A vs Baseline B,
       but they used different hyperparameters / datasets / splits
       Rule: verify config files show same settings for compared methods

    4. **Aggregation mismatch**: Paper says "average over 5 seeds"
       but result files show only 3 runs
       Rule: count actual runs vs claimed count

    5. **Delta error**: Paper says "improves by 15%" but
       actual delta is (85.3 - 73.1) / 73.1 = 16.7%
       Rule: verify arithmetic of all relative improvements

    6. **Caption-table mismatch**: Figure caption describes
       something different from what the figure/table actually shows
       Rule: cross-check every caption against its content

    7. **Scope overclaim**: Paper says "consistently outperforms"
       but only tested on 2 datasets
       Rule: check if language matches actual evaluation scope

    ## Output Format (per claim)
    For each claim, report:
    - claim_id: sequential number
    - location: section/table/figure
    - paper_text: exact quote from paper
    - paper_value: the number claimed
    - evidence_file: which raw file
    - evidence_value: the actual number
    - status: exact_match | rounding_ok | ambiguous_mapping |
              missing_evidence | config_mismatch | aggregation_mismatch |
              number_mismatch | scope_overclaim | unsupported_claim
    - details: explanation if not exact_match

    Overall verdict: PASS | WARN | FAIL

ステップ 3：レポートを作成する（実行担当者 — Claude）

レビュアーの応答を解析し、PAPER_CLAIM_AUDIT.md を作成します。

# Paper Claim Audit Report

**Date**: [today]
**Auditor**: GPT-6-Astra ultra (fresh zero-context thread)
**Paper**: [paper title from tex]

## Overall Verdict: [PASS | WARN | FAIL]

## Claims Verified: [N total]
- exact_match: [count]
- rounding_ok: [count]
- ambiguous_mapping: [count]
- missing_evidence: [count]
- mismatch: [count]

## Issues Found

### [FAIL/WARN] Claim #N: [description]
- **Location**: Section X / Table Y / Figure Z
- **Paper says**: "..."
- **Evidence shows**: ...
- **Status**: [status]
- **Fix**: [specific correction needed]

## All Claims (detailed)

| # | Location | Paper Value | Evidence Value | Status |
|---|----------|-------------|---------------|--------|
| 1 | Table 2 | 85.3% | 85.28% | rounding_ok |
| 2 | Abstract | "15% improvement" | 12.8% | number_mismatch |
| ... |

また、機械処理用に PAPER_CLAIM_AUDIT.json も作成します。

ステップ 4：概要を表示する

📋 Paper Claim Audit Complete

  Claims verified: 24
  exact_match:     18
  rounding_ok:      3
  ambiguous:         1
  ⚠️ mismatch:      2

  Overall: ⚠️ WARN

  See PAPER_CLAIM_AUDIT.md for details.

実行するタイミング

1. /paper-write の後 — 改善ループ前の最初の確認
2. /auto-paper-improvement-loop の後 — 改善ループで数値が変更された場合に再確認
3. 提出前 — 最終確認

他のスキルとの連携

/auto-paper-improvement-loop が読み込む場合（存在するとき）

if PAPER_CLAIM_AUDIT.json exists:
    read mismatched claims
    fix them as priority items in the improvement round

参考情報として扱い、決してブロックしない

/experiment-audit と同じパターンです。

• PASS → 通常どおり続行
• WARN → 警告を表示して続行し、草稿に「提出前に数値を確認」とフラグを付ける
• FAIL → アラートを表示して続行しますが、提出可能とはマークしないでください

HTML ビューのレンダリング（自動、RENDER_HTML = true の場合。デフォルト）

paper/PAPER_CLAIM_AUDIT.md と paper/PAPER_CLAIM_AUDIT.json を書き込んだ後、監査レポートに対して /render-html を呼び出し、判定とクレームごとの内訳を読みやすい HTML ビューで確認できるようにします。

/render-html "paper/PAPER_CLAIM_AUDIT.md" --json "paper/PAPER_CLAIM_AUDIT.json"

完全な Codex レビューゲートを使用します（監査クラスの成果物です。レンダリング忠実性チェックは、このスキルに既存のゼロコンテキストのクロスモデル監査不変条件に一致します）。出力は paper/PAPER_CLAIM_AUDIT.html に配置され、ソースの SHA256 が埋め込まれます。また、レンダリング判定を含む .review.json サイドカーも作成されます。

ブロッキングではありません：/render-html が失敗した場合（ヘルパーがない、Codex MCP を利用できない、ファイル書き込みエラーなど）は、失敗を記録し、スキルは完了したものとして扱います。JSON と MD の判定ファイルが正規の出力であり、HTML ビューは人間の読者向けの便宜的なものです。

プロジェクトの CLAUDE.md で RENDER_HTML = false が設定されている場合、または — render html: false が渡された場合はスキップします。

主なルール

• 実行のたびに必ず新しいスレッドを使用します。 codex-reply は使わないでください。コンテキストを引き継いではいけません。
• 実行者による解釈はゼロです。 ファイルパスのみを使用します。要約はしません。
• 生の結果のみを使用します。 EXPERIMENT_LOG、AUTO_REVIEW、人間による要約は使用しません。
• 丸めのルール。 表示精度に対する標準的な丸めのみを認めます。84.7% → 84.7% または 85% は OK です。84.7% → 85.3% は NOT OK です。
• クロスモデル。 レビュアーは、実行者とは異なるモデルファミリーでなければなりません。

レビューのトレース

各 mcp__codex__codex または mcp__codex__codex-reply レビュアー呼び出しの後、shared-references/review-tracing.md に従ってトレースを保存します（ポリシー C — フォレンジック。黙って省略してはいけません）。shared-references/integration-contract.md §2 のチェーンに従って解決した save_trace.sh を使うか、.aris/traces/<skill>/<date>_run<NN>/ に直接ファイルを書き込みます。--- trace: パラメーター（デフォルト：full）を遵守してください。

提出用成果物の出力

このスキルは、呼び出し元や検出結果にかかわらず、常に paper/PAPER_CLAIM_AUDIT.json を書き込みます。検出器が対象を検出しなかった実行（論文に数値クレームがない場合）では、判定 NOT_APPLICABLE を出力します。数値クレームがあるものの生の結果がない論文では、BLOCKED を出力します。黙ってスキップすることは禁止です。paper-writing のフェーズ 6 と verify_paper_audits.sh は、予測可能なパスにこの成果物が存在することを前提としています。

この成果物は、shared-references/assurance-contract.md のスキーマに準拠します。

{
  "audit_skill":      "paper-claim-audit",
  "verdict":          "PASS | WARN | FAIL | NOT_APPLICABLE | BLOCKED | ERROR",
  "reason_code":      "all_numbers_match | rounding_drift | missing_raw_results | ...",
  "summary":          "One-line human-readable verdict summary.",
  "audited_input_hashes": {
    "main.tex":                              "sha256:...",
    "sections/5.evidence.tex":               "sha256:...",
    "/abs/path/to/results/run_2026_04_19.json": "sha256:..."
  },
  "trace_path":       ".aris/traces/paper-claim-audit/<date>_run<NN>/",
  "thread_id":        "<codex mcp thread id>",
  "reviewer_model":   "<resolved — the model that actually ran (target: gpt-6-astra)>",
  "reviewer_reasoning": "<resolved — the effort that actually ran (target: ultra)>",
  "generated_at":     "<UTC ISO-8601>",
  "details": {
    "total_claims":   <int>,
    "mismatches":     [ ... per-claim issue records ... ],
    "result_files":   [ ... raw files consulted ... ]
  }
}

audited_input_hashes の範囲

この監査呼び出しに渡された宣言済み入力セット、つまり今回の実行で読み込んだ正確な .tex ファイルと生の結果／設定ファイルをハッシュ化します。リポジトリ全体の集合にしてはならず、レビュアーが自己申告したサブセットを使ってもいけません。呼び出し元が main.tex と単一の結果ファイルのみを渡した場合は、その 2 ファイルだけをハッシュ化し、それ以外は含めません。外部検証ツールはこれらのエントリーを再ハッシュ化し、不一致があれば STALE としてフラグを立てます。

パス規則（verify_paper_audits.sh が期待する形式に一致させる必要があります）：論文ディレクトリ内のファイルのキーは、検証ツールに渡される引数である論文ディレクトリからの相対パスにします。したがって、paper/main.tex ではなく main.tex とします。論文ディレクトリ外のファイル（外部の results/ ディレクトリなど）には絶対パスを使用します。検証ツールは os.path.join(paper_dir, key) を使って相対エントリーを解決します。paper/ を先頭に付けると paper/paper/main.tex になり、誤って STALE と判定されます。

判定の決定表

入力の状態	判定	reason_code の例
論文で数値クレームが検出されない	NOT_APPLICABLE	no_numeric_claims
数値クレームが検出されたが、生の結果ファイルが見つからない	BLOCKED	no_raw_evidence
すべてのクレームが生データと一致する	PASS	all_numbers_match
重要な不一致はなく、軽微な丸めのずれのみ	WARN	rounding_drift
重要な不一致がある（数値の誤り、設定の不一致）	FAIL	claim_mismatch
レビュアーの呼び出しに失敗した（ネットワーク／形式不正）	ERROR	reviewer_error

スレッドの独立性

呼び出しごとに、新しい mcp__codex__codex スレッドを使用します。codex-reply は 決して使用しないでください。以前の監査出力（PROOF_AUDIT、CITATION_AUDIT、 EXPERIMENT_LOG、AUTO_REVIEW の要約）をこの監査の入力として受け入れないでください。 新しいスレッドを使うことで、shared-references/reviewer-independence.md に従い、 レビュー担当者の独立性が保たれます。

人間向けの補足ファイル

paper/PAPER_CLAIM_AUDIT.md は、読者向けに JSON と併せて作成されます。 verify_paper_audits.sh に対する正式な情報源は JSON であり、Markdown は 人間向けです。判定によって最終確定をブロックするかどうかは、親スキル （paper-writing Phase 6）と検証スクリプトが決定します。このスキル自体は ブロックせず、出力するだけです。