計画が「Xを実現したい」と動機を書き、実装がある定数・閾値でそれを実現したとき、その定数が動機を実際に満たすかは、定数の意味をドメインの数式・不等式に展開して確かめる。定数がコードとテストで整合していても、動機を満たしていないことがある。実装が計画通りであることと、動機が達成されていることは別。

例

「枠が重ならなくなった対象も対応付けたい」という動機に対し、平均寸法で正規化した中心距離の上限を 1.0 に設定した。しかし軸平行矩形が非重複であることは「中心差の絶対値 ≥ 寸法和の半分」と同値で、平均寸法で正規化すると『非重複 ⟺ 正規化距離 ≥ 1』が恒等的に成り立つ。よって上限 1.0 が受け入れる非重複配置は、片軸がちょうど 1.0・他軸が 0 の「辺が接するだけ」という測度ゼロの一点だけ。実際に効いていた緩和は別条件（重なりが正なら概ね可）であって、動機の「非重複の受容」ではなかった。コードは計画に忠実でも、計画の背景と選んだ値が噛み合っていない。

判断基準

• レビューで閾値・正規化定数を見たら、計画の背景文（何を解こうとしたか）と定数を突き合わせ、定数の受容域をドメインの不等式へ落として「動機が要求する典型入力が本当に受容されるか」を確かめる。
• 受容域が境界一点しか含まない、条件が常に成り立つ／常に成り立たない、といった退化がないか見る。退化していれば、その定数は動機ではなく別の条件を効かせている。

落とし穴・検証

定数を使ったテストが通ること自体は動機達成の証明にならない。テストが受容域の境界一点だけを踏んでいるのに、一般ケースを検証したように読めることがある。実機評価の前に、受容域の端（動機が要求する典型入力）を数式で確認し、必要なら定数を動機に合う値へ直すか、計画側の記述を実態に合わせる。