「〜したと報告された」「ドキュメント／設定にそう書いてある」「計画上そう割り当てた」を、それが実際に起きた・効いている証拠として扱わない。最適化するのは、機械的な実行証跡・一次情報・生成物や実挙動の実測で『実在』と『効力』を確認してから判断・完了を宣言すること。避けるのは、自己申告・書面・宣言的設定を額面どおり受け取り、宣言と実態の乖離を静かに残すこと。

判断基準

• 主体の自己申告（AI・サブエージェントの「実行した」「成功した」報告）は、実行イベントログ・権威側データの再取得・書き込み後の読み直し（read-back）で裏づけが取れて初めて事実として扱う。裏づけの無い申告は事実にも逸脱にもカウントしない。
• ドキュメント・コメント・契約・外部仕様の記述は、一次情報や実挙動での再照合を経てからレビュー・設計判断の根拠にする。『書いてある＝効いている／正しい』を信じない。
• 宣言的設定・役割定義・計画上の割り当ては、生成物や実行メタデータの実測で『実際に適用されているか』を確認する。スキーマ検証の無い設定は未知キーを黙殺し、定義と起動処理が結び付かない役割は親設定を黙って継承するなど、静的整合チェックが通っても到達不能が残る。
• ゼロ件の良好メトリクスや『テスト通過』は、検知母数（実施率・カバレッジ）と検証対象の一致を併記して初めて実績とみなす。検知が回っていないゼロや、別 checkout を検証した通過は証拠にならない。

適用条件・例外

外部書き込み・委譲・自動化・宣言的設定・可変な外部契約が絡む判断に効く。純粋に決定論的で即時に読み戻せる操作や、実測コストが確認価値を明らかに上回る些末な場面では省いてよい。実測・一次情報が未取得の段階の推論は『確認待ち』として結論扱いせず、検証されるまで保留する。

根拠（synthesize 元）

• 906 委譲エージェントの外部書き込みは成功報告を信用せず、権威台帳との突き合わせ監査で実在を検証する
• 911 委譲AIエージェントの行動制約は許可ツール設定を信頼境界にせず、実行イベントログの機械判定で検証する
• 910 外部のAI開発プラクティスは要素分解し、対象工程の実在を成果物の実測で確認してから取り込む
• 822 外部・可変な契約はコードコメントでなく一次情報で再照合してからレビュー判断する
• 851 設計ドキュメントは仮実装のcommit値を『現状』として書かず、実測を設計入力に採用する
• 782 ゼロ件の良好メトリクスは検知母数を併記しないと実績と解釈しない
• 898 固定コンテナ経由でテストを流す構成は worktree の変更を検証せず『テスト通った』誤報を生む
• 912 開発手法は『設計成熟度』と『実証成熟度』を分けて評価する