light-venue-matching

会場マッチング · ステージ 12

提出済みの論文を、監査可能な投稿先の選定につなげます。実際に実行する前に venue-resource-map.md を読み、JSON を作成または使用する前に references/workflow_contract.md を読んでください。最新の情報源を選ぶには references.md を使用してください。 templates/venue_input.json から始めてください。モデルの記憶や同梱の投稿先 一覧から始めてはいけません。

必ず守る境界

1. 組版工程の venue-handoff.json を使用します。その PDF のパスとハッシュ、 DELIVERED、ページ数、ページサイズ、プロファイル／ソース、コンプライアンスの PASS、重大な指摘がゼロであることを確認してください。論文／図／引用／組版の来歴を 保持してください。コンパイル、再フォーマット、ページボックスの再検査を行っては いけません。また、ステージ 11 の UNAVAILABLE をコンプライアンスとして扱っては いけません。
2. 論文執筆工程の原稿／主張プロファイルを、安全な相対パス、スキーマ、SHA-256 を 備えた manuscript_profile.claims_delivery 経由で使用します。投稿先に合わせるために 主張、手法、結果、記事種別、データ規模、証拠の強さを変更してはいけません。参考文献の 真正性は引用工程が、視覚的な正確性は図の工程が担います。
3. 採択率、査読期間、APC／OA、インデックス収載、四分位、募集締切は変化の速い項目として 扱います。実行日当日に確認した情報源を必須とします。確認できない場合は UNKNOWN、UNAVAILABLE、または STALE を出力してください。記憶に頼っては いけません。AVAILABLE の情報源には、監査可能な所在情報（url、query、 locator、または path）、checked_at、access_tier、authority が必要です。 公式ルール／料金／締切には、公式機関／出版社／投稿先の情報源が必要です。 インデックス収載と四分位には、インデックス／登録機関の情報源が必要です。
4. 403／429／5xx、キー／ログイン／購読の不足、robots による拒否、情報源の停止は UNAVAILABLE として扱います。これらは「インデックス未収載」「DOAJ 未収載」 「無料」「リスクあり」を意味するものではありません。
5. 捕食的／乗っ取りの兆候は、最新の複数情報源による人間のレビューが済むまで、 目に見える警告として保持してください。DOAJ に掲載されていないこと、高額な APC、 短い査読期間、勧誘メール、異常な刊行数、または過去の一覧が 1 つあることだけで、 最終判断を下してはいけません。
6. 採択率を推定したり、適合度を採択確率に換算したりしてはいけません。公式の最新採択率は 情報源と日付を付けて使用してください。それ以外の場合は acceptance_likelihood.status=UNKNOWN とします。
7. 候補の発見、証拠の収集、順位付け、提出の各段階では、 decision_point=true と chosen=null を維持してください。停止してユーザーに選択を 求めます。明示的な light.venue_user_selection.v1 のみが選択済みの引き継ぎを作成 できます。ユーザーが直接選択した場合は actor=user として記録してください。 ユーザーが明示的に選択を委任した場合は、その許可内容を一字一句そのまま保持し、 actor=agent_with_user_authorization、decision_authority=user を使用します。 投稿してはいけません。すべての選択記録には、タイムゾーン付きの selected_at と、 because にユーザーが述べたトレードオフを含める必要があります。選択を、レビュー済みの 正確なパケットに decision_sha256 でひも付けてください。パケットが変更された場合、 またはレジストリ／証拠／適合性の成果物が変更された場合は、新たにレビューと選択を 行う必要があります。
8. STAGE_GATES[12]、ROUTES[12]、確認チェックポイント、重大な指摘、または 戻り方向のエッジを捏造してはいけません。ステージ 12 はユーザーが決定する地点であり、 設定済みのゲートもルートエッジもありません。

ワークフロー

1. 実際の投稿成果物を使用する

light.typesetting_venue_handoff.v1 が必要です。次の条件を満たす場合にのみ、 prepare を実行します。

• status=DELIVERED；
• compliance_status=PASS かつ critical_count=0；
• PDF が存在し、その SHA-256 が一致する；
• コンプライアンスレポートが存在し、ページ情報と一致する。

いずれかの条件を満たさない場合は、入力エラーを返し、ステージ 12 の重大な指摘を 作成せずに、著者をステージ 11 に案内してください。

2. 著者の制約を把握する

不足分を独自に補わず、次の内容を記録してください。

• 研究の方向性、論文の種類、手法、データ規模、主張／根拠；
• 著者の段階、地域、必要なインデックス、OA要件、APCの上限；
• 厳守すべき投稿期限と許容できる査読期間；
• リーチ／適合性／安全性の優先度と、移行戦略；
• 受け入れられない投稿先、出版社、ビジネスモデル、リスク。

各制約をハードまたはソフトに分類してください。ハードな著者制約は候補を除外でき、ソフトな希望は順位と説明に反映されます。 主張／根拠のプロファイルは、claims_delivery.path + sha256 + schema を介して現在の論文執筆成果物に紐付けてください。手入力の原稿プロファイルではステージ 12 の要件を満たしません。

