01
问题
系统可能因为原始症状消失而看似已修复，但因果机制仍然存在。当上下文、负载、工具顺序、数据质量或操作行为变化时，回归就会重新出现。
ICISELFLAB / RELIABILITY
围绕故障机制构建可靠性测试
ICI Reliability 检验修正能否在条件变化后继续有效，而不是把一次成功的重新运行当作故障机制已经消失的证明。
02
ICI 如何处理
ICI 保存故障机制、支持和反对证据、修正动作以及获得结果时的条件，然后生成有针对性的反测试，系统改变因果因素，寻找隐藏复发、交互控制和缓解失效边界。
03
运行示例
某个工作流在调整一个参数后不再失败。Reliability 恢复原负载，并单独改变遥测质量或依赖控制。如果故障再次出现，修正会被识别为依赖具体上下文，而不是持久修复。
04
证据纪律
结果区分已验证缓解、回归、隐藏复发、未解决交互和证据不足。置信度跟随测试证据，而不是跟随结果是否“看起来整齐”。
为什么重要
当一致不等于独立证据
这篇简短页面把一个海事集成系统案例与现代AI案例联系起来。
这不是1995年的原则，而是结构性原则。
同一条信息可以经过多个显示器、人员、智能体或工作流步骤，仅仅因为重复出现就显得像被多次确认。技术进步增加速度和步骤数量，却不会消除对原始来源的因果依赖。
重复可以提高主观可信度，却不一定增加独立信息。
1995ROYAL MAJESTY
Royal Majesty：多个系统，一个脆弱的位置来源
1995年6月10日，Royal Majesty在楠塔基特附近搁浅。NTSB认定，GPS天线连接出现问题后，接收机转入推算航位模式，而集成导航系统和自动驾驶继续运行，这一模式变化没有被充分识别和处理。
NTSB指出，如果系统比较多个独立位置接收机的输入，并在出现差异时报警，这次搁浅本可以避免。
ICI: 不同显示并不一定意味着不同来源。如果上游依赖相同，下游的一致性可能只是表面的。
主要来源：NTSB Marine Accident Report MAR-97/01 ↗2023MATA v. AVIANCA
Mata v. Avianca：让同一个来源确认自己
在Mata v. Avianca案中，一名律师使用ChatGPT进行法律研究。系统生成了不存在的判例引用和司法意见。对同一系统的进一步提问又产生了更多确认，而不是独立验证。
法院记录了这些引用并不存在，并作出处罚。同一个信息来源事实上被再次用于验证自己的结果。
ICI: 如果第二个答案来自同一个认识论依赖，它就不是第二份证据。真正的验证需要独立路径。
来源：U.S. District Court, S.D.N.Y., 制裁裁定 ↗正确的问题不是“有多少智能体同意？”，而是“有多少真正独立的证据链支持这个结论？”
原则公开，实现不公开。
本页说明认识论原则与公开案例，不披露Sentinel的专有架构、评分逻辑、阈值、内部评估器或干预选择机制。
CONTACT
与 ICI 合作
研究合作、受控试点和技术评估。