入力の判別・検証ロジックで「discriminator フィールドが存在し型が正しいときだけ既知集合と照合する」形は、欠落・null・型不一致の入力が検証をすり抜けて既知扱いになる fail-open の典型パターン。未知種別を数える品質指標があっても、欠落はそもそも照合に入らないため計上されず、品質ゲートが偽 green になる。

実装規則

• 存在検証（フィールドがあるか・型が正しいか）を既知集合照合の前段に置き、欠落・型不一致も「未知」として同じ品質指標へ計上する
• 判別の必要条件（フォーマットを特定するマーカーの存在等）を「あれば使う」でなく「なければ判別不能として明示的に失敗する」に倒す

レビュー観点: 対称性の確認

同じ検証が複数の並行変種（クライアント形式別・レイヤ別・入出力別）に存在するとき、片側だけ塞いだ修正は非対称の fail-open を残しやすい。実例として、2形式のログパーサで一方の discriminator 検証を修正した際、レビューの次ラウンドでもう一方の同型欠陥が指摘された。検証・判別ロジックへの修正をレビューするときは「この検証の兄弟変種はどこにあり、同じ修正が全変種に適用されているか」を明示的な観点にする。修正 diff に片側しか現れないこと自体が兆候になる。

検証

欠落・null・型不一致の検体を変種ごとに独立して置き、「値があるときだけ照合する」対照実装がそれぞれ別の検体で落ちることを確認する。件数だけでなく、すり抜けた入力が通常分類へ混入しないこと（隣接データの汚染）も assert する。