experiment-audit

実験監査：モデル間の完全性検証

各レビュースロットの前に、レビュアーの選択に従ってください： 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） を、正規のヘルパーリゾルバーを通じて reviewer_route.py で呼び出し、この スロットのティア、毎回新しいコンテキスト、ソース／画像の入力、決定論的なゲートを維持します。 以下の Codex の例／固定指定は backend=codex の場合にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信の契約を使用してください。ルートと実際に返された ID を保存してください； 選択したレビュアーが利用できない場合は REVIEW_UNAVAILABLE とします。実際の ファミリー／完了状況／対象範囲に基づいて受け入れ可否を分類してください。レビュー担当者を含む子プロセスには、 呼び出し元のレビュアー／モデル／推論レベルのオーバーライドを渡してください。生成ワーカーは変更しません。

🔒 このスキルを /loop、/schedule、または CronCreate でラップしないでください。 これは 判定を下すものであり、実験の完全性を評価します。この判定をタイマーで再実行しても新しい情報は得られません。また、ループが自身の出力を受け入れて停止時期を判断すると、 自らの無罪を証明することになります（acceptance-gate.md）。その前段階の 外部待機、つまり実験の完了をスケジュールし、その後で監査を一度だけ実行してください。詳しくは shared-references/external-cadence.mdを参照してください。

実験の完全性を監査します：$ARGUMENTS

このスキルが必要な理由

LLM エージェントは、次のような方法で不正な実験結果を生成することがあります：

1. 偽の正解データ — モデル出力から合成の「参照データ」を作成し、高い一致率を性能として報告する
2. スコアの正規化 — 指標をモデル自身の最大値で割り、0.99 以上にする
3. 実体のない結果 — 存在しないファイルや、一度も呼び出されていない関数の数値を報告する
4. 対象範囲の不足 — 2 シーンのパイロットを「包括的な評価」として報告する

これらは意図的な欺瞞ではありません。完全性を保つ制約がない最適化エージェントに起こりうる失敗モードです。このスキルはその制約を加えます。

中核原則

実行者はファイルパスを収集します。外部レビュアーバックエンドがコードを読み、完全性を判断します。実行者は完全性の判断に関与しません。

これは shared-references/reviewer-independence.md と shared-references/experiment-integrity.md に従います。

定数

• REVIEWER_BACKEND = codex — デフォルトは Codex MCP（ultra）です。Oracle MCP を使うには — reviewer: oracle-pro、Manual Review MCP を使うには — reviewer: manual で上書きしてください。manual-review MCP が利用できない場合は停止してインストールコマンドを表示し、Codex にフォールバックしないでください。詳しくは shared-references/reviewer-routing.md を参照してください。

レビュアーの呼び出し規約

レビュアーを呼び出す際は、REVIEWER_BACKEND に応じて分岐してください：

REVIEWER_BACKEND = codex の場合： 新しいレビュースレッドには mcp__codex__codex を使用します。 追加レビューには mcp__codex__codex-reply を使用し、threadId を再利用します。

REVIEWER_BACKEND = manual の場合： 次の内容で、新しいレビュースレッドに mcp__manual_review__review を使用します： prompt: [Codex に渡すものと完全に同じプロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "<実際の実行者モデル>", "require_reviewer_model": true} 返された threadId を保存します。 次の内容で、追加レビューに mcp__manual_review__review_reply を使用します： threadId: [保存した manual-review の threadId] prompt: [追加レビュー用プロンプト] config: {"model_reasoning_effort": "xhigh", "executor_model": "<実際の実行者モデル>", "require_reviewer_model": true}

プロンプトの忠実性：manual に渡すプロンプトは、Codex が受け取るものとまったく同じテキストでなければなりません。 レビューの追跡は、どちらのバックエンドにも同様に適用されます。

ワークフロー

ステップ 1：成果物を収集する（実行者 — Claude）

内容を読んだり要約したりせず、以下のファイルを見つけて一覧にします。

