P0/P1 保存原理・認定器レビュー追補 AI-001：RV-01 の対応と RV-05 の裁定

レビュー記録 AI-001（初版・本文は保持）の続きです。状態：この追補の時点（2026-10-19）の記録。後続の 内部実施の完了記録 で、利用者が裁定者・指摘者・レビュアーの兼任を内部実施として了承し、RV-05 を p0-draft-2 として実装した（§6）。独立性は認定しない・評価用正解の凍結なし。independent_review / evaluation_frozen は false のままです。

1. 版と、旧版が不変であることの確認

レビュー対象の旧版（e73d4ba の固定168ファイルと、559244d までの文書・追加監査）は変更していません。追加したのは次の別系列だけで、共通台帳の対象外（tests/*.py・examples/{p0,p1,p1-a,p1-b,p1-c}/*.json の外）です。既存ファイルで変えたのは、参照を足した examples/README.md と、追補への参照行を足した初版記録だけです。

追加物	内容
examples/review/↗	負例12件（RN01〜RN12）と既知の逸脱1件（KD01）、manifest（生バイト hash・bytes）
tests/review/test_review_negatives.py	系列の閉じ方・hash、必須パス、入力保持、再実行一致、CLI 一致、偽造票が「段の接続」検査を通る点の確認、正常な鎖が認定される対照、KD01 の現行挙動
tests/review/test_budget_sweep.py	固定117例＋負例12件の予算掃引（約20,000評価）と、必要十分な予算の厳密性

python3 -m unittest discover -s tests/review -v   # 追加系列。9テスト、約13秒
python3 -m unittest discover -s tests -v          # 従来の231テスト。tests/review は含まれない
python3 scripts/research/evaluate-p1-d.py --cli --output data/research/p1-d/review-followup   # 従来の20条件

不変の確認結果は §4 の表にあります。期待結果は、各ゲートの意味から手で指定しました（処理系の出力から生成していません）。

2. RV-01 の対応

2.1 追加した負例

RV-01 の7ゲートそれぞれに、そのゲートを無効化したときだけ失敗する例を置きました。

初版のゲート（変異）	追加例	狙い
段票の再計算照合（H07）	RN01〜RN05	始端・終端の改竄と、両段で一貫した偽の政策・依存・翻訳後Q範囲。後者は「段の接続」検査を通るため、実体からの再計算だけが拒否する（テストで接続検査が true であることも確認）
runtime 要求の hash（H11）	RN06	ref は native でも hash が違えば利用不可
依存の hash 照合（H12）	RN07	要求と保存の hash が違う依存だけが利用不可、runtime は利用可のまま
runtime 要求数（H25）	RN08、RN09	0 件・2 件は入力不正
射影の認定条件（P02）	RN10	保持列に収まる Q と収まらない Q の混在は不認定
同じ射影値で旧回答が異なる反例の記録（P03）	RN11	旧固定例が検査していなかった evidence_level・counterexamples を必須パスにする
別添えの照合（P04）	RN12	元記録と一致しない別添えは入力不正

2.2 検出力の確認（変異検査）

初版で「機能テスト213件と117例の必須パスが検出しなかった」変異33件（生存27、P0実体 hash 経由でのみ失敗6）と、予算の退行を想定した追加変異4件（B0〜B3）を、旧テスト／旧例／追加の負例系列／予算掃引で別々に実行しました。数字は失敗した検査の件数です（0＝検出せず）。

変異	場所（e73d4ba）	旧テスト	旧例	負例系列	予算掃引	結果
H07	handover.py:176 段票の再計算照合	0	0	8	0	負例系列が検出
H11	handover.py:320 runtime の hash	0	0	1	0	負例系列が検出
H12	handover.py:319 依存の hash	0	0	1	0	負例系列が検出
H25	handover.py:282-283 runtime 要求数	0	0	2	0	負例系列が検出
P02	projection.py:122 認定条件	0	0	1	0	負例系列が検出
P03	projection.py:119 反例の記録	0	0	1	0	負例系列が検出
P04	projection.py:69-70 別添えの照合	0	0	1	0	負例系列が検出
B0	model.py:52 Budget.tick の1ずれ	92※	3	11※	44	全系列が検出
B1	events.py 打切り行を undetermined にする	34	0	0	1	旧テストと掃引が検出
B2	query.py 打切り行を undetermined にする	50※	2	11※	1	旧テスト・旧例・掃引が検出
B3	forecast.py 打切り行を undetermined にする	15	3	0	1	旧テスト・旧例・掃引が検出

※ model.py・query.py は P0 の実体で、handover 系の操作が実行時に hash を照合するため、これらの変異は handover 系のテスト・例も失敗させる。※の列には機能検出でない失敗が混ざる（B0 の機能検出は旧例3・掃引44など）。

RV-01 の7ゲートは、いずれも追加の負例系列が検出した（旧テスト・旧例・掃引では0）。 残り26件は引き続き機能的な検出がない。内訳は、冗長な防御として等価と判断したもの13件（H01、H02、H05、H06、H08、H19、E14、E16、E17、E24、R03、P06、F08）、RV-07 の S2 の網羅性の欠落12件（H20、E18、E19、E20、R06、F12、および P0 実体 hash 経由でのみ失敗していた Q03、Q04、Q07、D04、D08、V03）、追加監査が検出する R09 の1件です。Q03〜V03 の6件は、旧テスト41・負例系列11という失敗が出ますが、いずれも P0 実体 hash の固定が崩れた副作用であり、検出には数えません（旧例・掃引は0）。

2.3 判定の更新

PO	初版	追補での判定	理由・残る課題
PO07	未判定	修正後適合（AI-001・非独立・独立再確認待ち）	段票のゲート H07 を RN01〜RN05 が検出
PO08	未判定	修正後適合（同上）	P02/P03/P04 を RN10〜RN12 が検出。RV-07 の項目（証明選択など）は別
PO11	未判定	修正後適合（同上）	H11/H12/H25 を RN06〜RN09 が検出
PO12	未判定	修正後適合（同上）。RV-04（S2）と Python 3.11 未実行が残る	評価の見逃し（RV-01）は解消。認定票が実装の同一性を持たない点は未対応
PO04	適合（RV-05 裁定待ち）	適合（現行版は既知の逸脱 KD01、次の契約版で解消）	§3

追加物の作成者は初版のレビュアーと同じ AI-001 で、対象の作成者でも独立確認者でもありません。計画 §7 により、この修正への独立再確認が済むまで、RV-01 は「対応済み・再確認待ち」であり、合格や正解凍結には数えません。 初版の結論 1〜4 は変わりません（S0 なし／独立性未認定／正解凍結なし）。

2.4 予算掃引の位置付けと正直な評価

予算掃引は、初版では私の検査 script で行ったものを、追加系列のテストとして回帰化したものです。追加の変異 B0〜B3（予算の1ずれ、打切り行を undetermined に変える3種）は、掃引でも検出されましたが、旧テストも検出しており、掃引だけが見つける退行は今回の変異では示せていません。 掃引の価値は、個別の退行ではなく、全117例・全予算で「完了済みの行が汚れない」「入力不正が予算不足で別の状態に変わらない」を一括で守る網としての役割にあります。

2.5 残る S2（未対応）

RV-02〜RV-04、RV-06、RV-07（拡張認定の予算0、証明選択、訂正と元が同時刻の境界、events の上限境界など）は本追補で扱っていません。初版の台帳のままです。

3. RV-05 の裁定

裁定者の注記。 利用者の指示により AI-001 が裁定を行いますが、RV-05 の指摘者と同一です。計画 §3 に照らし独立した裁定とは数えません。作成者側の回答は取得していません。確定には利用者（プロジェクト責任者）の承認が要ります。

3.1 問い

確認（review）の recorded_at が、対象の主張（assertion）の recorded_at より厳密に前の入力を、どう扱うか。現行版は構文上妥当として受理し、as_of が両方より後なら主張を採用して supported にします（再現：KD01↗）。

3.2 実測した事実

事実	内容
契約・式	P0 契約は「recorded_at ≤ as_of の主張とその時点までの確認記録だけを使う」とし、確認と主張の前後関係を定めない。PO04 の式も同様
同じ検査層の先例	訂正は「置換元より厳密に後に記録される」ことを検査し、満たさなければ invalid_revision（validation.py:307-310↗）。確認には対応する検査がない
既存の例	固定済みの例（examples/ の JSON から review 系列を除いた全部）の確認 274 件のうち、主張より前のものは 0 件
既存のテスト	4 件が先行する確認を近道として含む。主張の時刻だけを未来へ動かして「未来の主張は見えない」ことを試す構成で、確認の時刻は元のまま（test_p0_definitions.test_unconfirmed_and_future_memberships_cannot_trigger_rules、test_p0_ledger.test_future_unknown_record_does_not_block_historical_view、test_p0_query.test_future_modifier_does_not_affect_historical_view、test_p1_forecast.test_future_assertion_is_not_visible_even_with_earlier_review）
試験適用（隔離コピー）	validation.py に2行を足すと、機能テスト174件のうち失敗するのは上の4件のみ。4件は確認の時刻も未来へ動かせば元の意図のまま通る（確認済み）。handover 系のテストと p1-c の例15件は、P0 実体 hash の固定が崩れて失敗し、P1-d の評価器は snapshot_mismatch で停止する

3.3 選択肢と論点

• A 入力不正にする（review_precedes_assertion）。
• B 受理し、契約に「先行する確認も採用する」と明記する。
• C 受理するが、その確認を無効とみなして保留する。

論点：

1. P0 の recorded_at は台帳への記録時刻で、観察の対象時点とは別です（P0 契約 P13）。確認は対象が台帳に記録された後にしか存在できません。先行する確認は時刻の因果が成立しない記録です。
2. 同じ検査層に、訂正の時刻順を拒否する先例があります。確認だけが検査されないのは不整合です。
3. 来歴が矛盾する入力で採用を確定すると、確認の本人性・時点を根拠に採用する設計（AGENTS.md の「不明な属性を補って確定しない」）に反します。拒否は原情報を消しません（入力側を直して再投入できる）。
4. 移行では、原確認の時刻を保ちたい場面が考えられます。ただし recorded_at は台帳への記録時刻であり、移行元の時刻は別の属性として保持すべきです（現行スキーマにはなく、recorded_at を書き換えて表すことも認めません）。
5. C は拒否と採用の中間状態と診断出力を新設し、意味の面積を増やします。B は PO04 の式に忠実ですが、式が因果を欠いているのが不足です。

想定される作成者側の説明（未取得）：契約が前後関係を要求していない／4件のテストが入力に含む。前者は契約の不足、後者は構成の近道であり、裁定を妨げないと判断します。

3.4 裁定

A を採る。 確認の recorded_at が対象の主張の recorded_at より厳密に前の入力は、構文が妥当でも入力不正とし、理由コードを review_precedes_assertion、error_path を review.recorded_at とする。等しい時刻は許す（時刻の解像度が1秒で、同時の確認があり得るため。訂正の厳密な後続とは性質が異なる）。

適用範囲：検査は P0 の入力検査を共有するため、P0 の問い合わせ・比較、事象の native 検査、予測の報告台帳、archive の解釈可否の検査に及ぶ。

適用時期：現行版には適用せず、次の契約版（p0-draft-2、profile は p0-positive-2 を推奨）で実装する。 理由は二つ。(1) 現行の p0-positive-1 は e73d4ba で固定・レビュー済みで、P0 の実体 hash が handover 系の認定に組み込まれているため、同じ版で変えるとレビューした基準が失われる。(2) 厳格化は、保存済みの archive が「解釈可能」かを変える（audit_replay の判定）ため、旧版の読み方を残す必要がある。現行版の挙動は KD01 で固定し、既知の逸脱として記録する。

PO04 の判定は「適合（現行版は既知の逸脱、次の契約版で解消）」とする。

3.5 適用時の手順（未実施）

1. validation.py の review 検査に次を追加する。

   if review["recorded_at"] < assertions[review["assertion_ref"]]["recorded_at"]:
       raise Problem("review_precedes_assertion", "review.recorded_at")
   

2. P0 契約に規則を追記し、版を p0-draft-2 とする。契約文書・P0 の5ファイルの hash が変わるため、handover.py の P0_SPEC_SHA256・P0_RUNTIME_SHA256、handover_spec.json、それに依存する p1-c の例（consumer.profile_spec_sha256・archive・段票・runtime 要求の hash）、各 manifest、P1-d の台帳を、新しい版として再固定する。旧版（e73d4ba）の台帳と結果は残す。

3. 上の4テストは確認の時刻も未来へ動かす（意図は変えない）。

4. KD01 の期待を known_deviation.after_adoption へ反転し、新規に「等しい時刻は許される」例を加える。

5. 初版の乱数照合（fuzz_oracle.py など）の生成器に、確認が主張以後になる制約を加えて再実行する。

3.6 暫定の運用

現行版を使う間は、入力側で review.recorded_at >= assertion.recorded_at を検査してください。現行版は先行する確認を採用します。

4. 再現記録

対象	コマンド	終了	結果（分母は別々）
従来の開発テスト（追加物を置いた作業ツリー）	python3 -m unittest discover -s tests -v	0	231/231。追加前と同数で、tests/review は含まれない
追加系列	python3 -m unittest discover -s tests/review -v	0	9/9（約13秒）。負例12・既知の逸脱1、予算掃引は129要求・22,991評価
P1-d CLI 評価	python3 scripts/research/evaluate-p1-d.py --cli --output data/research/p1-d/review-followup	0	P1 20/20条件・80/80 JSON・417/417必須パス、P0 22/22・37/37・221/221。bundle 561ef392… 一致
追加監査	python3 -m unittest discover -s tests/audits -v／python3 scripts/research/audit-preservation.py --output data/research/preservation-audit/review-followup	0／0	8/8、拡張 600・単項 256・存在規則 32・PR01 1 すべて通過、束 88f606a8… 一致
固定168ファイル	自前コードで生バイト hash・束 digest を再計算	－	不一致 0、束 561ef392… 一致、manifest 生バイト 1f01ed65… 一致
既存ファイルの変更	git status／git diff	－	追跡ファイルの変更は examples/README.md の2行のみ。src・tests/*.py・scripts・固定の例・契約は不変
変異検査	REVIEW_REPO=$PWD python3 -B data/research/review-001/scripts/mutrun_series.py <ID…>	0	§2.2（37変異）
空白検査	git diff --check	0	指摘なし

追加の script・ログ・hash は data/research/review-001/（Git管理外、SHA256SUMS 参照）にあります。試験適用（§3.2）は隔離コピーで行い、作業ツリーの src は変更していません。

5. 未確認点

• 追加物の独立再確認。裁定の利用者による承認、作成者側の回答。
• 次の契約版での RV-05 の実装と再固定（未実施）。
• 初版の未確認点（Python 3.11、人手による417必須パスの再導出ほか）はそのまま。

6. 後続（同日）：利用者の了承と RV-05 の実装

利用者は、この段階が外部へ提出するものではないことから、裁定者・指摘者・レビュアーが同一である点を了承し、単独で最後まで進めることを指示した。外部（大学関係者）の協力が得られた場合は、レビューが必要な時点にさかのぼって再開する。これを受けた変更は次のとおりで、詳細と再確認は 17-internal-run-ai-001.md にある。

• §3.4 の裁定 A（厳密に前の確認を入力不正）を、契約版 p0-draft-2 として実装した。§3.4 の「profile は p0-positive-2 を推奨」は採らず、profile p0-positive-1 と request／result の schema を維持して契約版だけを上げた。 理由：この研究段階には保存済みの実データがなく、profile を変えると全例（37＋P1の例＋負例系列）の入力を書き換える必要があるのに対し、厳格化で失われるのは先行する確認を含む架空の入力だけで、p0-draft-1 は e73d4ba に残るため。draft-1 の archive を draft-2 で読むと、先行する確認を含むものは解釈できない旨が契約の変更履歴に記載されている。
• §3.5 の手順は、validation.py・契約・4テスト・hash の再固定まで実施した。KD01 は、p0-draft-2 の境界である RN13（厳密に前＝入力不正）と RN14（等しい時刻＝許す）に置き換えた。draft-1 時点の系列は data/research/review-001/snapshots/pre-draft2/ に保存している。
• RV-02〜04、06、07 も修正し、再確認した。