benchmark-paper

ベンチマーク論文

会場適合スコアカードを作成します。これは、対象会場で最近受賞した論文や被引用数の多い論文の測定可能な傾向に、草稿がどの程度合致しているかを示します。これは投稿前に著者が不足を見つけるための適合度の指標であり、採択の予測、最優秀論文の予測、科学的価値の判断ではありません。

simulate-reviewers（内容の質をレッドチーム分析します）やstudy-exemplars（比較コーパスの作成に使用します）と組み合わせると効果的です。まず preflight-check を実行してください。デスクリジェクトにつながる欠陥があれば、スコアに意味はありません。

使用する場面

• 著者が投稿前に、共有しやすい単一の準備状況の指標を求めている。
• 著者が、自分の草稿が会場の最近の優れた論文と比べてどの程度の水準にあるかを知りたがっている。
• 著者が、模範論文と比べて弱い項目を、修正のしやすさ順に知りたがっている。

使用しない場面（ユーザーにはっきり伝えてください）

• 科学的成果において実際に受賞を左右する、新規性、正確性、重要性は判断できません。内容の批評には simulate-reviewers を使用してください。
• 採択や最優秀論文賞の受賞は予測できません。ツールで予測できると主張する人は、偽りの精度を売り込んでいます。
• 欠陥のある論文で高いスコアが出ても意味はありません。形式への適合 ≠ 内容の質です。

入力

• 草稿：.tex ファイル（またはコンパイル済み PDF／Markdown）。利用可能であれば .bib も含めます。
• 対象会場の ID（例：sigspatial-2026）→ venues/ 内のプロフィール。
• 任意：コーパスのサイズ N（デフォルトは模範論文 8 件）と対象期間（デフォルトは直近 5 年間）。

プロセス

1. venues/conferences/<venue>.yml と、その family: プロファイルである venues/families/<family>.yml から、会場プロファイルを解決します。見つからない場合は、ユーザーに尋ねるか、add-venue-profile で作成します。スコアリングの前に、会場が正しいことを再確認します。鮮度ゲートを適用します：プロファイルは年ごとにバージョン管理されています（verified.valid_window、verified.last_verified_against_cfp）。valid_window に対象サイクルが含まれていないプロファイルから、厳格なフォーマット制約（ページ数上限、段組数、必須セクション、締切）を断定してはいけません。必ず先に最新の CFP を確認してください。確認できない場合は needs-verification としてマークし、その根拠が年の一致しないプロファイルであることを明記します（references/scoring-rubric.md の「Staleness gate」を参照）。年の一致しないプロファイルでも、事前情報（模範論文の分布、標準的な構成）には利用できます。
2. 同じファミリーの模範論文コーパスを構築します。セクション構成、引用密度、アブストラクト構造、図表の慣例といった分布の各次元は、必ず同じファミリーの分布を基準に評価します。別ファミリーの代替指標は決して使いません。次の優先順位で解決します。(a) 対象会場の最新の study-exemplars コーパス。これを推奨します。study-exemplars を呼び出して、会場で最近受賞した最優秀論文と被引用数上位の論文を N 件、必要に応じて適法かつ一時的に取得し、特徴プロファイルを抽出します。論文の本文を同梱または保存してはいけません。(b) フォールバックの事前情報として、ファミリープロファイルの exemplar_distribution ブロックを使います（ファミリーの事前情報に基づくことを明記し、その信頼度も示します）。(c) このファミリーのいずれも存在しない場合は、N を減らし、該当する次元について「同じファミリーの模範論文分布がない」と明記します。他のファミリーの数値を借用してはいけません。受賞論文の一覧を入手できない場合は、被引用数上位の論文を代わりに使い、その旨を記載します。コーパスの根拠（最新データ／ファミリーの事前情報／なし）を明記します。
3. references/scoring-rubric.md に記載された次元（セクション構成、貢献の位置づけ、評価の厳密性を示す要素、主張と引用の密度、アブストラクト構造、図表の慣例、再現性に関する成果物）に沿って、原稿の比較可能な特徴を抽出します。引用の完全性に関する次元の根拠として、verify-citations の出力があれば使用します。各次元の実現レベル（absent／planned／drafted／complete）を判定します。正直な [RESULT]／[TBD]／\todo のプレースホルダーが根拠の大半を占める次元は、弱いのではなく planned です。これを特徴 JSON の realization フィールドに記録します。
4. 各次元を模範論文の分布への適合度として採点し、各数値について根拠（測定内容と模範論文の範囲）を明示します。planned／absent の次元では、実測値ではなく、設計の完全性と具体性（名前を挙げたベースライン、データセット、アブレーション一覧、計算予算を揃えたプロトコル、分散／有意性の方針）を採点します。保留中の [RESULT] 欄は、根拠に「仕様が定められた上で保留」として記載します。python3 scripts/scorecard.py features.json --venue <id> を実行して、決定論的に計算・表示します。総合点を目視で推測してはいけません。スクリプトは、未実現の次元がある場合に planned の次元を「範囲内」の水準より低く制限し、指標名を plan-conformance に変更します。これにより、実行済み論文と比較されることが暗黙のうちに起きるのを防ぎます。
5. 報告：スコアカード（各次元の 0～10 点、および venue-fit／plan-conformance 指標）、修正しやすさ順に並べた最も弱い 3 次元、模範論文のパターンに結びつけた具体的な修正案、必須の注意書きブロックを提示します。計画段階の場合、課題は「設計が弱い」ではなく「実験が未実施」（手順：仕様を定める → 実行する）として説明します。ユーザーがスクリーンショットを撮れる、共有用の一行要約も提示します。

