基于YOLOv11的焊缝缺陷智能检测系统开发实践
2026/7/25 10:42:56
Working Draft · AI Era Execution Security Language
This 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 = success
SaaS 可以显示：
Committed
数据库可以保存：
executed = true
但这些状态通常只能证明：
某个软件组件在某一时刻写入了这条记录。
它们不能天然证明：
本地设备确实形成了 Commit；
Security Domain 确实使用了指定密钥；
Executor 确实提交了原 Payload；
外部系统确实接受或完成了动作；
最终结果与原始 Intent 一致；
管理员没有事后修改记录；
中间失败、拒绝或重试没有被删除。
因此，Havenlon 不把日志等同于证据，也不把 SaaS 数据库等同于事实来源。
它要求：
执行事实必须由真正参与相应阶段的主体产生，并通过签名、哈希、计数器、前序关系和多方见证形成可独立验证的证据链。
执行者可以证明自己执行了什么。
设备可以证明自己提交或拒绝了什么。
外部系统可以证明自己接收或返回了什么。
SaaS 可以证明自己保存和展示了什么。
但任何一个主体都不能单独替代整条执行事实链。
1. Evidence｜证据
一句话定义
证据，是能够被独立验证，用于支持某个执行、治理、拒绝、失败或恢复事实的记录。
严格定义
证据不仅是一段文字或数据库字段。
一条有效证据至少应明确：
证明什么事件；
对应哪个 Intent；
由谁产生；
产生于哪个设备或信任域；
发生在哪个执行阶段；
使用了什么 Policy 和治理状态；
前一条证据是什么；
当前结果是什么；
是否存在计数器；
是否有可验证签名；
是否可以关联到后续证据。
证据必须同时具备：
来源可验证；
内容可验证；
对象可关联；
顺序可验证；
修改可发现；
缺失可发现。
上位概念
执行证明
可验证记录
事实支持
下位概念
执行证据
提议证据
审批证据
仲裁证据
提交证据
拒绝证据
失败证据
恢复证据
相关概念
Execution Fact
Evidence Chain
Device-Signed Fact
Evidence Store
Post-Execution Proof
容易混淆的概念
证据不等于：
普通日志；
UI 状态；
SaaS 数据库记录；
管理员说明；
单独一条 Receipt；
单独一个交易哈希。
这些信息可以成为证据组成部分，但必须完成来源、对象和链路绑定。
权力边界
一个主体只能对自己实际观察、判断或执行的事实提供证据，不能替其他信任域声明其无法直接证明的事实。
约束机制
数字签名；
IntentHash；
Commit ID；
Result Hash；
前序哈希；
单调计数器；
域分离；
多副本归档。
结果目标
让关键执行历史不依赖某个应用、数据库或管理员的单方面叙述。
在 Havenlon 中
Proposal、Approval、Arbitration、Device-Signed Commit、Executor Result 和 Receipt 分别形成证据，并最终进入 Evidence Store。
2. Execution Evidence｜执行证据
一句话定义
执行证据，是用于证明某个 Intent 从提议到最终结果经历了哪些执行阶段的证据集合。
严格定义
完整的 Execution Evidence 应能够回答：
Intent 是什么；
谁发起了 Intent；
哪些主体参与了审批；
使用了哪个治理状态；
使用了哪个 Policy；
Arbiter 作出了什么判断；
最终载荷是什么；
哪个设备形成 Commit；
使用了哪个 Key Slot；
使用了哪个 Execution Slot；
哪个 Executor 实施动作；
外部系统返回什么；
最终结果是什么；
是否发生失败、中断、重试或恢复。
执行证据不是单一结果记录，而是一组互相关联的阶段证据。
上位概念
Evidence
Post-Execution Proof
下位概念
Proposal Evidence
Approval Evidence
Arbitration Evidence
Commit Evidence
Execution Result Evidence
Receipt Evidence
相关概念
Execution Chain
Evidence Chain
Device-Signed Commit
Result Hash
Receipt Binding
权力边界
任何单一系统都不能通过补写一条最终结果记录，替代中间缺失的完整执行证据。
约束机制
IntentHash；
Step Hash；
Commit ID；
Result Hash；
Device Signature；
Receipt Binding；
证据链；
多源验证。
结果目标
使审计者能够从证据中重建一次执行的实际过程，而不是只能看到最终状态。
在 Havenlon 中
Execution Evidence 从 Intent 创建开始，到外部结果确认结束，贯穿整个执行生命周期。
3. Execution Fact｜执行事实
一句话定义
执行事实，是关于一次动作是否提交、是否执行以及产生什么结果的可验证状态陈述。
严格定义
执行事实必须分层定义。
一次动作可能存在以下不同事实：
Intent 已产生 Proposal 已提交 Approval 已形成 Arbitration 已通过 Commit 已形成 Executor 已调用 外部系统已接收 外部系统已完成 最终业务目标已实现
这些事实不能互相替代。
例如：
Commit 已形成，不代表 Executor 已成功调用；
Executor 返回成功，不代表外部业务状态已最终完成；
交易已广播，不代表链上已经最终确认；
API 返回 200，不代表执行语义与 Intent 完全一致。
上位概念
可验证事实
执行状态
下位概念
Intent Fact
Approval Fact
Arbitration Fact
Commit Fact
Invocation Fact
Receipt Fact
Final Result Fact
相关概念
Device-Signed Fact
Source of Truth
Receipt
Finality
Post-Execution Proof
权力边界
每个事实来源只能证明其负责阶段内发生的事实，不能把局部事实扩张为整个业务已经完成。
约束机制
事实类型；
阶段标识；
来源身份；
对象绑定；
时间；
计数器；
数字签名。
结果目标
消除“已提交”“已调用”“已接收”和“已完成”之间的状态混淆。
在 Havenlon 中
Device-Signed Commit、Executor Invocation、外部 Receipt 和最终 Result 分别被建模为不同执行事实。
4. Device-Signed Fact｜设备签名事实
一句话定义
设备签名事实，是本地设备对其实际参与的判断、提交、拒绝、执行或恢复事件签名形成的可验证事实。
严格定义
设备签名事实通常应包含：
device_id；
event_type；
IntentHash；
Commit ID；
Step Hash；
Policy Hash；
Governance Hash；
counter；
previous evidence hash；
result hash；
device state；
device signature。
它可以证明：
某个具体设备，在某个具体状态下，对某个具体 Intent 作出了某项具体陈述或动作。
它不能自动证明：
设备没有漏洞；
Intent 一定正确；
外部系统已经完成动作；
整个业务结果已经成功；
设备内部所有状态绝对真实。
上位概念
Execution Fact
Evidence
本地事实
下位概念
设备仲裁事实
设备提交事实
设备拒绝事实
设备执行事实
设备恢复事实
相关概念
Device-Signed Commit
Device Identity
Evidence Store
Counter
Trust 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 Truth
Device-Signed Fact
Evidence Witness
Trust Domain
Fact 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 Authority
Device-Signed Fact
SaaS Coordination Plane
Evidence Witness
Evidence Conflict
容易混淆的概念
Source of Truth 不应被理解为：
一个万能数据库；
一个超级管理员；
一个 SaaS 后台；
一个不可失败的终极组件。
约束机制
事实分类；
来源映射；
来源资格；
签名验证；
冲突保留；
不允许静默覆盖。
结果目标
让不同系统发生冲突时，能够依据事实类型判断谁有资格证明什么。
在 Havenlon 中
对于本地提交事实，Device-Signed Commit 优先于 SaaS 中的committed=true状态。