ccf-experiment-designer

CCF Experiment Designer

ファミリーファイルの契約

ファイルを扱う前に、正式なパスと、タスクおよび成果物ごとの作業ディレクトリを再利用してください。デフォルトはプロジェクトルートの ccfa-workfiles/<purpose>/<artifact-id>/ です。ファイルはその場で更新し、入力を保持したうえで、UTF-8を使用し、中国語テキストが含まれていないか確認してください。命名、所有権、タスクで作成したファイルのクリーンアップには、artifact-contracts.md を適用してください。引き継ぎ先でもこれらのパスを引き継ぎます。

コラボレーションの契約

専門担当者による作業を開始する前に、まず ccf-humanization を読み、適用してから、ccf-common を読み、適用してください。引き継ぎのたびに、適用される有効なルールを再利用するか、不足しているルールや変更されたルールを再確認してください。文章がなくても、両方の事前確認が必要です。詳細な編集、実験、保守のモードは、関連する場合にのみ実行してください。

必要な専門担当者からの貢献を、単一の所有者のもとにまとめてください。有効な前提条件を再利用し、影響を受ける結果を検証してください。重複した報告を避け、協力ルートに従ってください。

呼び出し制御

CCFA 引き継ぎモード：PARTIAL（推奨）。 metadata.ccf_skill_controls.handoff_question_mode、../ccf-common/references/handoff-modes.md、../ccf-common/references/task-modes.md に従ってください。

生のプロトコル計画やエビデンスのスキーマ設計を含む、すべての実験作業の前にHumanizationとCommonを有効にしてください。論文用の文章、表、キャプションを作成する場合、または実行可能な実験を変更する場合は、必要に応じて ../ccf-humanization/references/experiment-discipline.md を読み込み、スモークテストを変更された重要なパスに限定し、報告する比較に必要な手法の設定がすべて揃っていることを検証してください。これらの詳細な確認は条件付きですが、ファミリーの基本ルールは常に適用されます。内部の承認状況を明かさずに、手法と科学的に重要な設定を記述してください。未解決のバージョン決定は、重要な事実を隠すことなく、論文用の成果物の外に置いてください。

中心的な仮説と妥当な代替仮説を区別できる、必要十分な最小限の実験パッケージを設計してください。計画された手法には提示された仕様を使用し、手法全体を比較して報告する場合は設定がすべて揃っていることを検証してください。結果表と、エビデンスに基づく図の仕様には、提示された実測値、承認された実行を通じて確認した測定値、または明示的なプレースホルダーを使用してください。数値、改善、統計的有意性、ベンチマーク順位、ユーザースタディの結果を決して捏造しないでください。プロトコルを、反復的なスモークテストや非現実的な防御的ケースで拡張しないでください。論文品質のレイアウト、配色、キャプションの配置、レンダリングの品質確認は ccf-visual-composer の担当です。実験計画、表、LaTeX表、図の仕様、アブレーションのリスト、実行キューなど、ユーザーが求める出力形式に従ってください。

自律的な研究が明示的に求められている場合は、比較プロトコル、必要な実行仕様、実際のフィードバックの解釈を担当してください。これらを ccf-pipeline-orchestrator に返し、タスクが所有する実装と実際のホスト上での実行を調整できるようにしてください。コマンドの失敗と、科学的に否定的な結果を区別してください。エビデンスは、単に別のモジュールを試すだけでなく、異なるメカニズムや探索戦略を採用する根拠になり得ます。このコラボレーションによって、コンセプトのみのアイデアレビューに実験要件が追加されることはありません。

モード

• design：データセット、ベースライン、評価指標、アブレーション、頑健性、効率、失敗分析、実行の優先順位。
• result-template：LaTeXでは \emptycell、Markdownでは — を使った記入用の表。結果の捏造は禁止です。
• result-presentation：提示された実測値、または承認された実行を通じて確認した測定値から作成する結果表、図のエビデンス計画、チャートの仕様、キャプションに含める事実、欠損値マーカー。
• research-iteration：次の研究上の判断に向けた、仮説を識別できるプロトコル、承認されている場合は実行可能な実行仕様、観測結果の解釈。references/evidence-design.md を使用してください。

ワークフロー

