How To Read
ここは“落とし穴回避”のページです。強い主張ほど、(1)定義、(2)指標、(3)反証条件、(4)再現手順、の順に確認します。
Q. EEGFlowは結局、何をするサイト？
A. マインドアップロード/WBEを「検証可能な研究プログラム」に寄せるための検証基盤（Verification Commons）を作るサイトです。 データ（入力）、評価（出力）、ルール（達成条件/反証条件）、運用（継続）を先に固定します。
Q. EEGで“思考”は読める？
A. 「何をどこまで」と定義しないと答えられません。現実には、EEGはノイズや個体差が大きく、さらに言語モデルの事前分布が“それっぽい文章”を作れてしまうため、EEG由来の情報とモデル側の補完を反事実テストで切り分ける必要があります。
EEGFlowの立場は、「派手な読み出し」を否定するのではなく、検証可能な主張に落とすことです（失敗例まで含む）。
Q. decode（デコーディング）と emulate（エミュレーション）の違いは？
A. decodeは“観測を翻訳する”ことで、emulateは“内部状態が時間発展し、介入に反応し、出力を生成する”ことです。 WBEに近づくには、後者を評価できるベンチマーク（介入・反事実・閉ループ）へ寄せる必要があります。
入門（WBE 101）と用語集が近道です。
Q. じゃあ、何を作れば“前進”になる？
A. まずは L0〜L2 が現実的です。つまり「再現できる解析」「比較できるベンチ」「介入予測で検証できるモデル」です。 EEGFlowでは、これを“サイトとして運用できる形”に落とします（テンプレ・ログ・ルール）。
具体的な成果物
- 入力：BIDS/EEG-BIDS + メタデータ + QCログ
- 手順：固定パイプライン + 実行ログ + 失敗例
- 出力：指標（スコア） + ベースライン差分 + 反証条件の結果
Q. なぜ“標準化”がそんなに大事？
A. 標準がないと、同じことを言っているようで違う入力・違う手順・違う指標を比較してしまい、進捗が見えなくなります。 PDBやBIDS+OpenNeuroなどの事例は、分野が違っても「前進を測れる」状態を作った点が共通しています。
ケースワーク集に、設計の型をまとめています。
Q. “ベンチマークの罠”って何？
A. 指標に勝つことが、現実の目的達成とズレる現象です（Goodhartの罠）。 例えば、データリークや過学習でスコアだけ上がる、実装コストが高すぎて実運用されない、などがあります。 EEGFlowでは、失敗例・リーク検査・モデルカードを含めて運用設計します。