此前我们把测试通过与目标行为正确分开讨论。今天的材料进一步说明：即便检查过程本身严格，接受的命题也可能比用户理解的窄。FlashProve 可以核对指定权重承诺下的计算，但实际接口还要说明检查了哪些位置、是否允许近似，以及承诺怎样对应到用户购买的模型。问题已经不只是有没有验证，而是验证结果究竟携带了多少可以继续使用的信息。[1]
这与公开评测的缺陷有相通之处，却不是同一种技术错误。AutomationBench 的部分计分可以接近满分，严格完成仍有明显差距；OfficeQA 的字符串规则可能拒绝有效答案，也可能让联网找到答案的过程得到好成绩。密码学协议关注给定命题是否成立，业务判分还要确认命题是否忠实表达任务。后者不能仅靠更严格地执行旧规则解决。[2]
由此值得改变的判断，是不再把成功状态当作可以直接传递的保证。一个下游使用者真正需要的是：在什么输入、工具、预算和接受条件下，哪项性质已被检查。例如“定位奖励提高”应继续说明文件、模块、函数三个分量和评估任务来源；“历史重建一致”应说明是完整序列匹配，且只使用当时到达的数据。把这些条件留下，别人才知道结果能否用于自己的决定。[3][4]
也不能把条件写得越多就当作越可靠。说明书可以很完整，检查却未必能区分我们关心的错误。一个可借用的做法，是围绕实际承诺找一对相近案例：答案含义相同但格式不同，工具返回一致但标识指向错误对象，事件时间相同但到达时间不同。再看判定是否随真正相关的变化而变化。这样既能发现错误通过，也能发现合理行为被拒绝；本期只是提出这条检验路线，没有报告我们已经运行过这些案例。
这条思路也解释了为什么不能给所有任务套一层统一审核。低风险原型可能只需一项明确测试；服务模型身份、科研比较与历史数据重放则分别需要不同证据。应先说清下一位使用者会据此做什么决定，再选择足以支撑该决定的检查。更强的模型和更严格的证明都很有价值，它们最有用的时候，是替一个具体承诺补上原来无法检查的部分，而不是把所有含义不同的成功压成一个绿灯。
另一种解释
涨分也可能来自更宽的接受范围、不同工具入口或新的任务选择；应先核对这些变化，再判断能力贡献。
接下来观察什么
后续查同一任务下接受策略的敏感性、正常案例误拒与完整链路成本；追独立验证器和修订评测的可复跑记录。