ニュートンのポリシーエディタで、3つのパック（vaults.fyi、RedStone、Chainalysis）を開き、あるvaultアクションを実行してよいかどうかを確認しました。
vaults.fyiはrisk_scoreを0.72として返しました。RedStoneはdivergence_bpsを38として返しました。Chainalysisは独自のrisk_scoreとして「low」を返し、さらにサンクション（制裁）フラグをfalseに設定していました。
その3つの応答のうち2つは、まったく別の内容に対して同じフィールド名のrisk_scoreを使っています。1つは数値のvaultヘルス評価です。もう1つは分類（カテゴリ）の制裁ラベルです。どちらのプロバイダのJSONにも、事前に警告はありません。なぜなら、どちらのチームも相手のスキーマが存在することを前提にして設計していなかったからです。
素朴なマージが単に両方のレスポンスを書き込んで1つのオブジェクトにしてしまうだけなら、2回目の書き込みが勝ちます。Vaults.fyiの0.72は、黙って "low" に置き換えられます。ポリシーは走り続けます。エラーも警告も、どこにも赤い文字もありません。存在しなくなった値に対して、閾値（しきい値）を比較し始めてしまうのです。
ニュートンが実際にどこでこれを止めるのかを探しに行きました。明らかに、Regoファイルを書いた人が気づくかどうかに任されているわけではありません。
すべてのパックは、何かがマージされる前に、そのパックIDの下で出力を名前空間化します。Vaults.fyiのリスクスコアは data.wasm.vaultsfyi.risk_score にあります。Chainalysisのものは data.wasm.chainalysis.risk_score、まったく別のアドレスで、フィールド名が同一でもそうです。RedStoneの乖離（divergence）値は data.wasm.redstone.divergence_bps にあります。3つすべてに対して一度にSimulateを実行すると、マージされたデータ・パネルにはまさにそれが表示されました。3つの別ルートで、どれも互いに触れていないのです。
それは、開発者に命名に注意するよう伝える“ルール”ではありません。衝突そのものが起きないように、マージ処理が拒否しているのです。ポリシー作成者が最初の比較を行うより前に。
私に残ったのは、当たり損ねたバグではありませんでした。実際の修正がいかに地味であるか、その点でした。名前空間付きのJSONキーなんて誰も売り出しません。でもそれこそが、危険な操作を正しくブロックする貸金庫（vault）ポリシーと、単に2つの無関係なプロバイダがたまたま同じ語を選んだだけで、黙ってそれを承認してしまうポリシーの間に立っている“正確なディテール”です。