1. 両方のファミリープリフライト後に、要求された出力を特定します。生のプロトコル計画とエビデンススキーマには、原稿の書き直しを伴わないHumanizationの基本方針を適用します。詳細な文章や実験のチェックは、該当する場合にのみ選択し、手法のバージョンを確認する前に、主張と利用可能なエビデンスを確定します。
2. アイデアまたは草稿からストーリーラインを抽出します。提示された主張／メカニズムの説明を再利用します。中心的な主張を明確にする必要がある場合に限り、../ccf-paper-writer/references/storyline-blueprint.mdを読みます。すでに結果表で指定されている内容には使用しません。
3. 主な各主張について、その貢献の種類に見合う十分なエビデンスを対応付けます。該当するデータセット／ワークロード、比較手法、指標、そして主張を判別できるアブレーション、分析、証明、または調査を含めます。計画中の手法には提示された仕様を使用し、報告する比較には検証済みの構成を要求します。頑健性テストや失敗テストを追加するのは、観察された問題や妥当なメカニズムに基づいて特定の主張またはプロジェクト上の判断を解決する場合、あるいは検証済みの投稿先要件を満たす場合に限ります。妥当性だけでは無関係なテストを正当化できません。起こりそうもない防御的ケースを列挙しないでください。
4. データセット、ベースライン、指標、またはプロトコルの出典情報が不足しており、それが依存する比較に影響する場合は、ccf-literature-searcherを通じて解決します。まず、提示されている検証済みの情報源を再利用します。計画では、独立した設計作業を止めずに未解決の依存関係を特定できます。中心的な主張との整合性を検証します。重大な主張とテストの不整合が未解決の場合は、焦点を絞った確認をccf-paper-reviewerに依頼し、その指摘を反映します。プロトコルに関する質問に対して、完全なレビュー報告書を作成してはいけません。利用できないエビデンスは推測せず、その旨を明示します。また、一般的な実験チェックリストに合わせるためだけに研究目標を狭めてはいけません。
5. 実質的なプロトコル設計にはreferences/evidence-design.mdを、表／スキーマの作業にはreferences/result-templates.mdを読み込みます。両方が必要な場合を除き、小規模なタスクで両方を読み込まないでください。 結果待ちの原稿では、提示された設計を自動的に実験を追加することなく、その表スキーマに対応付けます。計画段階と完了段階のプロトコルの状態、集計方法、手法の識別情報を保持します。結果の分析欄は空欄のままにして、スキーマを執筆者に返します。値が未確定でも、論文の残りの部分の執筆を妨げることはありません。追加するテストはすべて、特定の主張、比較、または観察された問題に答えるものでなければなりません。パッケージを完成させるためだけに、無関係なカテゴリを埋めないでください。
6. 結果を提示する際は、単位、シード、信頼区間、データセット名、指標の良し悪しの方向性、確認済みの手法のバージョン／構成を保持します。不明な値は明示的に示し、簡略化した実行結果で補ってはいけません。
7. 実行可能な実験コードを実際に変更した場合に限り、重要な実行経路について重複しないスモークテストだけを残します。計画や書式設定だけではスモークテストは不要です。スモークテストは出版用エビデンスとは分け、完全な実験の代わりに使用してはいけません。 許可された研究の反復作業では、references/evidence-design.mdの説明に従って、実行可能な契約を提示し、フィードバックを解釈します。提示または調査済みのコマンド、データ、環境、残りの予算を使用します。実行可能なパスを推測したり、入力が不足しているのに実行成功として扱ったりしてはいけません。必要な入力が未解決でも、独立して進められる準備を続けます。無関係な実験キャンペーンを開始するのではなく、具体的な次の比較または解釈をオーケストレーターに返します。
8. 要求された成果物に視覚的な構成、レイアウト、またはレンダリングが含まれる場合は、ccf-visual-composerを使用します。実際の値、単位、不確実性、指標の良し悪しの方向性、キャプションに必要な事実を渡し、返された図表を取り込み、確認します。生のエビデンススキーマにはレンダリングは不要です。
9. 報告する比較を確定する前に、主張、数値、構成の整合性を確認します。重大な矛盾が未解決の場合は、ccf-integrity-auditorを使用します。原稿の文章が必要な場合はccf-paper-writerを使用し、パッケージの完成度が対象範囲に含まれる場合はccf-submission-checkerを使用します。これらは必要に応じた貢献であり、すべての計画で実行する段階ではありません。

適応型出力契約

まず、要求された成果物を返してください。結果表を求められた場合は、表を出力してください。図を求められた場合は、根拠に基づく図の仕様とキャプションに記載する事実を出力し、視覚的な構成が必要な場合は、次の担当者として ccf-visual-composer を指定してください。実験計画全体を求められた場合は、以下の該当する項目を使用してください。無関係または空の項目は省略してください。スモークテストの範囲は、変更された実行可能コードに限ります。引き継ぎは必要な場合にのみ記載してください。根拠の完全性は作業上のルールであり、自己認証の項目ではありません。

研究の反復では、プロトコルのバージョン、実際の結果と根拠の場所、競合する説明を区別できるかどうか、およびそこから裏付けられる次の判断を記載してください。結果がない場合、比較が無効な場合、または実行エラーが発生した場合は、測定結果が芳しくない場合とは区別してください。単一の指標の改善から、因果的な成功や論文としての公開準備が整ったことを推論しないでください。

Mode:
Venue and assumptions:
Claim-evidence matrix:
Dataset / benchmark needs:
Confirmed method / baseline versions:
Baseline matrix:
Main experiments:
Ablations:
Robustness / failure / efficiency:
Smoke scope and deduplication:
Result tables or figure specs:
Missing values:
Execution priority:
Next CCFA owner:

参考資料

• references/evidence-design.md：自律的な研究における実験とベンチマークの設計、実行仕様、解釈。
• references/result-templates.md：記入式の結果表と発表用のひな形。
• ../ccf-humanization/references/experiment-discipline.md：確認済みの完全な手法ゲート、簡易版の禁止、スモークテストの範囲、および実験から論文への確認事項。
• ../ccf-humanization/references/humanization-policy.md：警告のみ、インジェクションなし、防御的ケースの削除に関する方針。