出力

以下を含む scorecard.md：

• 会場適合度指標（0～10）と、平易な英語での1行評価（例：「近年の {venue} の採択論文と構成上は一致しています。評価セクションが不足しています」）。計画・アウトラインの場合、指標のラベルは plan-conformance とし、実行済み論文と比較してはいけません。
• 次元ごとの表：スコア、実現レベル、代表例の範囲、評価対象の値、根拠。
• 優先度の高い修正点：効果 × 容易さの順にランク付け。
• コーパスの開示：根拠となった論文、受賞論文か引用論文か、対象時期、分布が現行の同一分野コーパス、分野プロファイルに基づく事前情報、または存在しない（no on-family exemplar distribution）のいずれか。
• 形式根拠の開示：年が一致しないプロファイルに基づく必須制約がある場合は、現行の CFP と照合するまで needs-verification として示します。
• 注意事項（必須）：適合度は品質ではありません。採択や受賞の予測ではありません。人間による判断が必要です。

ガードレール

• すべてのスコアについて、測定対象と比較した代表例の範囲を明記してください。数値だけを示してはいけません。
• 指標を採択確率や受賞の可能性として示してはいけません。尋ねられた場合は断り、その理由を説明してください。
• コーパスは必要に応じてオープンアクセスのソースから取得し、一時的に処理した後、保存もコミットもしません（study-exemplars を参照）。
• コーパスを満たすために代表例データを捏造してはいけません。N 件に満たない場合は、より少ない件数を基準に評価し、その旨を開示してください。
• これはコパイロットの参考情報であり、最終判断ではありません。決定するのは著者です。

メモリ

ユーザーの論文ディレクトリで共有されている .paper-memory/ 規約を使用します （完全な仕様： paper-memory-convention.md）。

• 開始時： .paper-memory/profile.yml（分野、会場のランク）を読み、代表例の重点を決めます。また、lessons.md を読んで、前回の実行で弱かった次元と、この著者に繰り返し見られる不足点（recurring）を確認し、それらを優先します。
• 終了時： 共有形式 - [YYYY-MM-DD] (benchmark-paper | <scope>) weak-dimension -> recommendation で、長期的に役立つ知見を追記します（重複を除去して日付を付ける reflect-and-improve の reflect_log.py append を使用）。複数の草稿で代表例より劣る次元は recurring、一度限りの不足点は this-paper とします。スコアカード全体ではなく、長期的に有用な要点のみを記録してください。
• .paper-memory/ が存在しない場合は、必要に応じて作成し、プロジェクトの .gitignore への追加を提案してください。ローカル専用であり、アップロードしたり、このリポジトリにコピーしたりしてはいけません。