3. 網羅性を重視して候補を探し、その後、精度を高めるために検証する

未公開の原稿はローカルに保管してください。公開検索または外部認証が必要な検索を行う前に、原稿を著者承認済みの広い分野／手法ファミリーの用語に置き換え、送信するクエリを事前チェックしてください。

python scripts/query_privacy_gate.py `
  --input templates/query-privacy.example.json

未公開の論文タイトル、要旨、正確な仮説、固有の手法名やデータセット名、結果を記した文、表、図を、公開検索エンジンに送信しないでください。事前チェックレポートには、意図的にクエリのハッシュと一致カテゴリのみを残します。PASS は入力された語句の重複を検出するものであり、匿名性を証明したり、再特定を排除したりするものではありません。

著者が提示した候補リスト、最新の公式 CFP、出版社の検索ツール、venue_discovery.py を使用してください。

python scripts/venue_discovery.py `
  --query "author-approved broad field and method family" --rows 50 --out discovery.json

Crossref のコンテナ頻度で分かるのは候補のみです。対象範囲、順位、インデックス登録、安全性、品質を確立するものではありません。すべての候補発見クエリ、エンドポイント、アクセスレベル、ステータス、確認時刻を記録してください。ISSN と公式名称で重複を除去し、名称の不一致は手動確認用に残してください。

4. 分野ごとのエビデンスを構築する

各候補について、次の項目を個別のエンベロープにまとめてください。

• 公式の対象範囲と記事の種類；
• 長さ／ページ数、図／表、補足資料、匿名性、テンプレート、書式の規則；
• 手法／データとの適合性と、近年の比較可能な論文；
• OA／APC、所要期間、インデックス／四分位、最新の CFP 期限；
• リスク／ハイジャックの確認と、未解決の身元情報の不一致。

規則の確認には公式の投稿先／出版社のガイドラインを、インデックス登録の確認には信頼できるインデックスを、身元の確認には登録メタデータを優先してください。著者が適法なアクセスを提供しない限り、JCR、Scopus、Cabells、機関リスト、有料壁のある項目は利用できないものとして扱ってください。アクセス制御を回避してスクレイピングしないでください。

5. 標準の意思決定パケットを作成する

python scripts/venue_evidence_gate.py `
  --spec venue-evidence.json --report venue-evidence-findings.json `
  --json-out venue-evidence-report.json
