我們不會改這些字段。
而且這句話有一把鎖。

同一個問題，問兩次答案一樣

同一時刻、同一份名單下，同一個地址查兩次，判決、原因碼和證據鏈接完全一致。判決來自名單和確定性規則，不來自模型打分，所以不會因為「再問一次」而改變。

答案只會因為三件事而變化：名單本身更新了、鏈上情況變了（交易數、地址年齡、關聯的風險地址），或者判定規則調整了。每條返回都帶 evaluated_at（這次判定算出來的時刻）和 evidence_as_of（各份名單覆蓋到哪天）—— 事後復盤時，憑這兩個字段就能說清「當時為什麼這麼判」。

可以放心寫進代碼的

這四個是語言無關、結構穩定的。新值可能隨時增加 —— 遇到沒見過的值請當作「沒處理」，不要當作錯誤。

千萬不要寫進代碼的

要改的話，我們必須怎麼做

1. 新標識符先與舊的並存，兩個一起返回。
2. 舊的在 /api/contract 裡標 deprecated，並寫明移除日期，至少 90 天之後。
3. 到期才移除。

在第 2 步走完之前，門禁不會放行刪除 —— 這不是流程規定，是構建腳本里的一行判斷。

當前已登記的 signal_keys

按前綴分組。前綴本身也是穩定的：list.* 是名單命中，taint.* 是資金沾染，age.* 是地址年齡/活躍度，src.* 是數據源降級，scope.* 是覆蓋邊界，endpoint.* 是端點層。

當前已登記的 reason_codes