外观
Trusted Commit 信任的到底是什么？
项目版本说明
这些问答整合历史设计与实现资料；当前 main 分支 README 以工作包描述建设状态。具体能力、实验数据与设计目标的边界见项目状态与证据。
标准回答
Trusted Commit 是我在 EachOf 中定义的权威提交入口。它要解决的问题是：模型或异步处理器给出的结果，不能直接成为系统认定的有效知识。
流程上，Processor 负责生成候选，Core 负责检查候选是否属于有权限的作用域、引用的来源是否仍然有效、版本是否匹配，以及是否符合写入策略。只有通过这些检查，候选才能进入权威状态。这里的 Trusted 指的是提交过程受程序约束，并不是模型内容在语义上绝对正确。
举个例子，Worker 根据来源 v1 生成建议，生成期间用户把来源改成 v2。候选即使格式正确、模型也执行成功，仍可能引用过期依据。如果只检查 JSON 或任务是否成功，这条旧建议就会重新进入当前记忆；收口到 Core 后，系统才能在最终提交处检查依据是否仍有效。
这套设计也便于解释失败：一个候选被拒绝，应该能区分是权限、来源状态、版本还是策略问题。它把“模型生成失败”和“生成成功但不允许提交”分开，后续重试或重新处理才有明确依据。
关键机制
- 校验对象包括身份与作用域、来源状态及版本、候选结构和策略；不能只验证 JSON 格式。
- 检查与写入之间存在时间差，必须考虑并发纠错或撤销；事务、版本条件等是可选防护，要以实际实现为准。
- 提交结果需要关联任务与候选，支持追踪重试和重复写入，拒绝原因应能被解释。
通俗例子
候选根据来源 v1 生成，处理期间来源升级为 v2。Core 应识别旧依据，拒绝、隔离或要求重新处理，而非直接接收迟到结果。
追问与回答
为什么不能让 Worker 自己校验？
Worker 可以做预校验，减少无效计算，但最终入口还必须独立检查。一方面，它看到的来源和权限可能已经过期；另一方面，不同 Processor 的实现可能不一致。如果权威入口只相信 Worker 的“我检查过了”，系统的正确性就依赖每个调用方都永远实现正确。集中提交校验能把这组约束放在同一个边界维护。
校验通过后马上被撤销怎么办？
这是典型的检查与使用之间的竞态。我的要求是，最终提交不能只依赖之前读到的状态。实现上可以用事务内的版本条件或适当锁机制，让“版本仍有效”成为提交条件；不满足就拒绝或重新处理。但这些方案各有并发和性能代价，不能只说用了数据库事务就自然安全，必须核对实际隔离级别、检查对象和写入条件。
易混淆点
Trusted Commit 是项目术语，不是通用协议或行业认证；不要把校验通过说成“模型输出一定正确”。
参考资料
内容来源
- Android 技术札记 · 原条目
eachof-trusted