python scripts/venue_workflow.py prepare `
  --input venue-input.json --out-dir venue-run --as-of YYYY-MM-DD

候補のエビデンスを収集したら、まず venue_evidence_gate.py を実行してください。これは light.venue_evidence.v2 （templates/venue-evidence.example.json、意図的にフェイルクローズで設計されています）を読み込み、各候補を、対象範囲、記事の種類、読者層、書式、費用、期間、信頼性、戦略という独立した軸で確認します。単一の集約スコアは使用しないでください。 動的な項目には、確認できていない場合、参照箇所、retrieved_at、有効時点／情報源の経過時間、該当する場合はタイムゾーン、および UNKNOWN/UNAVAILABLE/STALE を記載する必要があります。ハードな除外条件には、記事の種類が受け付けられていないこと、公式の対象範囲と一致しないこと、ハードな APC 上限を超える料金、ハードな上限があるのに料金が不明なこと、タイムゾーンがないかすでに過ぎた期限、タイムゾーン対応の as_of がないこと、未来の retrieved_at、身元の不一致／ハイジャック、エビデンスに基づく because がない戦略が含まれます。DOAJ／TCS／情報源の確認に失敗した場合は、否定的なエビデンスではなく未解決のエビデンスとして扱ってください。

実際の PDF のページ数／ページサイズ／プロファイルの事実を、各候補の最新の規則と比較してください。対象範囲、記事の種類、手法／データ、論文の強み、書式、APC／OA、期間、インデックス登録、リスク、著者の制約について、個別に説明してください。公式の記事の種類／ページ数との不一致や、ハードな著者制約は候補を除外する場合があります。ソフトなリスクシグナルは候補を除外できません。

リーチ／適合性／安全性のティアと、移行順序を出力してください。各候補には because とエビデンスソース ID が必要です。不明な項目は信頼度を下げますが、投稿先のランクを暗黙に下げたり、否定的なエビデンスに変えたりしてはいけません。

6. ユーザーの決定を待って停止する

決定パケットを提示し、具体的な質問を1つ尋ねます。選択する候補はどれですか？重要なトレードオフと未解決の項目を提示してください。ユーザーが直接選択するか、明示的に委任しない限り、選択ファイルを作成してはいけません。除外された候補は決して選択しないでください。

正しい例：

候補 A はスコープと手法の適合度は高いものの、公式の基準は論文のプロフィールを上回っており、APC は利用できないため、リーチです。候補 B は記事タイプに適合し、現時点では APC が不要であることを示す証拠があるため、マッチです。どちらを選びますか？

誤った例：

候補 A を選択し、プロジェクトを更新しました。

7. ユーザーの選択を適用する

ユーザーが候補を指定するか、選択を明示的に委任した後、templates/user_selection.json をコピーし、ユーザーが述べた理由または逐語的な承認を記録して、delivery.json.decision_sha256 を decision_sha256 にコピーし、次を実行します。

python scripts/venue_workflow.py choose `
  --decision venue-run/decision-packet.json `
  --selection user-selection.json --out-dir selected

selected-venue-handoff.json と review-rebuttal-context.json を review-rebuttal に渡します。 author-submission-plan.json を著者に渡します。どちらの利用者にも、会場のルール、証拠 ID、不明点、原稿のプロフィール、ステージ 11 の来歴を提供します。 selected_at はタイムゾーン情報を持ち、決定パケットの generated_at 以降でなければなりません。choose は、決定ダイジェストに加えて、候補レジストリ、ソース証拠、適合レポート、不明点の SHA-256／スキーマのバインドを検証します。差異があれば安全側に停止します。投稿当日に変動する項目を再確認し、ポータルへの投稿前に停止してください。

スクリプトの役割

• venue_discovery.py：ネットワークの状態を正直に示す、最新かつ再現率重視の Crossref 検索です。
• query_privacy_gate.py：外部送信クエリのローカル事前チェックです。原稿やクエリのテキストを出力せず、提供された非公開の語句と結果値の重複を検出します。
• venue_workflow.py：正規の引き継ぎの検証、項目状態の正規化、適合度／リスクの説明、決定パケット、ユーザー選択の引き継ぎを行います。
• venue_signal.py：任意の OpenAlex／DOAJ シグナルアダプターです。無料の OpenAlex キーが必要な場合があり、失敗したシグナルはそれぞれ利用不可のままとなります。
• venue_evidence_gate.py：複数の軸を扱う Round 3 の venue_evidence.v2 ゲートです。スコープ／タイプ／コスト／タイムライン／信頼性／戦略を分け、総合スコアによる決定を禁止し、UNKNOWN／UNAVAILABLE／STALE を保持して、ユーザー向け決定パケットの作成前にハード制約との不一致をブロックします。
• venue_fit_rank.py：旧バージョン v1 の候補カードアダプターです。正規のレジストリの代わりに使用しないでください。
• venue_risk_gate.py：任意の旧バージョンの警告のみを行う調査結果アダプターです。ステージ 12 のクリティカルゲートとして使用してはいけません。

提出前のセルフチェック

• 実際の組版済みPDF／ハッシュ／ページ数／ページサイズ／プロファイル／適合性を取り込んでいますか？
• 論文、引用、図、組版の来歴を保持していますか？
• 論文執筆に関する主張／プロファイルのアーティファクトは、安全な相対パス、スキーマ、SHA-256で紐付けられていますか？
• 著者の方針／種類／方法／データ／段階／地域／索引／OA／APC／期限／速度／戦略／受け入れられない条件を記録していますか？
• 公開クエリでは承認済みの広範な用語を使用し、ローカルのプライバシー事前チェックに合格していますか？
• 現在の各フィールドに、出典、クエリ／URL、確認日、アクセス区分、ステータスがありますか？
• venue_evidence_gate.py を venue_evidence.v2 に対して実行し、総合スコアも時期尚早な chosen もなく、候補の各軸について個別に証拠を示していますか？
• 期限のタイムゾーン、料金区分／APC上限、免除、情報源の経過期間、DOAJ／TCSの利用不可状態、識別情報／乗っ取りに関する矛盾を明示していますか？
• 不明、403／429／5xx、キー／ログイン、機関限定、有料の各フィールドを、不利な証拠とせず UNKNOWN/UNAVAILABLE/STALE のままにしていますか？
• 公式の対象範囲／種類／長さを、実際の論文の事実と照合していますか？
• 軽度のリスクは警告にとどめ、ハゲタカジャーナル／乗っ取りの判定は人が行うようにしていますか？
• リーチ／適合性／安全性と引き継ぎの順序のそれぞれに、because と証拠を付けていますか？
• decision_point=true、chosen=null を維持し、ユーザーが明示的に選択する前に選択済みの引き継ぎを行っていませんか？
• ユーザーの選択は、レビュー済みの decision-packet.json のSHA-256に紐付けられ、4つすべての決定アーティファクトが紐付けられたハッシュ／スキーマと一致していますか？
• STAGE_GATES[12]、ROUTES[12]、重大な指摘、自動選択、投稿を捏造していませんか？

実現能力の正直な境界

段階別評価、対象範囲との適合性、APC／期限による絞り込み、リスク警告、著者との適合性、説明可能な推薦は、確立された一般的な仕組みであり、Light独自の機能ではありません。Lightのより限定的な実装上の利点は、実際のステージ11アーティファクトを正規の形式で取り込むこと、フィールドごとの来歴／アクセス／ステータス、不正直な失敗表現を避けること、未選択からユーザー選択済みへとアーティファクトを移行する仕組みを強制できることです。Round 3では、対象範囲の高スコアによって論文の種類、料金、期限、信頼性に関する阻害要因が隠れないよう、複数軸の証拠ゲートを実行可能な形で追加します。 キーワードの重複度や、手法／選択性の区分は、意思決定の支援であり、編集上の判断を予測するものではありません。有料／機関限定の情報源は任意です。