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 currentworking draft and may evolve as the discipline matures.AI 时代执行安全语言体系工作草案本系列旨在建立 AI 时代执行安全的共同语言。本文中的术语与定义代表当前工作草案将随着理论研究、工程实践和社区讨论持续修订31. Recovery Evidence恢复证据一句话定义恢复证据是记录系统从故障、失陷、模糊状态或 Safe Mode 恢复到新可信状态全过程的证据。严格定义Recovery Evidence 至少应记录恢复原因恢复前最后有效 CheckpointEvidence Gap 范围参与恢复的主体物理恢复条件新设备或新凭证被撤销的旧状态新 counter 起点新 Evidence Chain 起点Governance Approval恢复时间恢复后限制。恢复不能简单地删除旧数据库 → counter 归零 → 重新开始它必须能够证明新可信状态如何从旧状态或已知损坏状态演化而来。上位概念EvidenceGovernance RecoverySystem Recovery下位概念Device Recovery EvidenceOwner Recovery EvidenceChain Recovery EvidenceStorage Recovery EvidenceCredential Recovery Evidence相关概念Physical RecoveryEvidence CheckpointSafe ModeGovernance Mutation ControlChain Continuity权力边界恢复者不能利用恢复流程删除不利历史或把未知执行描述为从未发生。约束机制最后 Checkpoint 引用新旧设备绑定多方治理物理确认恢复签名冷静期外部副本对账。结果目标在重新建立可信状态的同时保留故障和恢复过程的完整事实链。在 Havenlon 中设备替换、Owner 恢复和证据修复都必须形成 Governance Intent 与 Recovery Evidence。32. Correction Evidence纠正证据一句话定义纠正证据是通过新增记录修正历史解释或补充新事实而不覆盖原始证据的机制。严格定义Correction Evidence 可用于Receipt 后续状态更新链上最终性变化业务结果重新确认初始错误分类修正时间来源修正外部网络重组补充缺失元数据。纠正记录必须包含被纠正 Evidence Hash纠正原因新事实来源纠正主体纠正时间新 Result Hash是否影响治理或执行状态。上位概念Append-Only EvidenceEvidence Maintenance下位概念Receipt CorrectionResult CorrectionClassification CorrectionTime CorrectionMetadata Correction相关概念Amendment RecordEvidence ConflictRevocation EvidenceAuditabilityEvidence Chain权力边界纠正不能删除原证据也不能由管理员无依据地改变执行事实。约束机制原 Evidence Hash 引用新事实来源纠正签名纠正原因作用范围外部见证。结果目标允许系统更新对事实的认识但保留认识变化的全过程。在 Havenlon 中外部结果后续变化通过新增 Result Evidence 表达不直接覆盖旧 Receipt。33. Evidence Conflict证据冲突一句话定义证据冲突是两个或多个有效来源对同一执行、治理或结果事实提供不一致陈述的状态。严格定义Evidence Conflict 可能表现为SaaS 显示 Commit 成功但设备没有 Device-Signed Commit设备已经 Commit但 Executor 没有调用记录Executor 返回成功外部业务状态未改变本地 Governance State 与 SaaS 状态不同两个 Evidence Witness 保存了不同 Checkpoint本地 counter 与归档 counter 冲突。证据冲突不能简单通过采用最新数据库记录采用权限最高管理员的解释删除其中一个来源手工改成成功状态进行处理。系统必须判断冲突涉及哪类事实每个来源有资格证明什么是否存在时间延迟是否发生部分执行是否发生回滚是否需要冻结后续动作。上位概念Evidence RiskFact Conflict下位概念Commit ConflictReceipt ConflictGovernance ConflictCounter ConflictCheckpoint Conflict相关概念Source of TruthAmbiguous Execution StateEvidence WitnessSafe ModeConflict Resolution权力边界任一冲突来源都不能单方面删除其他来源证据并宣布自己为最终事实。约束机制事实类型分类来源资格判断冲突证据保留高风险冻结外部对账治理介入冲突解决留证。结果目标在事实不一致时优先保持安全、可调查性和证据完整性。在 Havenlon 中设备 Commit 与 SaaS 状态冲突时本地提交事实依据 Device-Signed Commit 判断同时保留 SaaS 冲突并进入核验状态。证据与事实关系总图Intent ↓ Proposal Evidence ↓ Approval Evidence ↓ Policy / Arbitration Evidence ↓ Confirmation Evidence ↓ Device-Signed Commit ↓ Executor Invocation Evidence ↓ External Receipt ↓ Result Hash ↓ Device-Signed Result Evidence ↓ Evidence Checkpoint每条核心 Evidence 可以绑定IntentHash Commit ID Event Type Counter Previous Evidence Hash Current Evidence Hash Policy Hash Governance Hash Result Hash Device Identity Device Signature执行链与证据链的区别Execution Chain执行链 回答 动作实际经过了哪些阶段 Evidence Chain证据链 回答 如何证明这些阶段和状态变化确实发生执行链是过程。证据链是过程的可验证证明。没有执行链系统不知道动作如何发生。没有证据链系统无法证明动作实际如何发生。日志、回执、证据与事实的区别Log日志 回答 某个组件记录了什么 Receipt回执 回答 外部系统返回了什么 Evidence证据 回答 什么可验证记录可以支持某项事实 Fact事实 回答 哪一个状态确实发生 Source of Truth事实基准来源 回答 多个记录冲突时谁有资格证明这一类事实因此日志是一个组件的陈述。证据是可以被独立验证的陈述。事实是由有效证据支持的具体状态。执行事实的分层Intent Fact 谁希望发生什么 Approval Fact 谁对哪个 Intent 表达了同意或拒绝 Arbitration Fact Arbiter 在什么状态下作出了什么判断 Commit Fact 哪个设备是否形成了正式 Commit Invocation Fact 哪个 Executor 是否真正发起了动作 Receipt Fact 外部系统返回了什么 Final Result Fact 真实业务或外部状态最终变成了什么 Evidence Fact 这些事实如何被连续保存和验证这些事实不能压缩成一个executedtrue。证据攻击的典型路径完成异常执行 ↓ 删除应用日志 ↓ 修改 SaaS 数据库 ↓ 覆盖旧 Result ↓ 伪造或错绑 Receipt ↓ 删除拒绝与失败记录 ↓ 恢复旧 counter ↓ 将异常描述成从未发生Havenlon 的反向约束路径是Device-Signed Fact ↓ Monotonic Counter ↓ Previous Evidence Hash ↓ Current Evidence Hash ↓ Append-Only Evidence ↓ Evidence Checkpoint ↓ Evidence Replication ↓ Independent Evidence Witness攻击者可能仍能破坏系统但很难在改变事实的同时保持证据链完全正常。证据异常的安全响应情况一Evidence Store 接近容量上限Evidence Backpressure ↓ 降低执行频率 ↓ 限制自动化 ↓ 停止高风险执行 ↓ 进入 Evidence-Safe Mode情况二counter 回退或 prev_hash 不匹配Evidence Continuity Failure ↓ 冻结不可逆执行 ↓ 核验最近 Checkpoint ↓ 比较外部 Evidence Witness ↓ 进入物理与治理恢复 ↓ 生成 Recovery Evidence情况三Commit 已形成但 Receipt 缺失Ambiguous Execution State ↓ 禁止自动重试 ↓ 查询外部状态 ↓ 进行 Commit / Result 对账 ↓ 形成 Success、Failure 或 Correction Evidence执行控制层与执行证明层Execution Control Layer执行控制层 负责 ├── Intent ├── Authorization ├── Approval ├── Policy ├── Governance ├── Arbitration ├── Final Revalidation └── Independent Final Veto Execution Proof Layer执行证明层 负责 ├── Device-Signed Commit ├── Execution Result ├── Receipt Binding ├── Result Hash ├── Evidence Chain ├── Evidence Store ├── Evidence Checkpoint └── Evidence Witness完整系统需要Pre-Execution Control Post-Execution Proof只有执行控制没有执行证明系统可能阻止了一些风险但在失陷之后无法可靠解释事实。只有执行证明没有执行控制系统只能准确记录灾难如何发生。证据链与执行事实评审问题评估一套执行证明系统时至少应回答哪些执行阶段必须形成 EvidenceProposal 是否有独立证据Approval 是否绑定具体 IntentArbitration 是否产生签名结果谁是 Commit Fact 的事实来源SaaS 能否单方面声称 Commit 已完成Executor Invocation 是否有独立记录Receipt 是否绑定具体 Commit 和 Payload最终业务结果由谁证明是否区分 Commit、Invocation、Receipt 和 Final Result每条证据是否绑定 IntentHash是否存在 Commit ID是否存在 Result Hash每条证据是否有 event type是否存在 Previous Evidence Hash是否存在 Current Evidence Hashcounter 是否单调递增counter 是否可能被数据库回滚设备重启后 Evidence Chain 如何继续设备更换后旧证据如何保留历史证据能否被管理员直接 UPDATE错误证据如何纠正删除证据是否会产生可见链缺口是否存在 Evidence CheckpointCheckpoint 由谁签名是否存在独立 Evidence Witness证据是否存在多个不同管理域副本SaaS 删除记录后本地设备证据是否仍存在本地设备损坏后外部副本是否能够验证Evidence Store 容量不足时系统如何处理系统会不会为了可用性停止关键留证Evidence Backpressure 是否触发限频或 Safe ModeCommit 已完成但 Receipt 缺失时是否允许重试模糊执行状态是否自动被解释成“未执行”Executor 返回成功但外部状态不一致时怎么办多个 Fact Source 冲突时如何判断不同事实是否拥有不同 Source of TruthDevice-Signed Fact 能证明什么不能证明什么日志是否被误认为不可否认事实Receipt 是否被误认为完整执行证明成功是否区分不同执行阶段失败是否说明可能产生部分真实影响拒绝和中断是否同样形成证据Recovery 是否形成 Recovery EvidenceRecovery 是否会清除原 Evidence ChainGovernance Change 是否进入 Evidence ChainPolicy Change 是否保留旧版本事实SaaS 是否可以隐藏设备拒绝记录攻击者是否能够执行动作并删除全部相关证据当系统无法证明事实连续时是否继续允许不可逆执行如果这些问题没有明确答案系统可能拥有大量日志却没有真正能够支撑治理、恢复和追责的执行证据。本章核心公理执行发生了什么不能只由执行者自己解释。日志是组件的陈述证据是可以被独立验证的陈述。SaaS 可以展示和归档事实但不能因为掌握数据库就拥有创造执行事实的权力。设备签名事实证明设备作出了某项具体陈述不证明整个外部世界已经与该陈述一致。不同执行阶段必须由不同有资格的事实来源证明。Commit Fact、Invocation Fact、Receipt Fact 和 Final Result Fact 不是同一件事。Receipt 是外部系统的回答不是整条执行链的证明。证据完整性不仅要求记录没有被修改还要求关键记录没有被删除。只追加不等于绝对不可删除必须与哈希链、签名、多副本和独立见证共同使用。Counter 证明顺序Previous Evidence Hash 证明前序Current Evidence Hash 证明当前内容Device Signature 证明来源。Result Hash 绑定结果但不能替代对业务语义和最终性的判断。无法确定动作是否执行时不能把“不确定”自动解释为“未执行”。证据缝隙会使系统失去安全重试、可靠审计和正确恢复的基础。证据系统发生背压时安全响应应当限制执行而不是停止留证。恢复不能重写历史恢复本身必须成为证据链的一部分。执行前控制决定什么可以发生执行后证明决定如何证明发生了什么。不能证明发生了什么的执行本身就是一种失控。Havenlon 对证据链与执行事实的基本回应Havenlon 不把应用日志、SaaS 数据库状态或单一 Receipt 视为完整执行事实。它要求每个 Intent 都拥有唯一 IntentHashProposal、Approval、Arbitration、Commit、Execution 和 Receipt 分别形成证据不同事实由有资格的不同来源证明SaaS 负责协同展示和归档但不能创造 Device-Signed FactDevice-Signed Commit 作为本地提交事实来源Executor Result 作为执行调用事实来源External Receipt 作为外部响应事实来源每条证据绑定具体 Intent每条结果证据绑定具体 Commit每条证据拥有明确 event type使用 counter 证明事件顺序使用 Previous Evidence Hash 建立前序关系使用 Current Evidence Hash 保护当前记录使用 Result Hash 绑定最终结果使用设备签名证明本地事实来源成功、失败、拒绝、中断和恢复全部留证历史 Evidence 采用追加式变化错误解释通过 Correction Evidence 修正恢复过程通过 Recovery Evidence 记录使用 Evidence Checkpoint 防止长期历史回滚使用 Evidence Replication 增强存续能力使用 Evidence Witness 提供独立验证检测 counter 回退、hash 断裂和证据分叉Evidence Conflict 发生时保留所有来源Commit 已形成但结果未知时禁止无条件重试Evidence Backpressure 时降低执行能力证据链异常时进入 Evidence-Safe Mode管理员不能通过修改 SaaS 状态覆盖设备签名事实执行者不能无约束删除或重写自己的执行证据当证据无法证明执行状态连续、完整和可验证时不继续扩大不可逆执行。最终原则是Havenlon 不只要求动作受到约束还要求动作发生之后任何单一主体都不能垄断对事实的解释。一次执行只有在能够被证明来自哪个 Intent、经过哪些约束、形成哪个 Commit、产生什么结果时才真正成为可治理的现实。不能证明发生了什么的执行本身就是一种失控。