検証パイプライン

この部では、投票の完全性を 4 段階に分けて検証するパイプラインを扱います。

この部の前提となる原則は次の 4 点です。

• 最終的な Verified 判定は fail-closed で、required check が失敗、未実行、保留中、実行中のまま残る場合は successful overall result になりません。verificationStatus や stark_receipt_verify は STARK receipt verification の信号にすぎず、単独で overall verdict を表しません（ゲーティングロジック）。
• 判定確定後に送る POST /api/sessions/:sessionId/finalizations/:finalizationId/verification/observations は observability 専用で、送信の成否が verdict を変更することはありません（設計と実行フロー）。
• public bundle.zip は保護対象 artifact を含まない監査用アーカイブで、public は無認証公開を意味しません（境界の正本は 公開境界）。
• RISC0_DEV_MODE=1 の receipt は production STARK proof ではありません。

この部の章

読み順は次のとおりです。

• 設計と実行フロー：設計原則、パイプライン構造、実行フロー、判定確定後の observability
• 4 段階検証モデル：検証の全体設計と各段階の保証
• チェック一覧：全検証チェック ID とその判定ロジック
• ゲーティングロジック：「Verified」表示の条件と不変条件
• 公開境界：public bundle.zip と protected report artifact の境界
• バンドル構造：証明バンドルの公開可能なアーティファクトと非公開アーティファクト

想定読者と前提

• 想定読者：/verify 画面の最終判定ロジックを把握したい監査者と実装者
• 前提：暗号プロトコル と zkVM 設計 の概要を読み終えていること

この部で扱わないもの

• bundle.zip のローカル監査手順（第三者検証ガイド を参照）
• 改ざんシナリオごとの検出表（改ざんシナリオ を参照）
• UI コンポーネントや Storybook 配置の詳細

関連する章

• 暗号プロトコル：チェック対象となるプリミティブ
• zkVM 設計：ジャーナルとレシートの構造
• 改ざんシナリオ：どのチェックがどの改ざんを検出するか
• 可観測性設計：verdict authority と判定後 observation の分離
• 第三者検証ガイド：bundle.zip を使ったローカル監査
• 用語集：チェック種別とゲーティング用語の定義