jverdicc/EvidenceOS
GitHub: jverdicc/EvidenceOS
EvidenceOS是一个验证协议内核，通过守恒证据预算和信息论泄露边界来控制AI自适应交互中的能力提取风险。
Stars: 1 | Forks: 0
# EvidenceOS (Rust)
[](https://github.com/jverdicc/EvidenceOS/actions/workflows/ci.yml)
[](LICENSE)
[](https://doi.org/10.5281/zenodo.18685556)
[](https://doi.org/10.5281/zenodo.18685556)
EvidenceOS 是一个面向生产的通用验证协议 验证内核。
## 范围与术语（如果您在想“运行时治理”，请阅读此部分）
EvidenceOS 是一个用于自适应交互下离散声明胶囊的确定性结算内核。它执行单向门生命周期（CreateClaim -> Freeze -> Seal -> Execute），并对 Oracle 输出进行计量，从而使适应性泄露被预算控制而非被忽略。
术语说明：当本项目提到“实时”时，指的是胶囊的确定性、低尾延迟、高频事务处理（撮合引擎风格）。这并不意味着 EvidenceOS 摄取或治理连续的、流式的 Agent 行为轨迹。
连续的 Agent 治理通过适配器/边车 模式支持（在 DiscOS/OpenClaw 中），该模式：
- 监视高风险的 Agent 动作/工具调用，
- 仅快照可证伪的工件，
- 将其编译成可接纳的胶囊，
- 提交给 EvidenceOS 进行结算，
- 将签名回执重新注入 Agent 循环。
这是用于连续 Agent 集成模式的适配器/边车。
参见：[`docs/REALTIME_VS_RUNTIME.md`](docs/REALTIME_VS_RUNTIME.md) 和 [`docs/AGENT_ADAPTER_CONTRACT.md`](docs/AGENT_ADAPTER_CONTRACT.md)
## 什么是 UVP（60 秒简介）
UVP 是一个用于在自适应交互下认证声明的内核 + 用户空间架构。DiscOS（独立仓库）是不受信任的发现/用户空间，负责提出声明胶囊。EvidenceOS（本仓库）是受信任的内核，负责在留存数据 上执行胶囊。每个 Oracle 响应都被规范化、计量和记录，因此泄露是被预算控制的而非被忽略。
该协议跨时间、身份和接口跟踪证据财富 和适应性泄露。这使得协调探测变得可衡量、昂贵且可审计，而不是在无声中累积。结果是一个具有明确风险态势、确定性结算和可撤销证据链的验证系统。
## 从这里开始（2 分钟入门）
1. **黑盒威胁模型演练（推荐首先阅读）：** [`docs/THREAT_MODEL_BLACKBOX.md`](docs/THREAT_MODEL_BLACKBOX.md)
2. **引导式入职路径：** [`docs/START_HERE.md`](docs/START_HERE.md)
3. **实战威胁模型示例：** [`docs/threat_model_worked_example.md`](docs/threat_model_worked_example.md)
4. **黑盒 UVP 接口说明：** [`docs/uvp_blackbox_interface.md`](docs/uvp_blackbox_interface.md)
5. **实时与运行时治理术语：** [`docs/REALTIME_VS_RUNTIME.md`](docs/REALTIME_VS_RUNTIME.md)
6. **连续 Agent 适配器信任边界：** [`docs/AGENT_ADAPTER_CONTRACT.md`](docs/AGENT_ADAPTER_CONTRACT.md)
7. **动手对抗性演示：** [`examples/exfiltration_demo/`](examples/exfiltration_demo/)
8. **认识论试验工具（临床试验式评估）：** [`docs/EPISTEMIC_TRIAL_HARNESS.md`](docs/EPISTEMIC_TRIAL_HARNESS.md) ([分析管道](docs/TRIAL_HARNESS_ANALYSIS.md))
立即运行：
python -m venv .venv && source .venv/bin/activate
python -m pip install -e '.[analysis]'
python -m analysis.epistemic_trial.report --help
# 最小化完整运行（需要一个 ETL 文件）：
python -m analysis.epistemic_trial.report --etl path/to/etl.log --out out/trial_report
9. **基于角色的读者导图：** [`docs/reader_map.md`](docs/reader_map.md)
10. **安全实现文档：** [`docs/HOLDOUT_ENCRYPTION.md`](docs/HOLDOUT_ENCRYPTION.md), [`docs/TEE.md`](docs/TEE.md), [`docs/IMPLEMENTATION_STATUS.md`](docs/IMPLEMENTATION_STATUS.md)
新接触本项目或来自非系统工程背景？请从 [`docs/START_HERE.md`](docs/START_HERE.md) 开始，获取更多引导式阅读路径。
## 15 行黑盒玩具场景（内核为何有效）
1. DiscOS 使用 `CreateClaimV2` 开启一个用于私有留存评估的声明。
2. 攻击者发送自适应 Oracle 查询 #1；输出字母表为包含 4 个符号的 `Y`。
3. EvidenceOS 首先规范化输出；格式错误/非规范的有效载荷被拒绝，且**不收取 k 费用**。
4. 有效查询 #1 被收取 `k_1 = log2(|Y|) = log2(4) = 2` 比特。
5. 查询 #2 和 #3 以规范输出重复；累积泄露为 `k_tot = Σ_i k_i`。
6. 在执行继续之前，强制执行声明生命周期：`CreateClaimV2 -> Freeze -> Seal -> Execute`。
7. `Freeze` 锁定可接纳性/材料，因此探测无法在中途重写声明。
8. `Seal` 绑定确定性执行上下文和账本状态以供可审计重放。
9. `Execute` 仅返回规范符号/回执，绝不返回原始留存内部信息。
10. 每个被接受的符号在界限内将虚假认证风险乘以 `2^{k_i}`。
11. 因此 EvidenceOS 在自适应查询后将显著性更新为 `alpha' = alpha * 2^{-k_tot}`。
12. 认证需要足够的证据财富：`E >= 2^{k_tot}/alpha`。
13. 如果 `E` 低于阈值，结果是限流/重度检查/冻结，而非认证。
14. 如果 `k_tot` 达到策略预算，声明冻结，进一步查询停止产生信号。
15. 净效应：攻击者可以查询，但每一位都被计量、限制和审计。
### 最小化伪 CLI 记录（现有脚本路径）
```
$ make blackbox-demo
Generated docs/generated/blackbox_demo.md
$ sed -n '1,40p' docs/generated/blackbox_demo.md
# 黑盒演示：Transcript → Ledger → Freeze
...
| 1 | c01 | quality_oracle | Q_BUCKET_MED | 4 | 2.00 | 2.00 | 6.00 | PASS ... |
| 3 | c03 | safety_oracle | S_FLAG_LOW | 8 | 3.00 | 7.00 | 1.00 | PASS ... |
| 4 | c04 | robustness_oracle | R_BAND_2 | 16 | 4.00 | 11.00| 0.00 | FROZEN ... |
```
然后阅读 [`docs/START_HERE.md`](docs/START_HERE.md) 获取引导图，以及 [`docs/EPISTEMIC_TRIAL_HARNESS.md`](docs/EPISTEMIC_TRIAL_HARNESS.md) 进行严格的试验式评估。
## 临床试验工具
EvidenceOS 包含一个用于临床试验式评估的 **认识论试验工具**。
- 工具规格：[`docs/EPISTEMIC_TRIAL_HARNESS.md`](docs/EPISTEMIC_TRIAL_HARNESS.md)
- 分析管道：[`docs/TRIAL_HARNESS_ANALYSIS.md`](docs/TRIAL_HARNESS_ANALYSIS.md)
- 分析工作区概览：[`analysis/README.md`](analysis/README.md)
本仓库包含：
- `evidenceos-core`：守恒账本原语、确定性逻辑时钟、ETL Merkle 日志和类 ASPEC 的 Wasm 验证器。
- `evidenceos-daemon`：暴露内核 API 的 gRPC 服务。
- **[DiscOS](https://github.com/jverdicc/DiscOS)**（独立仓库）：不受信任的发现/用户空间编排器，负责提出声明胶囊并消费内核响应。
## 技术摘要
EvidenceOS + DiscOS 实现了通用验证协议 (UVP)：一种用于在自适应交互下认证声明的内核-用户空间架构。DiscOS 是不受信任的“发现”用户空间，负责提出可执行声明胶囊；EvidenceOS 是一个内核，负责在留存数据上执行胶囊，控制所有内核 I/O，并发出可审计的回执。
UVP 的核心理念是守恒：认证被视为一种稀缺资源。每个 Oracle 回复和每个输出字节都被 (1) 规范化，(2) 计量，和 (3) 记录，以便安全论证可以跨时间、身份和相关性查询流进行组合。论文用守恒证据预算形式化了这一点：证据财富 W（由声明谱系积累的真值货币）和适应性泄露 k（通过交互揭示的关于留存数据的信息）。定理 1 在假设内核强制执行规范实现、可接纳执行和计量 Oracle 的前提下，将虚假认证界定为转录支持大小的函数。
EvidenceOS 用几个原语实现了这一封装：
• 带滞后的量化 Oracle。Oracle 返回离散符号 而非高精度分数。输出滞后为局部变异增加“度量停滞”：如果新提交的真实度量变化低于配置的 Δσ 阈值，内核返回前一个桶。这在论文的压力测试中瓦解了桶探测精度，并迫使任何潜在攻击者为获得新信息付出代价进行非局部“跳跃”。
• 守恒的联合记账。守恒账本将每次查询/结算记入 k 和 W。当多个接口共享秘密时（例如，同一留存数据上的准确性和安全性），账本使用联合接口记账，因此跨 Oracle 探测无法通过跨度量的“微分”攻击提取更多比特。
• 依赖下的安全组合。在相关性下，朴素的乘积组合可能失效，EvidenceOS 提供了保守的 e-merging 组合器，旨在无需独立性假设的情况下保持有效。
• 通过主题预算抵抗女巫攻击。单账户限制可通过身份轮换突破；UVP 对共享主题池 收取费用，因此提取不会随身份扩展。
• 不可绕过的可接纳性 (ASPEC)。ASPEC 是声明 Wasm 的可判定可接纳性配置文件，它禁止环境能力（时间、随机性、网络、文件），在密封/高保证操作中禁止客户机 DP 系统调用（`dp_laplace_i64`, `dp_gaussian_i64`），强制静态资源限制，并防止隐藏的内部搜索。这确保假设选择通过计量的 Oracle 调用发生，而不是在提交的代码内部。
• 确定性、可审计的结算。确定性逻辑时钟 (DLC) 和周期结算减少了时序泄露。证据透明日志 (ETL) 是一个仅追加的 Merkle 日志，发布签名树头，支持包含/一致性证明，并提供撤销反馈。声明形成一个谱系 DAG；当根节点被削减时，递归撤销会污染后代。
UVP 使用通道 来权衡延迟和保证。随着风险目标收紧（α → 10⁻⁶ 及以上），系统会碰到“验证墙”：更多工作被转移到 HEAVY 验证和延迟结算，而不是允许高带宽交互。
对于最高风险配置文件（例如 CBRN），UVP 建议将输出限制为结构化声明：具有确定性规范化的模式有界、类型化字段。这瓦解了转录容量并减少了隐写/操纵带宽，使严格的保证目标变得易处理。
最好将 EvidenceOS 理解为大型安全系统内的验证内核：主机妥协、密钥盗窃和硬件侧信道除了协议外，还需要标准的隔离和部署控制。
## 威胁模型（摘要）
EvidenceOS 假设自适应调用者可以使用重复交互随时间提取留存信号，即使每个单独的响应看起来无害。防御姿态是规范化和计量交互，维护共享泄露/证据预算，并在风险态势被超过时通过升级和冻结失败关闭。
有关完整的叙述演练和示例，请参见 [`docs/THREAT_MODEL_BLACKBOX.md`](docs/THREAT_MODEL_BLACKBOX.md)。
## 架构图
有关 Vault/Oracle 内部和端到端 UVP 流程的高级视觉参考，请参见 [`docs/ARCHITECTURE_DIAGRAMS.md`](docs/ARCHITECTURE_DIAGRAMS.md)。
有关文档的紧凑索引，请参见 [`docs/README.md`](docs/README.md)。
## 架构：语言权衡矩阵
对于 EvidenceOS 内核，语言选择是安全和确定性决策，而非开发人员偏好。通用验证协议 (UVP) 需要严格的 **三要素**：
1. **构建时的内存安全**（以保留内核威胁边界并防止内存破坏逃逸）。
2. **确定性低延迟执行**（以避免可能扭曲结算和验证行为的运行时抖动）。
3. **现代系统生态适应性**（以直接与 gRPC/Protobuf 和当代 AI Agent 编排堆栈集成）。
除了 Rust，没有主流语言能同时提供这三点。
| 语言 | 它的优点 | 为何不符合 UVP 内核要求 |
|---|---|---|
| **C++** | 卓越的性能；在延迟至关重要的 MFT/HFT 基础设施中占主导地位。 | 在我们的威胁模型中，手动内存管理为缓冲区溢出和内存破坏类别留有空间，这些可能成为“密封 Vault”边界逃逸。该风险与内核级验证不兼容。 |
| **Go / Java** | 强大的内存安全和成熟的生产工具。 | 它们的 GC 运行时引入了非确定性的暂停行为和尾延迟峰值。对于算法交易级别的时序和硬实时验证约束，这种执行抖动是不可接受的。 |
| **Ada / SPARK** | 强大的安全和形式保证姿态。 | 它目前不提供我们所需的现代生态系统人体工程学（尤其是与 gRPC/Protobuf 的无缝集成），无法以高速度与当前 AI Agent 工作流对接。 |
**为何 Rust 是可行的内核语言：** Rust 的 **所有权和借用** 模型在编译时强制执行内存安全和数据无竞争，同时保留可预测的性能，零垃圾回收器运行时开销。这正是 UVP 三要素：安全、确定性和实用集成集一种系统语言之中。
## 操作级安全
在 Swarm 设置中，每次提示或每次 Agent 的监控会失效，因为每个单独的交换看起来无害，而聚合序列仍然提取敏感的留存结构（论文：§2 威胁模型；论文：§3 适应性泄露）。Swarm 可以跨许多身份、工具和时间窗口分配探测，因此仅一次评分一个请求的控制会错过操作级轨迹（论文：§12 多身份适应）。因此，UVP 将 **操作** 视为一级记账对象，而不是假设 Agent 边界是有意义的安全边界（论文：§14 跨声明预算）。在 EvidenceOS 中，操作身份由共享主题键（`TopicHash`/`MultiSignalTopicID`）加上谱系上下文和工具/动作元数据表示，因此即使源账户轮换，相关活动也被计入公共预算（论文：§14 跨声明预算；论文：§11 主题耦合）。这使得提取成本在整个操作中累积，而不是按提示、按会话或按工作进程重置。谱系 DAG 链接和 ETL 承诺保留了确定性执行这些共享预算所需的历史，并事后证明决策（论文：§7 谱系和撤销；论文：§9 透明日志）。然后，UVP 将通道路由应用于操作风险，随着证据预算消耗或异常信号增加，将流量移动通过 PASS、CANARY、HEAVY、REJECT 和 FROZEN 状态（论文：§10 通道和干预）。这些通道实施分级干预：PASS 中低摩擦允许，CANARY/HEAVY 中更高审查和限流，REJECT 中硬性拒绝，FROZEN 中包含和污染传播。安全示例：如果多个看起来良性的请求共同显示跨通道的时间阶梯探测，系统会升级通道并可能冻结后代，而不是发出高带宽反馈。结果是防御性操作级控制，它在约束 Swarm 适应性的同时不发布攻击性剧本。
### 操作信号 → UVP 执行面
| 操作信号 | UVP 原语 | 预期系统响应 |
|---|---|---|
| 跨许多小请求的时间阶梯探测 | `TopicHash` / `MultiSignalTopicID` 跨声明预算 | 通道升级（PASS → CANARY/HEAVY）和更紧的响应分辨率 |
| 跨通道微分探测（通过多个工具/Oracle 达到同一目标） | 联合账本记账 + 共享主题池 | 限流加上共享预算借记以防止通道套利 |
| 针对一个操作目标身份轮换 | 主题耦合记账 + 谱系感知归属 | 尽管账户流失仍升级或拒绝 |
| 风险父声明后快速后代分支 | 谱系 DAG + ETL 支持的撤销传播 | 污染后代并可选冻结分支（`FROZEN`） |
| 结算边界附近的突发活动 | DLC 周期 + 确定性结算窗口 | 延迟/排队进入 HEAVY 通道；限制时序侧信道价值 |
| 可疑验证金丝雀失败 | 金丝雀脉冲检查 + 撤销反馈 | 立即通道提升，可能 REJECT/FROZEN，发布撤销信号 |
有关更深入的操作模型和企业集成指导，请参见 [`docs/OPERATION_LEVEL_SECURITY.md`](docs/OPERATION_LEVEL_SECURITY.md)。
## 架构概览
```
DiscOS (untrusted discovery/userland)
|
| gRPC (canonicalized, validated, metered)
v
EvidenceOS daemon + kernel (ASPEC, W/k accounting, DLC lanes)
|
| append-only commits + signatures
v
ETL (Merkle log, STH/inclusion/consistency proofs)
|
| references
v
Claim Capsules (lineage DAG, revocation-aware settlement)
```
## 通俗英语概述（为何存在）
EvidenceOS 和 DiscOS 实现了通用验证协议 (UVP)：一种即使对手可以跨许多交互调整其策略也能认证“声明”（机器可检查输出）的方法。
如果您曾见过一个系统，其中每个单独的请求看起来都很正常——但跨时间、账户或通道的聚合行为显然是在探测——那就是 UVP 设计要关闭的失效模式。我们将 *操作*（协调活动）视为被计量和控制的对象，而不仅仅是单个请求。
**您得到什么：**
- 一个强化的验证器守护进程，它在密封沙箱中执行声明，计量 Oracle 访问，并发布可审计证据（ETL 日志 + 包含/一致性证明）。
- 一个不受信任的客户端/工具层，它确定性地准备声明并消费验证器响应，而不扩展信任边界。
- 一个可复现的测试/证据故事：系统测试、模糊测试、覆盖率门控和场景工件位于 `artifacts/` 下。
**您 *不* 会得到什么：**
- 内容审核系统。
- 关于“人类主导的物理执行质量”的保证。
- 仅靠策略使不安全能力变得安全的方法（UVP 是关于可验证认证 + 证据守恒 + 可衡量泄露控制）。
### 当有人探测系统时会发生什么？
EvidenceOS 旨在使探测：
1. 可衡量（k 比特 / 预算消耗，通道转换，拒绝），
2. 昂贵（预算和限流是操作范围的），
3. 可审计（ETL 证据），以及
4. 可停止（可以失败关闭的分级响应）。
## 范围和非目标
EvidenceOS 解决 **评估完整性和适应性泄露控制**。它不：
- 评估模型毒性、偏差或幻觉率
- 替代内容审核或基于 RLHF 的对齐
- 为单次交互提供安全保证
EvidenceOS 专为假设 AI 系统能力强、可能具有欺骗性并随时间跨许多交互运行的场景而设计。其保证是协议级和数学上的，而非行为上的。
有关完整的能力和风险矩阵，请参见 [`docs/POSITIONING.md`](docs/POSITIONING.md)。
## 现实世界验证
2026 年 2 月 23 日，Anthropic 发布了一份安全
报告，记录了 DeepSeek、Moonshot AI 和
MiniMax 对 Claude 的三次工业规模蒸馏
攻击。这些活动在约 24,000 个欺诈
账户中产生了超过 1600 万次
交换，针对包括
Agentic 推理、工具使用和思维链
提取在内的特定能力。
Anthropic 发布的这些攻击描述直接
映射到 UVP 论文中形式化的
威胁模型并在 EvidenceOS 中实现。
来源：https://www.anthropic.com/research/detecting-and-preventing-distillation-attacks
### 攻击模式映射
| Anthropic 观察到的攻击 | UVP 威胁模型 | EvidenceOS 机制 |
|---|---|---|
| 24,000 个欺诈账户轮换以逃避单账户封禁 | 女巫放大（论文 §12） | TopicHash / MultiSignalTopicID 共享预算 — 提取成本在所有身份中累积，而不是按账户重置 |
| 跨账户协调的 16M+ 次交换针对同一狭窄能力 | 适应性泄露 / 操作级提取（论文 §2, §14） | 守恒账本在整个操作中累积收取 k 比特，而不是按会话 |
| 思维链诱导重复数万次以生成训练数据 | 通过重复 Oracle 探测进行结构化能力提取 | 量化 Oracle + 滞后瓦解了重复近乎相同查询的精度；ASPEC 拒绝旨在诱导未计量内部推理的胶囊 |
| 跨账户“负载均衡”以增加吞吐量并逃避检测 | 分布式萨拉米香肠攻击（论文 §11） | 联合接口记账检测相关能力的跨账户探测；主题预算在操作间共享 |
| MiniMax 在 Anthropic 发布新模型后 24 小时内转向，将流量重定向到新系统 | 实时更新策略的自适应对手 | DLC 周期结算 + W/k 账本连续性 — 策略转向不重置预算；累积泄露持续存在 |
### EvidenceOS 增加了反应式检测所没有的功能
Anthropic 发布的对策是分类器、
行为指纹识别和访问控制。这些
是反应式的：它们在提取
发生后识别攻击。Anthropic 将在“仍处于活动状态”时检测 MiniMax 描述为
“前所未有的可见性” — 在 1300 万次交换之后 —
EvidenceOS 旨在使 1300 万次交换
在提取成功之前在有界预算内
数学上不可能。守恒账本不
检测预算何时被超过。它执行
对可提取内容的硬上限，主动地，
通过构造。
区别在于：
- **反应式检测：** 在提取
发生后识别攻击。封禁账户。
能力已经转移。
- **主动界定 (UVP)：** 使超出
定义的 k 比特预算的提取物理上不可能。
即使未被检测到，攻击也无法成功。
这是从社会/启发式过程到
UVP 论文主张的计算底层的转变。
Anthropic 2026 年 2 月的报告是
没有它的情况下工业规模发生情况的现实世界案例研究。
## 实际用例和结果
| 用例类别 | 对抗性向量（通俗英语） | EvidenceOS 机制 | 缓解 / 结果 | 可复现证据 |
| --- | --- | --- | --- | --- |
| 传输/认证探测 | 凭证填充、缺失令牌、无效令牌尝试 | TLS/mTLS + bearer/HMAC 认证门 + 失败关闭拦截器 | REJECT / UNAUTHENTICATED | `crates/evidenceos-daemon/tests/transport_hardening_system.rs`, `crates/evidenceos-daemon/src/auth.rs::tests::wrong_token_rejected` |
| 超大有效载荷 / 解码限制探测 | 旨在耗尽解码/内存路径的超大 Protobuf 有效载荷 | 有界解码（`decode_with_max_size`）+ 严格的 gRPC 大小检查 | REJECT (`RESOURCE_EXHAUSTED`) | `fuzz/fuzz_targets/fuzz_daemon_decode_limits.rs`, `crates/evidenceos-daemon/src/auth.rs` |
| 模式别名探测 / 主题漂移尝试 | 替代模式别名或漂移尝试以绕过规范主题绑定 | 模式规范化 + 从规范元数据/信号派生 `topic_id` | 仅对规范化别名 PASS；否则 REJECT | `crates/evidenceos-daemon/tests/schema_aliases_system.rs`, `docs/TEST_COVERAGE_MATRIX.md` |
| 类蒸馏高通量探测 | 随时间学习内部行为的许多不同声明尝试 | 按操作/令牌范围的探测器检测请求数量 + 语义多样性 + 主题多样性，具有 k 比特/记账可见性 | THROTTLE → ESCALATE → FROZEN/REJECT | `crates/evidenceos-daemon/tests/probing_detection_system.rs`, `artifacts/probing/probing_detection_system.json`, `fuzz/fuzz_targets/fuzz_probe_detector.rs` |
| ETL 篡改尝试 | 错误的包含/一致性证明或分叉历史声明 | ETL Merkle 包含/一致性验证 + 签名树头 | REJECT / incident | `crates/evidenceos-daemon/tests/etl_verification_system.rs`, `crates/evidenceos-daemon/tests/etl_proofs_system.rs` |
| 密封 Vault 逃逸尝试 | 过多 Oracle 调用、超大输出、禁止的运行时行为（以及配置时的浮点操作策略拒绝） | 密封 Vault 限制 + ASPEC 策略 + 通道控制 + 确定性结算检查 | 视违规情况而定 THROTTLE/REJECT/FROZEN | `crates/evidenceos-daemon/tests/vault_execution.rs`, `crates/evidenceos-daemon/tests/aspec_rejections.rs`, `fuzz/fuzz_targets/fuzz_aspec_verify.rs` |
有关展示 UVP 如何映射到电子交易、FDA 提交、疾病监测和其他高风险系统的特定领域集成指南，请参见 [docs/INTEGRATION_PATTERNS.md](docs/INTEGRATION_PATTERNS.md)。
### 案例研究：类蒸馏探测（公开报告）
一类常被报告的事件是旨在克隆模型行为并强制内部推理轨迹的高容量提示活动。EvidenceOS 将此视为验证器边界处的操作级安全事件：它实时检测高容量/高多样性探测模式，应用分级响应（THROTTLE，然后 ESCALATE，然后 FROZEN/REJECT），并记录响应发生的可审计 ETL 证据。
### 威胁地平线：后量子考量
EvidenceOS 的核心保证（定理 1）是信息论的，对量子加速不变——量子计算机无法从 k 比特预算中提取超过 k 比特。然而，在后量子环境中系统面临两个特定转变：
1. **加密暴露：** 当前加密层（ETL 签名、TopicHash）带有标准量子暴露。Shor 算法威胁 Ed25519 签名密钥，Grover 算法将有效哈希安全性减半。迁移到 CRYSTALS-Dilithium 用于签名和 SHA-3/512 用于主题哈希是一个路线图项目，无需对底层守恒账本逻辑进行任何更改。
2. **量子优化风险：** 更尖锐的风险是对抗效率。使用 QAOA（量子近似优化算法）的量子 Agent 可以在固定预算内找到最大效率的提取路径，使对抗模型显著收紧。虽然信息论墙壁保留，但 Agent“完美打包”其提取背包的能力增加。后量子威胁环境中的运营商应相应配置保守的 k 预算。
*状态：路线图。核心定理通过构造抗量子。加密迁移已在架构中指定。*
## 保证状态
- **已证明（论文级模型）：** UVP 守恒框架、转录记账和定理支持的风险界限（在 stated 内核假设下）。
- **模拟测试（仓库证据）：** 确定性行为、账本转换、L 证明/一致性、gRPC 生命周期路径和模糊解析器/状态面。
- **架构已指定：** DiscOS↔EvidenceOS 分离、ASPEC 可接纳边界、主题预算抗女巫模型和基于通道的结算控制。
- **路线图：** 围绕密钥生命周期/轮换的更强生产加固、扩展的策略包和额外的端到端对抗模拟套件。
- **PLN 实现范围：** 当前生产 PLN 是运行时燃料标准化 + 确定性周期舍入；编译时 CFG 分支均衡尚未实现（参见 `docs/PLN_PRODUCTION_PROFILE.md`）。
## 实现状态（论文 ↔ 代码）
为避免论文工件快照和当前主线代码之间的审查时间歧义，请使用：
- [`docs/PAPER_VS_CODE.md`](docs/PAPER_VS_CODE.md) 查看实时一致性矩阵（论文声明 → 仓库实现 → 状态）。
- [`docs/IMPLEMENTATION_STATUS.md`](docs/IMPLEMENTATION_STATUS.md) 查看额外实现护栏说明，包括论文关键的泄露/记账不变量（k_i, k_tot, alpha' 和认证阈值）。
## 验证矩阵
| 用例类别 | 对抗性向量（高层） | EvidenceOS 机制 | 缓解 / 结果 | 状态 | 证据 |
| --- | --- | --- | --- | --- | --- |
| 适应性度量探测 | 重复近阈值探测以推断留存内部 | 量化（`epsilon`/分桶）、滞后（`delta` 停滞）、W/k 收费 | 随 k 预算上升 THROTTLE 或 HEAVY；减少比特泄露 | Live | [docs/TEST_COVERAGE_MATRIX.md](docs/TEST_COVERAGE_MATRIX.md), [docs/TEST_EVIDENCE.md](docs/TEST_EVIDENCE.md), [`fuzz_oracle_roundtrip`](fuzz/fuzz_targets/fuzz_oracle_roundtrip.rs) |
| 跨接口微分提取 | 跨相关 Oracle 接口组合输出 | 联合接口记账、守恒 W/k 预算、主题池 | 仅在预算内 PASS；否则 THROTTLE/HEAVY | Sim-tested | [docs/TEST_COVERAGE_MATRIX.md](docs/TEST_COVERAGE_MATRIX.md), [`fuzz_ledger_ops`](fuzz/fuzz_targets/fuzz_ledger_ops.rs) |
| 女巫放大 | 身份轮换以绕过单账户限制 | TopicHash / MultiSignalTopicID 共享预算 | 一旦主题预算耗尽 THROTTLE 或 REJECT | Architecture specified | [docs/TEST_COVERAGE_MATRIX.md](docs/TEST_COVERAGE_MATRIX.md) |
| 蒸馏 / 大规模能力提取 | 24,000 个协调账户通过 16M+ 次交换提取（Anthropic，2026 年 2 月） | TopicHash 共享预算 + 守恒账本 + 联合接口记账 | 提取受所有身份间的 k 比特预算限制；策略转向不重置账本 | Sim-tested | docs/TEST_COVERAGE_MATRIX.md, Anthropic distillation report (Feb 23, 2026) |
| 隐藏胶囊内搜索 | 提交夹带未计量优化/搜索的代码 | ASPEC 可接纳性和有界执行配置文件 | 结算前 REJECT 不可接纳胶囊 | Live | [docs/TEST_EVIDENCE.md](docs/TEST_EVIDENCE.md), [`fuzz_aspec_verify`](fuzz/fuzz_targets/fuzz_aspec_verify.rs) |
| 时序/顺序操纵 | 利用竞争/顺序非确定性获取不一致回执 | 确定性逻辑时钟 (DLC)、规范化、确定性 ETL 提交 | PASS 带可复现回执；分歧流被拒绝/冻结 | Live | [docs/TEST_EVIDENCE.md](docs/TEST_EVIDENCE.md), [`fuzz_etl_ops`](fuzz/fuzz_targets/fuzz_etl_ops.rs), [`fuzz_etl_read_entry`](fuzz/fuzz_targets/fuzz_etl_read_entry.rs) |
| 已证实的不良根传播 | 根失效后下游声明继续 | 谱系 DAG + 递归撤销反馈 | FROZEN/REJECT 受污染后代 | Sim-tested | [docs/TEST_EVIDENCE.md](docs/TEST_EVIDENCE.md), [docs/TEST_COVERAGE_MATRIX.md](docs/TEST_COVERAGE_MATRIX.md) |
## 威胁模型与范围外
EvidenceOS 在其内核假设下解决协议级验证完整性。它本身 **不** 消除部署层妥协类别。
没有额外部署控制的范围外：
- **主机妥协：** 被妥协的主机/VM 可以更改进程内存、二进制文件或运行时控制；使用加固主机、隔离和测量启动/认证。
- **密钥盗窃/滥用：** 被盗的 ETL 签名或服务密钥可以产生令人信服但恶意的工件；使用 HSM/KMS、密钥轮换和严格的操作控制。
- **硬件侧信道：** 协议记账不能中和微架构泄露和物理侧信道；使用工作负载隔离和平台加固。
这些是部署责任。UVP/EvidenceOS 应与标准生产安全控制结合使用。
## 快速入门
### 1) 构建
```
cargo build --workspace
```
### 2) 运行内核
```
cargo run -p evidenceos-daemon -- \
--listen 127.0.0.1:50051 \
--data-dir ./data \
--nullspec-registry-dir ./data/nullspec-registry \
--nullspec-authority-keys-dir ./data/trusted-nullspec-keys
```
### 3) 端到端：在 60 秒内查看声明生命周期
在一个终端启动守护进程（见第 2 步），然后在另一个终端运行：
```
./scripts/run_scenarios.sh
cat artifacts/scenarios/lifecycle_pass.json
```
生命周期工件应包括包含证明、`W`/`k` 账本条目和确定性声明 ID。
要检查冻结路径示例：
```
cat artifacts/scenarios/reject_invalid_claim.json
```
### 4) 测试
```
cargo test --workspace
```
## 可复现性与证据
EvidenceOS 在仓库中保留测试证据和覆盖率映射：
- 测试证据程序/结果：[`docs/TEST_EVIDENCE.md`](docs/TEST_EVIDENCE.md)
- 覆盖率矩阵（机制级）：[`docs/TEST_COVERAGE_MATRIX.md`](docs/TEST_COVERAGE_MATRIX.md)
- 覆盖率矩阵（参数级附录）：[`docs/TEST_COVERAGE_PARAMETERS.md`](docs/TEST_COVERAGE_PARAMETERS.md)
- FORC 论文工件路径索引/状态：[`docs/ARTIFACT_INDEX.md`](docs/ARTIFACT_INDEX.md)
- 从 Zenodo DOI `10.5281/zenodo.18685556` 获取缺失的 FORC 论文工件：`bash scripts/fetch_forc_artifacts.sh`
基线可复现性命令：
```
cargo fmt --check
cargo clippy --workspace --all-targets -- -D warnings
cargo test --workspace
```
模糊入口点（需要 `cargo-fuzz`）：
```
cargo fuzz run fuzz_aspec_verify
cargo fuzz run fuzz_ledger_ops
cargo fuzz run fuzz_oracle_roundtrip
cargo fuzz run fuzz_etl_ops
cargo fuzz run fuzz_etl_read_entry
cargo fuzz run fuzz_structured_claim_validate
cargo fuzz run fuzz_probe_detector
```
## 透明度和事件报告
- 参见 [`docs/REGULATORY_REPORTING.md`](docs/REGULATORY_REPORTING.md) 了解 EvidenceOS 工件如何支持合规、审计和事后审查工作流程的中性概述。
- 该指南解释了如何将签名 ETL 记录、包含证明和一致性检查组装成可验证的报告包，而无需暴露原始敏感有效载荷。
- 它包括针对监管链、保留姿态和证据质量检查的面向实施的建议，以便报告保持可复现和可审查。
- **EvidenceOS 不是监管工具；这是关于可审计性和可验证事件记录。**
## IPC API
EvidenceOS 暴露定义于以下位置的 gRPC/Protobuf API：
- `crates/evidenceos-protocol/proto/evidenceos.proto`（`evidenceos.v2`，规范）
- `crates/evidenceos-protocol/proto/evidenceos_v1.proto`（`evidenceos.v1`，兼容）
版本控制和弃用策略记录在 `docs/PROTOCOL_VERSIONING.md` 中。
兼容性声明：DiscOS 客户端应在连接期间调用 `GetServerInfo` 并在发出生命周期 RPC 之前验证协议主版本兼容性和 `proto_hash` 相等性。EvidenceOS 暴露已弃用的 `Freeze`/`Seal` 别名，这些别名路由到 `FreezeGates`/`SealClaim` 以实现向后兼容。
[DiscOS 仓库](https://github.com/jverdicc/DiscOS) 包括：
- 一个 Rust 客户端
- 一个 Python 客户端示例
- 使用合成/玩具数据并避免操作有害指令的安全演示场景
将 DiscOS 演示与 EvidenceOS 一起使用时，保持演示非操作性和策略一致；参见 [`docs/DUAL_USE_AND_MISUSE.md`](docs/DUAL_USE_AND_MISUSE.md)。
如果您正在遵循引用 `--etl-path` 的旧 DiscOS 文档/示例，请将这些调用更新为 EvidenceOS 当前的 `--data-dir` 标志。
## 声明生命周期 API
守护进程暴露单向声明生命周期：
`CreateClaim -> CommitArtifacts -> FreezeGates -> SealClaim -> ExecuteClaim`
读取 API 可用于胶囊检索、守护进程公钥检索（`GetPublicKey`）、签名树头、包含证明、一致性检查和撤销反馈。
签名验证在带内：客户端通过 `GetPublicKey` 获取 Ed25519 公钥和 `key_id`（`sha256(public_key)`），然后针对域分离预哈希（`evidenceos:sth:v1` 和 `evidenceos:revocations:v1`）验证 SignedTreeHead 和撤销反馈签名。
密钥轮换策略：守护进程支持 `/keys/` 下的密钥环，并使用活动 `key_id` 签名新 STH，同时通过 `GetPublicKey(key_id=...)` 保留历史密钥的验证。
## 研究与引用
本仓库是 **通用验证协议 (UVP)** 研究项目的一部分。
* **论文：** "The Conservation of Epistemic Integrity: A Kernel–Userland Protocol for Verifiable Reality"（在 FORC 2026 审理中）。
有关已发布现实世界攻击模式到 UVP 机制的映射，请参见
[docs/REAL_WORLD_VALIDATION.md](docs/REAL_WORLD_VALIDATION.md)。
* **引用 DOI（所有版本）：** 使用 [DOI: 10.5281/zenodo.18685556](https://doi.org/10.5281/zenodo.18685556) 引用所有版本，该链接始终解析到最新版本。
如果您在研究中使用此代码，请引用 Zenodo 存档或即将发表的 FORC 2026 论文。
## 许可证
Apache-2.0
## Protobuf 工具链
本仓库使用 **vendored protoc**（`protoc-bin-vendored`），因此贡献者和 CI 不需要安装 `protoc`。
## 容器 / 部署
提供了 `Dockerfile`、`docker-compose.yml` 和加固的 `systemd` 单元，位于 `deploy/systemd/` 下。
所有部署入口点应传递 `--data-dir`（而非已移除的 `--etl-path`），以便守护进程在一个目录下管理 `etl.log` 和状态文件。
对于经 HMAC 认证的 Agent，生产部署应通过 `EVIDENCEOS_HMAC_KEYS` 和可选兼容性回退 `EVIDENCEOS_HMAC_SHARED_SECRET` 配置密钥轮换：
- `EVIDENCEOS_HMAC_KEYS` 格式：`"kid1:hexsecret1,kid2:hexsecret2"`。
- 请求可以设置 `x-evidenceos-key-id`；如果省略，守护进程使用 `default`。
- `EVIDENCEOS_HMAC_SHARED_SECRET` 仍然受支持并映射到密钥 id `default` 以实现向后兼容。
- 不要同时在两个地方定义 `default` 密钥。
### 信用与准入
EvidenceOS 在声明执行时强制信用消费。
信用铸造和权益管理由运营商提供。
参见 [docs/CREDIT_AND_ADMISSION.md](docs/CREDIT_AND_ADMISSION.md)
了解外部服务合同和配置。
## 迁移说明（V2 声明执行）
- 可用的新安全 RPC：`CreateClaimV2` 和 `ExecuteClaimV2`。
- 旧版 `ExecuteClaim` (v1) 默认禁用，且仅能用 `EVIDENCEOS_ENABLE_INSECURE_V1=true`（或 `=1`）重新启用；当与 `EVIDENCEOS_PRODUCTION_MODE=1` 结合时，启动时硬失败。
- `topic_id` 现在应从 V2 元数据和主题信号由内核计算。
- CI 和本地验证通过 `./scripts/test_evidence.sh` 标准化，具有 95% 行覆盖率门控。
## 假设场景矩阵
| 场景 | 对抗性向量 | 机制 | 预期结果 | 证据链接 | 状态 |
|---|---|---|---|---|---|
| 确定性生命周期成功 | 有效声明通过完整生命周期 | ASPEC + 生命周期守卫 + ETL 包含/一致性/签名证明 | PASS | `scenarios_produce_deterministic_public_evidence` + `artifacts/scenarios/lifecycle_pass.json` | Live |
| 无效声明输入被拒绝 | 格式错误的创建请求（`oracle_num_symbols=1`，空名称） | gRPC 验证失败关闭 | REJECT | `scenarios_produce_deterministic_public_evidence` + `artifacts/scenarios/reject_invalid_claim.json` | Live |
| 针对仅 TLS 守进程的明文 | 传输降级尝试 | TLS 强制 | REJECT | `transport_hardening_system::tls_required_rejects_plaintext` | Live |
| 缺少 mTLS 客户端证书 | 未授权客户端身份 | mTLS authN | UNAUTHENTICATED | `transport_hardening_system::mtls_rejects_no_client_cert` | Live |
| 缺少 bearer 令牌 | 无授权 API 调用 | 请求拦截器 authN | UNAUTHENTICATED | `transport_hardening_system::auth_rejects_missing_token` | Live |
错误的 bearer 令牌 | 凭证猜测/重放 | 请求拦截器 authN | UNAUTHENTICATED | `auth.rs::tests::wrong_token_rejected` | Live |
| 超大解码有效载荷 | 输入放大 | `decode_with_max_size` 守卫 | RESOURCE_LIMIT | `fuzz_daemon_decode_limits` + auth decode unit tests | Experimental |
| 预密封执行尝试 | 生命周期绕过 | 声明状态机检查 | REJECT | `lifecycle_v2::cannot_execute_before_seal` | Live |
| ETL 包含篡改 | 伪造包含路径 | Merkle 包含验证器 | REJECT | `etl_verification_system::verifies_inclusion_consistency_and_sth_signature` | Live |
| ETL 一致性篡改 | 分叉树历史声明 | Merkle 一致性验证器 | REJECT | `etl_verification_system::verifies_inclusion_consistency_and_sth_signature` | Live |
| 密钥轮换历史验证 | 跨签名密钥更改的信任混淆 | key_id 索引密钥环查找 | PASS | `etl_verification_system::key_rotation_preserves_old_head_verification` | Live |
| 随机轮换序列 | 重复轮换+追加压力 | 历史密钥验证 + STH 签名检查 | PASS | `etl_verification_system::property_random_rotation_and_append_stays_verifiable` | Experimental |
### 如何复现场景证据
```
./scripts/run_scenarios.sh
cat artifacts/scenarios/summary.json
```
对于 CI 等效输出（覆盖率/模糊日志加场景工件）：
```
make test-evidence
```
## 外部策略 Oracle（超级法官）
EvidenceOS 支持运营商可以在不修改内核源代码的情况下部署的外部提供“超级法官”策略 Oracle。这些插件旨在用于第三方安全策略覆盖（例如，独立的 AI 安全公司），并被有意约束以保留内核安全和守恒保证。
策略 Oracle **仅限否决**：它们只能使结果更保守（`DEFER`/`REJECT`）。它们不能认证声明，也不能增加证据财富。特别是，Oracle 否决从不升级拒绝路径，而否决驱动的结果会限制结算行为，因此正向证据不是从策略干预中铸造的。
Oracle 作为不受信任的 Wasm 在确定性沙箱中运行：无导入、严格的燃料和内存限制、固定 ABI 导出，以及对任何陷阱、OOM、无效返回代码或格式错误模块的失败关闭行为。Oracle 输出通过构造是低带宽的（单个整数决策代码），回执被规范化并嵌入声明胶囊以供验证器审计。
守护进程从 `/policy-oracles/` 加载清单和 Wasm blob，验证固定的 `sha256` 哈希，强制执行清单模式/范围约束，并可选地针对 `trusted_keys.json` 验证 Ed25519 发布者签名。
最小策略 Oracle (WAT)：
```
(module
(memory (export "memory") 1)
(func (export "alloc") (param i32) (result i32) i32.const 0)
(func (export "policy_oracle_decide") (param i32 i32) (result i32)
i32.const 1)) ;; 1 = DeferToHeavy
```
示例清单：
```
{
"schema": "evidenceos.v1.policy_oracle_manifest",
"oracle_id": "acme.superjudge.v1",
"vendor": "Acme Safety",
"version": "1.0.0",
"description": "Conservative policy veto",
"wasm_filename": "acme_superjudge.wasm",
"wasm_sha256_hex": "",
"reason_code": 9001,
"decision_mode": "veto_only",
"max_fuel": 100000,
"max_memory_bytes": 65536,
"max_input_bytes": 4096,
"require_signature": false,
"signer_pubkey_ed25519_hex": null,
"signature_ed25519_hex": null
}
```
有关部署和 ABI 详细信息，请参见 `docs/ORACLE_PLUGINS.md`。UVP 参考：（模块 B：Oracle Resolution… §10.1–10.5）和 Canonical Realization §5.1。
## 自带 Oracle（WASM 包）
EvidenceOS 支持第三方 Oracle 插件，以便专业安全或合规公司可以发布法官而无需修改内核代码。
安全模型：
- 插件是不受信任的计算。
- 身份通过签名清单 + wasm 哈希固定。
- 执行在有界燃料/内存且无环境网络/fs/时间/rng 导入的确定性 wasm 沙箱中运行。
- 内核拥有规范实现字节、泄露收费和账本结算。
包布局：
- `oracles///manifest.json`
- `oracles///oracle.wasm`
- 可选校准 blob 和 README。
要配置受信任签名者，请传递 `--trusted-oracle-keys `，其中 JSON 将密钥 id 映射到 ed25519 公钥（十六进制）。将 `--oracle-dir` 设置为包根目录。守护进程在加载前验证签名、ABI、ASPEC 通道和哈希。
客户端仅引用 `oracle_id`；外部原始度量值从不作为协议输出公开。内核仅发出规范桶符号。
警告：Oracle++ 仅在远程+认证部署下有意义。本地插件仍受转录和账本控制约束，但主机妥协假设不同。
## Oracle++（远程认证 Oracle）
Oracle++ 是可选的，仅用于 **远程、不可绕过** 的 Oracle 部署。本地进程内克隆可以被复制或绕过，并且不提供 UVP 远程信任假设。
EvidenceOS 通过以下方式验证 Oracle++：
- 验证来自受信任机构的签名认证，
- 固定 Oracle 身份和测量的运行时哈希，
- 固定内核预期的 `OracleResolution` 哈希，
- 为重放/分叉保护强制执行签名单调序列号（`seq_no`），
- 强制执行规范 `bucket_bytes` 验证（`no hidden bits`）。
认证将测量的运行时状态和协议签名密钥材料绑定到声明的 Oracle 身份。仅当签名有效且计数器按每个 `(oracle_id, session_id)` 单调递增时，才接受查询回复。
Oracle++ **不** 替换账本控制。它补充了内核已强制执行的转录规范化、泄露记账（`k`）和结算控制。
## NullSpec 治理
EvidenceOS 现在在声明执行之前要求每个 `(oracle_id, holdout_handle)` 有一个活动的 NullSpec 合约。缺失、过期或分辨率哈希不匹配的 NullSpec 会失败关闭并发出事件记录。
### 非参数 e-process 选项
运营商可以选择离散桶上的非参数 `DirichletMultinomialMixture` e-process（来自校准计数），或在适用的地方保留参数化 Bernoulli/fixed-alt 合约。
参见 [docs/NULLSPEC.md](docs/NULLSPEC.md) 和 `evidenceosctl nullspec *` 命令。
示例合约字段：
```
{
"schema": "evidenceos.nullspec.v1",
"oracle_id": "settle",
"kind": {"DiscreteBuckets": {"p0": [0.25, 0.25, 0.25, 0.25]}},
"eprocess": {"DirichletMultinomialMixture": {"alpha": [1.0, 1.0, 1.0, 1.0]}}
}
```
## 结构化声明 + PhysHIR
EvidenceOS 支持具有确定性规范化的严格结构化声明模式：
- 类型化和有界字段（拒绝未知键和浮点数），
- 具有排序键的规范 JSON 编码，
- PhysHIR 单位解析和数量字段的 SI 维度检查。
### PhysHIR 的作用
结构化声明中的每个数量字段都带有一个物理维度签名 (PDS)：
[L]^a [M]^b [T]^c [I]^d [Θ]^e [N]^f [J]^g
其中每个括号是一个 SI 基本维度，每个指数是其幂：
| 符号 | 维度 | SI 基本单位 | 示例指数含义 |
|--------|---|---|---|
| [L] | 长度 | metre (m) | a=2 → 平方米 |
| [M] | 质量 | kilogram (kg) | b=1 → 千克 |
| [T] | 时间 | second (s) | c=-1 → 每秒 |
| [I] | 电流 | ampere (A) | d=1 → 安培 |
| [Θ] | 温度 | kelvin (K) | e=1 → 开尔文 |
| [N] | 物质的量 | mole (mol) | f=1 → 摩尔量 |
| [J] | 发光强度 | candela (cd) | g=1 → 坎德拉 |
提交声明时，内核：
1. 将数量字符串（"12.3 mmol/L"）解析为定点形式
2. 解析其 PDS 签名（对于摩尔浓度为 [L]^-3 [N]^1）
3. 根据模式声明的所需维度检查解析的 PDS
4. 如果维度不匹配则拒绝声明
### 这对泄露控制为何重要
没有 PDS，所有数字输出在维度上都是等效的。应用于“浓度查询”的主题预算可以通过将同一查询重新表述为比率或速率来绕过。PhysHIR 通过使内核具有维度感知来关闭这一点：泄露预算 可以限定于特定 PDS 签名。针对 [N]（摩尔量）的紧张预算不会被关于 [T]（时序）或 [L]（距离）的请求消耗。跨物理不相关维度的探测不会产生针对维度特定预算的信息优势。
### 示例（非敏感）
{
"schema_id": "cbrn-sc.v1",
"claim_id": "claim-001",
"event_time_unix": 1700000000,
"sensor_id": "sensor-a",
"location_id": "zone-1",
"measurement": "12.3 mmol/L",
"confidence_bps": 9800,
"reason_code": "WATCH"
}
字段说明：
- measurement：解析为定点，PDS 解析为 [L]^-3 [N]^1，在接受前根据模式检查
- confidence_bps：整数基点（0–10000），而非浮点数 — 避免规范化中的浮点非确定性
- event_time_unix：[T]^1，unix 纪元秒，仅整数
- reason_code：有界枚举，未知值在模式层被拒绝
标签：AI治理, DNS 反向解析, Python工具, Rust, Web报告查看器, 人工智能安全, 侧信道防护, 信息论, 可信执行, 可视化界面, 合规性, 基准测试防护, 子域名枚举, 审计日志, 形式化验证, 操作系统内核, 确定性计算, 系统安全, 网络流量审计, 胶囊化处理, 能力溢出控制, 自适应泄漏防护, 证据固定, 通用验证协议(UVP), 通知系统, 通知系统, 验证协议, 高可用架构