我们不会改这些字段。
而且这句话有一把锁。

同一个问题，问两次答案一样

同一时刻、同一份名单下，同一个地址查两次，判决、原因码和证据链接完全一致。判决来自名单和确定性规则，不来自模型打分，所以不会因为「再问一次」而改变。

答案只会因为三件事而变化：名单本身更新了、链上情况变了（交易数、地址年龄、关联的风险地址），或者判定规则调整了。每条返回都带 evaluated_at（这次判定算出来的时刻）和 evidence_as_of（各份名单覆盖到哪天）—— 事后复盘时，凭这两个字段就能说清「当时为什么这么判」。

可以放心写进代码的

这四个是语言无关、结构稳定的。新值可能随时增加 —— 遇到没见过的值请当作「没处理」，不要当作错误。

千万不要写进代码的

要改的话，我们必须怎么做

1. 新标识符先与旧的并存，两个一起返回。
2. 旧的在 /api/contract 里标 deprecated，并写明移除日期，至少 90 天之后。
3. 到期才移除。

在第 2 步走完之前，门禁不会放行删除 —— 这不是流程规定，是构建脚本里的一行判断。

当前已登记的 signal_keys

按前缀分组。前缀本身也是稳定的：list.* 是名单命中，taint.* 是资金沾染，age.* 是地址年龄/活跃度，src.* 是数据源降级，scope.* 是覆盖边界，endpoint.* 是端点层。

当前已登记的 reason_codes