确定性验证器与证据回执

让验证落到能检查的边界

确定性验证器把一个具体断言转换成可执行检查，例如JSON schema、金额复算、权限判定、数据库终态、文件diff和签名回执。它的价值是清楚、便宜且可定位错误，但只能证明被检查条件。文件存在不能证明内容正确，URL可访问不能证明支持某个法律命题，接口接受请求不能证明用户收到结果。

先声明验证对象和证据

每份验证报告绑定task合同版本、产物内容hash、数据与as_of快照、grader版本以及执行身份。验证后若产物或依赖变化，应重新验证，不能沿用旧passed。对写操作查询权威业务系统，对生成内容检查结构、来源和数值；必要时组合语义judge与专业复核，明确各自边界。

四种结果比二元开关更诚实

pass表示检查范围内满足条件；fail表示发现违反；inconclusive表示证据或接口不足；error表示验证器自身未成功运行。后两者不能自动通过，可在预算内重试、降级或进入人工队列。任务仍可交付已验证部分，但界面和API应说明剩余缺口，不把运行退出当完整业务成功。

验证器也需要被验证

用已知正确、已知错误、边界和篡改样本测试grader，保护其代码与隐藏oracle不被被测Agent修改。计算检查需覆盖单位和期间而非只比较一个浮点值；状态检查需处理最终一致、重复动作与结果未知。回执保留允许、尝试、执行和确认各阶段，缺少确认也应被记录。运行时验证可驱动修复，离线评测可统计表现，两者共用合同而不混淆作用。

验证器本身也要有测试

准备正确产物、已知错误产物、依赖不可用和证据不足四类样本，检查验证器是否把执行异常误报为通过。算术验证同时检查单位和输入来源；文件验证要打开并解析内容，业务验证要读取权威状态。回执注明规则版本、产物摘要、运行时间、检查范围和证据位置。验证代码由受信侧执行，候选Agent不能改动规则或测试答案；否则通过分数可能只是验证环境被改变。