Scan project directory for:
1. Evaluation scripts:    *eval*.py, *metric*.py, *test*.py, *benchmark*.py
2. Result files:          *.json, *.csv in results/, outputs/, logs/
3. Ground truth paths:    look in eval scripts for data loading (dataset paths, GT references)
4. Experiment tracker:    EXPERIMENT_TRACKER.md, EXPERIMENT_LOG.md
5. Paper claims:          NARRATIVE_REPORT.md, paper/sections/*.tex, PAPER_PLAN.md
6. Config files:          *.yaml, *.toml, *.json configs with metric definitions

判定を含む手動レビューの回答は、必ず Reviewer-Model: <exact-model-id> で始めてください。このセッションで実際に実行中のモデルを executor_model に渡してください。モデルの記載がない場合、モデルが不明な場合、または同じファミリーのモデルの場合は、無罪とは判定できません。推測するのではなく、REVIEW_UNAVAILABLE を出力してください。実行者のモデル名を特定できない場合、手動レビューにおける異なるモデルファミリーという主張は立証できません。報告書では断言せず、その旨を記載してください。

ファイルの内容を要約、解釈、説明してはいけません。 パスの収集のみを行います。

ステップ 2：レビュアーに送信する

選択されたレビュアーバックエンド（「レビュアー呼び出し規約」を参照）に基づき、ファイルパスと監査チェックリストのみをレビュアーに渡します。レビュアーがすべてを直接読み込みます。

codex の場合は、mcp__codex__codex を以下の内容で呼び出します。

• model: gpt-6-astra
• config: {"model_reasoning_effort": "ultra"}
• sandbox: read-only
• cwd: [project directory]
• prompt: [以下の完全なプロンプトをそのまま使用]

manual の場合は、mcp__manual_review__review を以下の内容で呼び出します。

• config: {"model_reasoning_effort": "xhigh", "executor_model": "<actual executor model>", "require_reviewer_model": true}
• prompt: [以下の完全なプロンプトをそのまま使用]

手動レビューでは、Codex 専用の model、sandbox、cwd は使用できません。ユーザーが確認できるよう、同じファイルパスをプロンプトに含めてください。

両方のバックエンドで、以下のプロンプトをそのまま使用します。

You are an experiment integrity auditor. Start from the assumption that the
    evaluation is compromised somewhere — your job is to find where. Be
    adversarial. Trust nothing the author tells you — verify everything
    yourself. Read ALL files listed below and check for the following fraud
    patterns.

    Files to read:
    - Evaluation scripts: [list paths]
    - Result files: [list paths]
    - Experiment tracker: [list paths]
    - Paper claims: [list paths]
    - Config files: [list paths]

    ## Audit Checklist

    ### A. Ground Truth Provenance
    For each evaluation script:
    1. Where does "ground truth" / "reference" / "target" come from?
    2. Is it loaded from the DATASET, or generated/derived from MODEL OUTPUTS?
    3. If derived: is it explicitly labeled as proxy evaluation?
    4. Are official eval scripts used when available for this benchmark?
    FAIL if: GT is derived from model outputs without explicit proxy labeling.

    ### B. Score Normalization
    For each metric computation:
    1. Is any metric divided by max/min/mean of the model's OWN output?
    2. Are raw scores reported alongside any normalized scores?
    3. Are any scores suspiciously close to 1.0 or 100%?
    FAIL if: Normalization denominator comes from prediction statistics.

    ### C. Result File Existence
    For each claim in the paper/narrative:
    1. Does the referenced result file actually exist?
    2. Does the claimed metric key exist in that file?
    3. Does the claimed NUMBER match what's in the file?
    4. Is the experiment tracker status DONE (not TODO/IN_PROGRESS)?
    FAIL if: Claimed results reference nonexistent files or mismatched numbers.

    ### D. Dead Code Detection
    For each metric function defined in eval scripts:
    1. Is it actually CALLED in any evaluation pipeline?
    2. Does its output appear in any result file?
    WARN if: Metric functions exist but are never called.

    ### E. Scope Assessment
    1. How many scenes/datasets/configurations were actually tested?
    2. How many seeds/runs per configuration?
    3. Does the paper use words like "comprehensive", "extensive", "robust"?
    4. Is the actual scope sufficient for those claims?
    WARN if: Scope language exceeds actual evidence.

    ### F. Evaluation Type Classification
    Classify each evaluation as:
    - real_gt: uses dataset-provided ground truth
    - synthetic_proxy: uses model-generated reference
    - self_supervised_proxy: no GT by design
    - simulation_only: simulated environment
    - human_eval: human judges

    ## Output Format

    For each check (A-F), report:
    - Status: PASS | WARN | FAIL
    - Evidence: exact file:line references
    - Details: what specifically was found

    Overall verdict: PASS | WARN | FAIL
    
    Be thorough. Read every eval script line by line.

ステップ 3：解析して報告書を作成する（実行者 — Claude）

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

# Experiment Audit Report

**Date**: [today]
**Auditor**: External reviewer backend, ultra reasoning (cross-model, read-only)
**Project**: [project name]

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

## Integrity Status: [pass | warn | fail]

## Checks

### A. Ground Truth Provenance: [PASS|WARN|FAIL]
[details + file:line evidence]

### B. Score Normalization: [PASS|WARN|FAIL]
[details]

### C. Result File Existence: [PASS|WARN|FAIL]
[details]

### D. Dead Code Detection: [PASS|WARN|FAIL]
[details]

### E. Scope Assessment: [PASS|WARN|FAIL]
[details]

### F. Evaluation Type: [real_gt | synthetic_proxy | ...]
[classification + evidence]

## Action Items
- [specific fixes if WARN or FAIL]

## Claim Impact
- Claim 1: [supported | needs qualifier | unsupported]
- Claim 2: ...

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

{
  "date": "2026-04-10",
  "auditor": "external-reviewer-ultra",
  "overall_verdict": "warn",
  "integrity_status": "warn",
  "checks": {
    "gt_provenance": {"status": "pass", "details": "..."},
    "score_normalization": {"status": "warn", "details": "..."},
    "result_existence": {"status": "pass", "details": "..."},
    "dead_code": {"status": "pass", "details": "..."},
    "scope": {"status": "warn", "details": "..."},
    "eval_type": "real_gt"
  },
  "claims": [
    {"id": "C1", "impact": "supported"},
    {"id": "C2", "impact": "needs_qualifier"}
  ]
}

ステップ 4：概要を出力する

🔬 Experiment Audit Complete

  GT Provenance:      ✅ PASS — real dataset GT used
  Score Normalization: ⚠️ WARN — boundary metric uses self-reference
  Result Existence:    ✅ PASS — all files exist, numbers match
  Dead Code:           ✅ PASS — all metric functions called
  Scope:               ⚠️ WARN — 2 scenes, paper says "comprehensive"

  Overall: ⚠️ WARN
  
  See EXPERIMENT_AUDIT.md for details.

他のスキルとの統合

/research-pipeline で自動実行（参考情報。処理をブロックしない）

パイプラインに統合されている場合、このスキルは /experiment-bridge の後、/auto-review-loop の前に自動実行されます。

/experiment-bridge → results ready
    ↓
/experiment-audit (automatic, advisory)
    ├── PASS  → continue normally
    ├── WARN  → print ⚠️ warning, continue, tag claims as [INTEGRITY: WARN]
    └── FAIL  → print 🔴 alert, continue, tag claims as [INTEGRITY CONCERN]
    ↓
/auto-review-loop → proceeds with integrity tags visible to reviewer

パイプラインをブロックしてはいけません。 FAIL の場合もパイプラインは続行します。ただし、主張には信頼性を示すタグが表示されます。

/result-to-claim による読み込み（存在する場合）

if EXPERIMENT_AUDIT.json exists:
    read integrity_status
    attach to verdict: {claim_supported: "yes", integrity_status: "warn"}
    if integrity_status == "fail":
        downgrade verdict display: "yes [INTEGRITY CONCERN]"
else:
    verdict as normal, integrity_status = "unavailable"
    mark as "provisional — no integrity audit"

/paper-write による読み込み（存在する場合）

if EXPERIMENT_AUDIT.json exists AND integrity_status == "fail":
    add footnote to affected claims: "Note: integrity audit flagged concerns with this evaluation"

主なルール

• レビュアーの独立性：実行者はパスを収集し、レビュアーは判定します。それだけです。
• 決してブロックしない：明確に警告しますが、パイプラインを停止してはいけません。
• ファイルによる切り替え：EXPERIMENT_AUDIT.md がない場合、このスキルは実行されていません。既存の動作への影響はありません。
• 異なるモデル間でのレビュー：レビュアーは、実行者とは異なるモデルファミリーでなければなりません。
• 限界を正直に伝える：この監査で検出できるのは一般的なパターンであり、考えられるすべての不正ではありません。これは安全策であって、保証ではありません。

謝辞

実行者エージェントが偽のグラウンドトゥルースを作成し、スコアを自己正規化した、コミュニティから報告された整合性の問題（#57、#131）に着想を得ています。

レビューのトレース

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