Havenlon｜AI 时代的执行安全语言体系（四七）：证据与执行事实

Working Draft · AI Era Execution Security LanguageThis article is part of the Havenlon Execution Security Language project. The terminology and definitions presented here describe the current working draft and may evolve as the discipline matures.AI 时代执行安全语言体系工作草案本系列旨在建立 AI 时代执行安全的共同语言。 本文中的术语与定义代表当前工作草案 将随着理论研究、工程实践和社区讨论持续修订执行链解决的是一个 Intent 如何经过提议、审批、仲裁、提交和执行最终改变真实状态。但执行完成之后系统还必须回答另一组同样重要的问题动作究竟有没有发生发生到了哪一个阶段最终执行的内容是什么哪个设备形成了提交哪个 Executor 实施了动作外部系统返回了什么执行结果是否符合原始 Intent失败是否产生了部分真实影响谁能够证明这些事实谁可以修改、删除或重新解释这些记录。很多系统虽然拥有大量日志却没有真正可靠的执行事实。应用可以记录status successSaaS 可以显示Committed数据库可以保存executed true但这些状态通常只能证明某个软件组件在某一时刻写入了这条记录。它们不能天然证明本地设备确实形成了 CommitSecurity Domain 确实使用了指定密钥Executor 确实提交了原 Payload外部系统确实接受或完成了动作最终结果与原始 Intent 一致管理员没有事后修改记录中间失败、拒绝或重试没有被删除。因此Havenlon 不把日志等同于证据也不把 SaaS 数据库等同于事实来源。它要求执行事实必须由真正参与相应阶段的主体产生并通过签名、哈希、计数器、前序关系和多方见证形成可独立验证的证据链。执行者可以证明自己执行了什么。设备可以证明自己提交或拒绝了什么。外部系统可以证明自己接收或返回了什么。SaaS 可以证明自己保存和展示了什么。但任何一个主体都不能单独替代整条执行事实链。1. Evidence证据一句话定义证据是能够被独立验证用于支持某个执行、治理、拒绝、失败或恢复事实的记录。严格定义证据不仅是一段文字或数据库字段。一条有效证据至少应明确证明什么事件对应哪个 Intent由谁产生产生于哪个设备或信任域发生在哪个执行阶段使用了什么 Policy 和治理状态前一条证据是什么当前结果是什么是否存在计数器是否有可验证签名是否可以关联到后续证据。证据必须同时具备来源可验证内容可验证对象可关联顺序可验证修改可发现缺失可发现。上位概念执行证明可验证记录事实支持下位概念执行证据提议证据审批证据仲裁证据提交证据拒绝证据失败证据恢复证据相关概念Execution FactEvidence ChainDevice-Signed FactEvidence StorePost-Execution Proof容易混淆的概念证据不等于普通日志UI 状态SaaS 数据库记录管理员说明单独一条 Receipt单独一个交易哈希。这些信息可以成为证据组成部分但必须完成来源、对象和链路绑定。权力边界一个主体只能对自己实际观察、判断或执行的事实提供证据不能替其他信任域声明其无法直接证明的事实。约束机制数字签名IntentHashCommit IDResult Hash前序哈希单调计数器域分离多副本归档。结果目标让关键执行历史不依赖某个应用、数据库或管理员的单方面叙述。在 Havenlon 中Proposal、Approval、Arbitration、Device-Signed Commit、Executor Result 和 Receipt 分别形成证据并最终进入 Evidence Store。2. Execution Evidence执行证据一句话定义执行证据是用于证明某个 Intent 从提议到最终结果经历了哪些执行阶段的证据集合。严格定义完整的 Execution Evidence 应能够回答Intent 是什么谁发起了 Intent哪些主体参与了审批使用了哪个治理状态使用了哪个 PolicyArbiter 作出了什么判断最终载荷是什么哪个设备形成 Commit使用了哪个 Key Slot使用了哪个 Execution Slot哪个 Executor 实施动作外部系统返回什么最终结果是什么是否发生失败、中断、重试或恢复。执行证据不是单一结果记录而是一组互相关联的阶段证据。上位概念EvidencePost-Execution Proof下位概念Proposal EvidenceApproval EvidenceArbitration EvidenceCommit EvidenceExecution Result EvidenceReceipt Evidence相关概念Execution ChainEvidence ChainDevice-Signed CommitResult HashReceipt Binding权力边界任何单一系统都不能通过补写一条最终结果记录替代中间缺失的完整执行证据。约束机制IntentHashStep HashCommit IDResult HashDevice SignatureReceipt Binding证据链多源验证。结果目标使审计者能够从证据中重建一次执行的实际过程而不是只能看到最终状态。在 Havenlon 中Execution Evidence 从 Intent 创建开始到外部结果确认结束贯穿整个执行生命周期。3. Execution Fact执行事实一句话定义执行事实是关于一次动作是否提交、是否执行以及产生什么结果的可验证状态陈述。严格定义执行事实必须分层定义。一次动作可能存在以下不同事实Intent 已产生 Proposal 已提交 Approval 已形成 Arbitration 已通过 Commit 已形成 Executor 已调用 外部系统已接收 外部系统已完成 最终业务目标已实现这些事实不能互相替代。例如Commit 已形成不代表 Executor 已成功调用Executor 返回成功不代表外部业务状态已最终完成交易已广播不代表链上已经最终确认API 返回 200不代表执行语义与 Intent 完全一致。上位概念可验证事实执行状态下位概念Intent FactApproval FactArbitration FactCommit FactInvocation FactReceipt FactFinal Result Fact相关概念Device-Signed FactSource of TruthReceiptFinalityPost-Execution Proof权力边界每个事实来源只能证明其负责阶段内发生的事实不能把局部事实扩张为整个业务已经完成。约束机制事实类型阶段标识来源身份对象绑定时间计数器数字签名。结果目标消除“已提交”“已调用”“已接收”和“已完成”之间的状态混淆。在 Havenlon 中Device-Signed Commit、Executor Invocation、外部 Receipt 和最终 Result 分别被建模为不同执行事实。4. Device-Signed Fact设备签名事实一句话定义设备签名事实是本地设备对其实际参与的判断、提交、拒绝、执行或恢复事件签名形成的可验证事实。严格定义设备签名事实通常应包含device_idevent_typeIntentHashCommit IDStep HashPolicy HashGovernance Hashcounterprevious evidence hashresult hashdevice statedevice signature。它可以证明某个具体设备在某个具体状态下对某个具体 Intent 作出了某项具体陈述或动作。它不能自动证明设备没有漏洞Intent 一定正确外部系统已经完成动作整个业务结果已经成功设备内部所有状态绝对真实。上位概念Execution FactEvidence本地事实下位概念设备仲裁事实设备提交事实设备拒绝事实设备执行事实设备恢复事实相关概念Device-Signed CommitDevice IdentityEvidence StoreCounterTrust Root权力边界设备只能签署自己能够直接验证的事实不能替用户、SaaS 或外部网络声明它们的真实状态。约束机制设备身份密钥安全元件域分离单调计数器固定事件类型结果绑定本地持久化。结果目标建立一个不由应用或 SaaS 单方面控制的执行事实来源。在 Havenlon 中本地设备对 Commit、拒绝、异常和恢复状态进行签名Bletchley 只能接收、验证和归档。5. Fact Source事实来源一句话定义事实来源是实际产生、观察或证明某一类执行或治理事实的主体、设备或系统。严格定义不同事实应当由不同来源证明。例如Intent 来源 → 发起主体或发起设备 ​ Approval 来源 → 审批者及其凭证 ​ Arbitration 来源 → Arbiter ​ Commit 来源 → 本地设备 ​ Execution Invocation 来源 → Executor ​ 外部结果来源 → 外部网络或业务系统 ​ 证据保存来源 → Evidence Store 或 Evidence Witness事实来源必须与事实类型匹配。SaaS 可以证明它接收了某条消息它保存了某项审批它归档了某条设备证据。但它不能仅凭数据库记录证明本地设备真实形成了 Commit安全元件真实使用了密钥Executor 实际向外部系统提交了动作外部业务结果已经最终完成。上位概念证据来源信任来源下位概念Intent 事实来源Approval 事实来源Commit 事实来源Execution 事实来源Receipt 事实来源Archive 事实来源相关概念Source of TruthDevice-Signed FactEvidence WitnessTrust DomainFact Authority权力边界拥有某种事实的读取或展示能力不代表拥有创造和修改该事实的权力。约束机制事实类型绑定来源身份来源签名作用域独立验证来源冲突处理。结果目标阻止一个系统同时成为所有事实的生产者、保存者和解释者。在 Havenlon 中不同执行阶段由对应主体产生事实Bletchley 不作为全部事实的统一信任根。6. Source of Truth事实基准来源一句话定义事实基准来源是当多个系统对同一类事实记录不一致时具有优先证明资格的来源。严格定义Havenlon 不采用一个覆盖所有领域的单一 Source of Truth。不同事实拥有不同基准来源Intent 是否由某主体发起 → 发起设备签名 ​ 某成员是否表达 Approval → 审批凭证与治理证据 ​ Arbiter 是否允许进入确认阶段 → Arbiter 签名结果 ​ 本地设备是否形成 Commit → Device-Signed Commit ​ Executor 是否调用外部系统 → Executor Result ​ 外部系统是否接收或完成 → External Receipt ​ 证据是否连续保存 → Evidence Store 与 Evidence Witness事实基准来源不代表绝对可信。它表示对这一种特定事实这个来源具有最直接、最合适的证明资格。上位概念Fact Source事实权威下位概念Intent 基准来源Governance 基准来源Commit 基准来源Result 基准来源Evidence 基准来源相关概念Local AuthorityDevice-Signed FactSaaS Coordination PlaneEvidence WitnessEvidence Conflict容易混淆的概念Source of Truth 不应被理解为一个万能数据库一个超级管理员一个 SaaS 后台一个不可失败的终极组件。约束机制事实分类来源映射来源资格签名验证冲突保留不允许静默覆盖。结果目标让不同系统发生冲突时能够依据事实类型判断谁有资格证明什么。在 Havenlon 中对于本地提交事实Device-Signed Commit 优先于 SaaS 中的committedtrue状态。