取り込んだデータについて「実データはこうなっている」と主張するとき、どの観測点で見たかで結論が変わる。取得した原本を直読みするスクリプトと、本番と同じパーサ・正規化を通して保存された値では、見える事実が違う。

実例の型: 公表資料の台帳に全角数字が1件混在する。これを原本直読みで見つけて「実データに全角が実在するので検査を緩める必要がある」と判断したが、取り込みパーサは以前から該当列を正規化してから格納しており、保存後のデータに全角は1件も無かった。緌めた検査は、本来 fail-closed にしたいガードを fail-open へ反転させていた。

判断基準

• 「一次情報を見る」は外部仕様の確認には正しいが、自システムが保持する事実の確認には正しくない。変換を伴う取り込みでは、確かめるべき観測点は入力側ではなく本番と同じ経路を通った出力側
• データの事実を根拠に実装を変えるときは、その観測がどの経路を通ったかを先に宣言する。書き捨ての確認スクリプトは本番経路をバイパスしやすい
• この取り違えは実装を緩める方向へ傾く。「汚い入力が実在する」と信じると、本来厳密にできる検査に正規化や例外を添えてしまう

委譲しているときに効く

実装を他者（人でも AI でも）へ委ねていると、この種の誤認は完了報告の中に「実データで確認済み」として現れるため見抜きにくい。さらにその報告をレビュー側へ渡すと、レビュアーも同じ前提の上で指摘を組み立てるので、誤った前提が複数の工程を通って増幅される。

• データの事実を主張する報告は、主張だけでなく観測経路（どこをどう見たか）を完了報告の契約に含める
• 検証の安い順番は、報告を読む側がすでに動いている本番・実環境へ直接問い合わせること。代替実装を書いて確かめるより速く、しかも経路の取り違えが起きない
• 誤認が判明したら、それを前提に出された指摘・実装をまとめて見直す（一部だけ直すと、緩められた検査が残る）