ある層の既存ロジック（例: フロントエンドの選択肢フィルタ）を別の層（例: バックエンドの妥当性判定）に移植して「同じ判定基準」を保証したいとき、ルール本体（何が許可されるかの計算）だけを移植すると不十分。参照実装には暗黙の「選択セマンティクス」が伴うことが多く、それを落とすと判定が厳しすぎる（または緩すぎる）方向に乖離する。

典型例

• 設定が複数マッチするとき、参照実装は find 系で「最初の1件だけ適用」しているのに、移植先で some/every で全件評価すると、参照実装では許容される状態が移植先では違反になる。データモデルが一意制約を持たない限り「複数マッチ」は到達可能な状態として扱う（「UIからは作れないはず」を検証せずに仮定しない）。
• 適用順序に依存する場合は、両層が同じ順序でデータを受け取ること（同一の永続化層・ソート条件由来か）まで確認して初めて等価と言える。

判断基準

• 移植前に参照実装の「マッチした設定・ルールの選び方」（find/some/ソート順/優先度/tie-break）を明示的に洗い出し、移植先で同じ選択を再現するか、意図的に変えるなら差分を設計判断として記録する。
• 選択セマンティクスの再現は順序依存テスト（同じ要素集合を順序を入れ替えて両方検証）で固定する。

検証

「参照実装では許容されるが移植先では違反になりうる入力」を意図的に作って突き合わせる。特に複数マッチ・空値・未設定の境界で乖離が出やすい。