用途与实际影响
这项功能怎样使用
为什么需要它
一次结果写着某个模型名，仍可能由另一配置或旧任务产生。必须让执行者、任务和真实文件互相对得上。
举个实际例子
一个云端任务把文件做完了，实际执行来源却和我指定的不一样。页面会保留文件供排查，同时明确写“身份不合格、不能参加比较”；内容看着正确，也不能借另一条路线的证明蒙混过关。
最后我会得到什么
对一份已有尝试，可以核对实际执行者、执行路线、留下的文件和是否真正结束；对不上时留下排查材料，并明确不能拿它参加正式比较。
正常时
实际模型、执行路线、这次任务和文件都能互相对应，且能确认执行和清理结束时，才把这份结果送去比较。
发现问题时
声明的模型、服务、任务或清理结果对不上时，写明矛盾发生在哪一层并保留文件供排查；不借另一条路线的记录补证。
入口不可用或证据不足时
宿主或云端服务不给必要的执行、结束证明时，标明证据不足；参与者自述和旧配置不能代替本次结果。
从哪里开始
在 CACB 项目的 AI 对话中问：这一次工程题的结果真由哪条路线和哪个实际配置产生？
需要准备什么
- 要核对的某次尝试或产物
从开始到拿到结果
- 1
读取这次尝试的真实记录
从宿主任务与隔离工作区核对原生、本机或云端路线及实际模型身份，不采信执行者自报。
- 2
对照实际执行与结束证据
核对启动者、真实模型、任务、工作区、留下的文件和终态；云端任务还要知道服务端是否确实结束。
- 3
决定能否用于比较
全部对上才把这次结果交给客观检查；有矛盾就保留诊断材料并说明哪个环节不可信。
技术实现与依据
这里保留实现、关键条件、精确入口、历史记录和验证结果。
三类 executor identity/schema（数据结构） 与共同接入原则已有源码；部分历史 native envelope 在完整回归中未闭合关键规则与设计选择
宿主回执优先于自报身份。
native_managed 只在宿主能证明原生 parent/spawn/child lineage 时成立。
local_async_job 明确是 Toolkit/AICLI + Codex CLI（命令行工具） 本地任务，不是原生 child；它绑定精确 artifact、quantization、tokenizer（分词器）/template、engine、profile 与 broker（代理服务） lease。
cloud_api_async_job 明确是指定 provider 的 Responses 任务，不是原生 child；它绑定 provider/profile/model/endpoint、request/stream 和 machine events。
本地与云端路线的 native_lineage=not_applicable 是正确语义，不增加也不减少能力。
任务输入与 workspace 同时绑定。
动作范围逐条检查，未执行的外层 envelope 不算动作。
新增 harness 先证明等价能力路径和同一 verifier 兼容，不用专用验收捷径。
证据只能用于精确执行和版本。
本模块用到的名词
- attestation（证明）
- 由宿主或受信适配器提供的执行事实，不是参与者自述。
- executor_kind（执行器类型）
- 决定任务由宿主原生、本机异步 job（任务记录） 还是云端 API job（任务记录） 承载，也是身份、传输与清理合同的分支。
- requested / effective / attested identity（请求/实际/证明身份）
- 分别记录想调用谁、实际运行谁、宿主或 provider 能证明谁；三者矛盾就失败关闭。
- native lineage（原生谱系）
- 宿主提供的 parent/spawn/child 与 rollout 关系；只对 native_managed 必需，非原生路线明确写 not_applicable。
- onboarding gate（接入门）
- 新 harness 在正式使用前证明身份、能力等价路径、workspace/artifact/terminal receipt（执行回执） 与同一 verifier 兼容的预演。
- envelope（动作信封）
- 宿主记录的一次工具调用及参数外壳。
- binding hash（绑定指纹）
- 把身份、任务、workspace 和版本组合成不可混用的内容指纹。
专业定义
把谁执行、为何选择这条路线、host/provider/transport 是什么、是否需要 native lineage，以及任务、workspace、动作和终态怎样归属，绑定为不可跨执行借用的证据。
解决什么
解决身份自报、原生谱系冒领、provider/profile/transport 漂移、跨执行借证、任务输入漂移、动作范围不明和终态假完成。
当前怎样实现
- evidence.py 与 model_evidence.py 管证据结构与状态。
- model-evidence-card schema（数据结构） 把 executor_kind 固定为 native_managed、local_async_job 或 cloud_api_async_job，并分别约束 lineage applicability。
- config/arms/v11.registry.json 把每个执行配置的 model、effort（思考等级）、harness、provider、transport 与 fallback（后备路线）=false 绑定在一起；单工作者与根编排分别定义，不把多模型合作算成某个模型的独立能力。
- 配置准入、本机接入、正式样本和可采用结论是不同阶段。当前方法/评分冲突未解决，任何启动配置都不能单独形成比较结论；公开页不列受测名单或逐配置状态。
- 首报代表按冻结的 first-valid 或中位代表规则选择，额外尝试只作审查证据；禁止事后挑高、拼接不完整尝试或把其他框架的补充结果混入原比较范围。
- native_managed 选择于要测真实宿主原生 Codex 行为且宿主能提供权威 rollout 时；host receipt（执行回执） 绑定 model、effort（思考等级）、agent_type、provider、harness、parent/spawn/child 与 turn context，用户得到原生 task handle、artifact 和终态/清理回执。
- local_async_job 选择于要测精确本机模型制品及其 Codex 工具循环时；Toolkit job（任务记录） id 与 AICLI machine events 绑定 backend（模型后端）/profile/model、artifact digest、quantization、tokenizer（分词器）/chat template、serving engine、loopback transport、sandbox、LocalGpuBroker（本地 GPU 调度器） lease 和 fallback（后备路线）=false，用户得到本地 artifact、verifier 摘要与完整清理 receipt（执行回执）。
- cloud_api_async_job 选择于非原生模型必须在指定 provider API 下接受同一 Codex harness 时；Toolkit/AICLI job（任务记录） 与 receipt（执行回执） id 绑定 provider/profile/model/revision、endpoint class/path fingerprint、Responses transport、request/stream id、machine events、privacy policy 和 fallback（后备路线）=false，用户得到本地 artifact、sanitized report（净化报告）与请求/终态证据。
- harness onboarding 先冻结 identity + capability/equivalent-path map，再读取 host-owned preflight receipt（执行回执）、根侧重算 workspace/log/trace/artifact hash（内容指纹），并证明同一 frozen verifier 能验收；通过才允许正式样本。
- manifest（清单） / receipt（执行回执） schema（数据结构） 约束 identity、workspace 与 terminal；云端 paid-attempt authorization（用户授权） hash（内容指纹） 只绑定当前一次真实付费尝试，旧授权、provider 配置或 synthetic test 都不可复用。
- canonical action parser 把受支持动作还原为可审计语义。
- binding hash（内容指纹） 防止别名或不同执行路线复用旧证据。
执行流程
- 1
先说明要测的现实对象：宿主原生任务、精确本机模型制品，或指定云端 provider 的 Codex harness。
- 2
冻结 executor_kind、requested identity、harness、transport、no-fallback 和比较基线。
- 3
新 harness 运行代表性 dry-run，读取 host receipt（执行回执） 并确认同一 verifier 能消费 artifact；未通过只保留候选状态。
- 4
记录宿主或受信适配器的 effective 与 attested identity。
- 5
原生路线核对 parent/spawn/child rollout；本地路线核对 job（任务记录）/profile/artifact/engine/lease；云端路线核对 provider/endpoint/request/stream。
- 6
绑定任务 capsule 和 workspace。
- 7
采集动作与终态。
- 8
规范化可审计动作。
- 9
核对 artifact 与 manifest（清单）。
- 10
核对路线专属 cleanup 与 authorization（用户授权） 证据。
- 11
生成单次证据 commitment。
边界
- 网页不展示原始宿主日志或任务密文。
- 缺 native lineage 对非原生执行不自动算失败；反过来，非原生 receipt（执行回执） 绝不能证明 native_managed。
- 云端请求只允许 participant-public 与必要 harness protocol；hidden control、oracle、raw rollout、私有证据、secret 和无关私有来源不得发送给 provider。
- 云端真实付费 attempt 必须逐次明确授权；本地 GPU 与原生 task 不消费这个 paid-attempt gate，但仍服从各自 owner、资源和执行授权。
- 宿主版本字面量不是永久 allowlist；真正绑定的是当前发现的身份、协议、能力与 receipt（执行回执）。
- 底层模型、provider、理解、推理和代码能力属于外部 AI/平台；CACB 自己只实现接入、评测、证据与验证框架。
失败与恢复
- 身份或任务不匹配
- 标记 infra invalid（执行证据无效）。
- native_managed 缺 parent/spawn/child 谱系
- 原生身份门失败，不得改写为普通成功或借用另一次 rollout。
- 本地 artifact/profile/engine 与 runtime（运行环境） receipt（执行回执） 不一致
- 停止资格判断，保留 workspace 供诊断；不得换成本地别名、原生或云端 fallback（后备路线）。
- 云端 requested/effective/attested provider、model 或 endpoint 不一致
- 关闭本次身份资格并保留 request audit；不得继承 native receipt（执行回执）。
- 新 harness 只有静态 profile、没有 host preflight receipt（执行回执）
- 保持 draft/research 状态，不进入正式样本。
- 云端没有当前 attempt 的付费授权
- 不发 provider request；已配置账号、旧授权或设计验证都不能补足。
- 动作无法规范化
- 只关闭受影响的执行证据，不猜行为。
- 终态缺失
- 保持 incomplete，尝试同 session 恢复。
真实入口
PRIVATE source · src/cacb/evidence.py证据状态与 commitment
PRIVATE source · src/cacb/model_evidence.py执行身份和证据卡
PRIVATE source · docs/WORKER_CONTRACT.md三类 executor union、identity、lineage 与 compatibility gate
PRIVATE source · docs/HARNESS_ONBOARDING.md新 harness 的 profile、host preflight 与同一 verifier 接入门
PRIVATE source · docs/LOCAL_CODEX_COMPATIBILITY.md本地 artifact、Codex tool loop 与 GPU 身份门
PRIVATE source · src/cacb/cloud_api_worker.py云端 provider/request/usage/privacy/terminal 的严格证据解析
PRIVATE source · schemas/model-evidence-card.schema.json三类 executor 与 lineage applicability 合同
PRIVATE source · schemas/episode-manifest.schema.jsonEpisode manifest（清单） 合同
PRIVATE source · schemas/worker-receipt.schema.json执行回执合同
PRIVATE source · config/arms/v11.registry.json24 canonical slots、C1–C10、精确模型/effort/harness/provider 与 launch state
PRIVATE source · config/formal-sampling.v1.json第一份有效样本与固定中位代表的首报采样规则
如何验证
- model evidence workflow 与 worker contract focused tests 在 e6f7581 历史观察代曾通过；该证据不继承到当前 59b0b5c。
- current（当前状态） cross-executor design contract 与 schemas 在源码层显式区分 native_managed、local_async_job、cloud_api_async_job，并要求 requested/effective/attested identity；这不证明任何具体配置已完成本机接入。
- v11.registry.json 当前 nominal_slot_count=24、episode.case_count=10；这里只公开配置绑定方法、十案例合同与验证边界，不展示受测身份矩阵或候选结果。
- 完整 native identity envelope 测试当前存在跨代失败，页面没有升级为全绿。
- 未读取或复制任何真实原始执行日志。
与其他模块的关系
先为 campaign/workspace 选择并冻结精确 executor binding，再把路线专属 host/provider/transport/lineage/authorization 证据交给执行生命周期；deterministic verifier 只接受同一 task/run/workspace 的匹配 artifact 并拥有样本资格。对已合格样本，identity 模块还要为 blind-quality-review 提供 fresh exact Sol Max 的实际 turn context、唯一 task/session 与 host receipt（执行回执）；这些 judge 身份证据不能反向证明参与者身份。失败报告再按 identity、transport、harness、cleanup、judge-contract 或 model-task 平面归因。