One Problem
マインドアップロード（WBE）を「物語」ではなく「検証可能な研究プログラム」にするには、前進の定義と検証の公共財が先に必要です。EEGFlowは、データ・指標・ルール・再現手順をWebで固定し、研究が積み上がる足場（Commons）を作ります。
TL;DR（人間向け）
3つだけ覚える
- 主張より先に物差し：「何を満たせば前進か」を固定しないと、成果が比較できない
- データだけでも不足：規格（標準）＋置き場（共有）＋評価（ベンチ）がセットで必要
- WBEは特に“すり替え”が起きる：decode（相関）を emulation（生成/因果）と混同しない
このサイトで解く「1問」
問い：「何を満たせば“前進”と言えるか？」を事前に固定し、第三者が同じ入力（データ）で同じ結論（評価）に到達できる状態を作る。
Outcome
- 勝利条件の固定：クレーム階段（L0〜L5）を明示し、L1をL4のように語る“すり替え”を防ぐ
- 再現可能な入力：BIDS等の標準＋メタデータで、解析対象を第三者に渡せる
- 比較可能な出力：スコア・ログ・失敗例まで含む評価スイートを公開する
- 継続運用：ベンチマーク更新、バージョン管理、監査ログで公共財を積み上げる
これは何ではないか（誤解防止）
このページは「マインドアップロードが可能/不可能」を断言する場所ではありません。EEGFlowが作るのは、断言が可能になるための検証基盤です（測定・評価・反証のルール）。
EEGFlow Commons の成果物（公共財）
Data Standard（入力の固定）
BIDS/EEG-BIDSをベースに、課題・刺激・同期・QC・匿名化のメタデータを拡張し、「解析可能な形」で共有できる規格を整備する。
Benchmark Suite（出力の固定）
デコーディング（相関）だけでなく、反事実・介入予測や閉ループ安定性まで含めたタスク群を定義し、同じ物差しで比較できる状態にする。
Registry & Prereg（“やる前”の固定）
実験・解析計画を事前登録し、探索と検証を区別する。プロトコルと変更履歴を残し、報告バイアスを下げる。
Leaderboard & Model Cards（比較の運用）
スコアだけでなく、データリーク対策、失敗例、計算資源、既知の弱点を“カード”として公開し、再現性と安全性を担保する。
具体例：1つの「比較可能な前進」はこう見える
たとえば「EEGから状態を推定するモデル」を例にすると、Commonsとして必要なのは次の4点です。
| 要素 | 最低限の中身（例） |
|---|---|
| 入力（Data） | BIDS準拠のデータ一式、計測条件、同期ログ、QCログ、匿名化/同意の範囲 |
| 手順（Code/Protocol） | 前処理→特徴→学習→評価の固定レシピ、環境情報、乱数シード |
| 出力（Metrics） | スコア（精度/不確実性/頑健性）、失敗例、ベースラインとの差分 |
| 反証（Falsification） | データリーク検査、反事実テスト、刺激条件の変更に対する予測外れの記録 |
これが揃うと「誰がやっても同じ条件で比較できる」ようになり、はじめて進捗が積み上がります。
歴史のケースワークから借りる設計
EEGFlowの設計は“新規発明”ではなく、他分野が既に解いてきた「検証の型」の移植です。代表例は ケースワーク集 に整理しています。
PDB（単一アーカイブ）やBIDS+OpenNeuro（規格＋置き場）、PhysioNet（データ＋評価）、OSF/PROSPERO（事前登録）などの型は、分野が違っても「前進を測れる」構造を作ります。WBEは特に、達成条件と反証条件を先に固定する必要があります。
最初の90日で実装する必須成果物
90-Day Execution Contract
- Day 1-14：「前進の定義」を固定し、L0-L5ごとの合格条件・失敗条件・禁止される主張（すり替え）を明文化する。
- Day 15-28：BIDS拡張メタデータとQCログ仕様を凍結し、必須フィールドを欠くデータは受理しない運用に切り替える。
- Day 29-60：公開EEGデータで再現可能なベースラインを1本実装し、同一環境で再実行して同一スコアが出ることを確認する。
- Day 61-90：反事実/介入予測を含む検証ベンチを公開し、モデル比較表（精度・頑健性・失敗例）を週次更新で運用開始する。
| 期間 | 必須成果物 | 受入条件（Doneの定義） |
|---|---|---|
| Day 1-14 | 評価契約書（L0-L5対応） | 各レベルで「入力」「指標」「閾値」「反証条件」が空欄なしで定義され、ページ間で矛盾がない。 |
| Day 15-28 | BIDS拡張仕様 + QCスキーマ | 必須キー欠落時に検証失敗となる。計測条件・同期情報・QCログが機械可読で抽出できる。 |
| Day 29-60 | 再現可能ベースライン | クリーン環境で3回再実行し、主要指標の差分が事前許容幅内に収まる。 |
| Day 61-90 | 介入込みベンチ + 比較表運用 | 通常条件だけでなく反事実・介入条件のスコアを公開し、失敗ケースを毎週追記する。 |
上記4項目のいずれかが未達の場合、「準備中」ではなく「未達」と明記し、次の主張レベルへ進まない。達成条件を満たさない成果は、研究ノートとしては残しても、検証済み成果としては扱わない。