I had three packs open in Newton's policy editor, vaults.fyi, RedStone, Chainalysis, checking whether a vault action should be allowed to execute.
Vaults.fyi returned a risk_score of 0.72. RedStone returned a divergence_bps of 38. Chainalysis returned its own risk_score, "low", plus a sanctioned flag set to false.
Two of those three responses use the exact same field name, risk_score, for two completely different things. One is a numeric vault health rating. The other is a categorical sanctions label. Nothing in either provider's JSON warns you in advance, because neither team built their schema knowing the other one existed.
If a naive merge just wrote both responses into one object, the second write wins. Vaults.fyi's 0.72 gets silently replaced by "low". The policy keeps running. No error, no warning, no red text anywhere. It starts comparing a threshold against a value that no longer exists.
I went looking for where Newton actually stops this, because it clearly isn't left to whoever writes the Rego file to notice.
Every pack namespaces its output under its own pack id before anything merges. Vaults.fyi's risk score lives at data.wasm.vaultsfyi.risk_score. Chainalysis's sits at data.wasm.chainalysis.risk_score, a completely different address, even with the identical field name. RedStone's divergence value sits at data.wasm.redstone.divergence_bps. Running Simulate against all three at once, the merged data panel showed exactly that, three separate paths, none touching each other.
That's not a rule telling developers to be careful with naming. It's the merge itself refusing to let the collision happen, before a policy author ever writes a single comparison.
What stayed with me wasn't the bug I didn't hit. It was how unglamorous the fix actually is. Nobody markets namespaced JSON keys. But it's the exact detail standing between a vault policy that correctly blocks a risky action, and one quietly approving it because two unrelated providers happened to agree on a word.