Assurance Evidence Plane：当 AI Agent 都声称自己合规，我们凭什么相信它们留下的证据？｜SEO / GEO 自动化治理（四十七）

核心主题： Assurance Evidence Plane / Event-Sourced Governance Ledger / Causal Event Graph / Tamper-evident Logging / Evidence Freshness / Evidence Completeness / Cross-System Reconciliation / Audit Integrity / Forensic Replay / Continuous Evidence Verification

研究日期： 2026 年 10 月 31 日

研究性质： 官方技术标准与原始资料核验、分布式系统工程分析、本项目原创 SEO/GEO 自治治理证据模型

系列定位： AI Agent 生产治理、SEO/GEO 工作自动化、运行时安全、证据链验证、审计完整性与可信自治

---

一家企业已经建立了完整的 AI Agent 自动发布系统。

Research Agent 负责信息研究，Fact Check Agent 负责事实核验，Editorial Agent 负责内容审批，Publisher Agent 负责将文章发布到 WordPress。

系统运行时还有多个保护机制。

Policy Engine 判断操作是否符合治理规则。

Authorization Service 检查执行主体的生产权限。

Runtime Assurance Monitor 识别当前状态是否处于 Safety Envelope 之内。

Effect Gateway 控制 WordPress 写入。

Effect Ledger 记录产生的外部效果。

从架构上看，系统似乎已经拥有充分的可观测性。

某天，Publisher Agent 发布了一篇工业设备采购指南。

自动化执行记录显示：

Policy Decision:
ALLOW

Authorization:
VALID

Runtime Assurance:
PASS

Publishing Gateway:
SUCCESS

WordPress:
201 Created

Workflow:
COMPLETED

所有步骤都显示成功。

但第二天，运营团队发现网站上的文章包含未经最终审核的技术内容。

进一步检查后，出现三个互相矛盾的记录。

Editorial System 声称最终批准的文章摘要：

Approved Artifact:
SHA256-A

Publisher Agent 声称自己执行的是：

Executed Artifact:
SHA256-A

但 WordPress 中实际保存的文章版本对应：

Observed Artifact:
SHA256-B

更令人困惑的是：

Publisher Agent 的运行日志没有记录内容替换。

WordPress 修订记录显示文章确实经历了一次修改。

GitHub 工作流日志却没有对应的内容更新任务。

系统的每个组件都能够拿出自己的日志。

Publisher 说：“我的执行记录是成功的。”

Policy Engine 说：“我确实返回过 ALLOW。”

WordPress 说：“文章确实被创建并修改过。”

但这些记录没有回答：

它们描述的是不是同一次操作、同一份内容、同一项授权以及同一个真实生产效果？

如果记录被修改，系统能否发现？

如果关键事件根本没写进日志，系统能否发现？

如果日志来自同一个已失陷服务，凭什么相信它们相互印证的结果？

这是第（四十七）篇要解决的问题。

此前我们研究：

如何阻止 AI Agent 执行不符合安全约束的操作。

现在继续研究：

如何独立验证系统声称已经执行了这些安全约束。

建立 Assurance Evidence Plane。

目标：Evidence-verifiable Autonomous Governance System。

一、为什么 Runtime Assurance 之后，还必须建立 Evidence Plane？

第（四十六）篇已经建立 Runtime Assurance Architecture。

Trusted Runtime Context
        ↓
Policy Decision
        ↓
Safety Envelope
        ↓
Protected Effect Gateway
        ↓
External Effect Verification

但这些检查的结果由谁记录？

记录在哪里？

谁有权修改？

执行记录与真实操作如何绑定？

证据来源故障时，原先的安全结论是否仍然成立？

例如：

Runtime Assurance = PASS

只是一条系统断言。

它并没有自动证明：

检查使用了最新 Policy。

检查针对实际发布的文章。

检查时拥有有效身份和权限。

结果没有在传输或保存中变化。

检查过程没有遗漏必要条件。

Runtime Assurance 产生的结论，本身也需要 Assurance。

这并非无限增加审计层级，而是建立相对独立、能够核验关键证据的控制面。

二、日志不等于证据：必须区分四个层次

第一层：Log Record。

2026-10-31 08:00:00
Publisher completed successfully.

它说明某系统记录了一句话。

第二层：Event Record。

{
  "event_type": "WORDPRESS_WRITE_ACCEPTED",
  "intent_id": "INT-047-001",
  "post_id": 1000101
}

结构化描述事件。

第三层：Verifiable Evidence。

除了内容，还具有可核验来源、完整性、时间条件、关联对象和签发依据。

第四层：Supported Assurance Claim。

例如：

本次文章正式发布使用有效审批，实际执行内容与批准内容一致，最终 WordPress 状态经过独立核验。

它是由多项证据支持的系统级结论。

Log Record
    ↓
Structured Event
    ↓
Verifiable Evidence
    ↓
Supported Assurance Claim

每一层都需要新增验证条件。

不是所有日志都能成为可信证据，也不是所有真实证据都足以支持最终安全结论。

三、真实性、完整性与真实陈述不能互相替代

假设 Agent 生成：

{
  "approval_status": "APPROVED",
  "content_verified": true,
  "publication_safe": true
}

系统可以计算 SHA-256，也可以为 JSON 签名。

这能在相应密码学假设与密钥管理条件下，帮助证明记录签名后没有发生未被检测的改变，签名与受信密钥存在关联。

但不能证明 JSON 中三个布尔值是真的。

如果 Agent 一开始就错误声明：

content_verified = true

签名只是保护了一条错误陈述。

Tamper-evident 不等于 Truthful。

Signed 不等于 Authorized。

Complete-looking 不等于 Complete。

Recorded 不等于 Observed。

这是 Assurance Evidence Plane 的第一原则。

四、Assurance Evidence Plane 要解决哪六种验证问题？

建议将可信证据分成六个维度。

签名有效的审批记录可能已经过期。

有效的发布指令可能没有对应 WordPress 结果。

WordPress 中存在的文章可能没有授权来源。

哈希链完整的日志可能从一开始就遗漏了非法写入。

所以不能只检查：

signature_valid == true

而应根据动作要求验证多项证据条件。

五、Event-Sourced Governance Ledger：为什么需要事件化治理记录？

传统系统往往只存当前状态：

Article Status = PUBLISHED

但争议发生时需要回答：

谁最初创建文章？

哪个版本通过 Fact Check？

哪个版本被批准？

谁请求发布？

Policy 为何返回 ALLOW？

WordPress 何时接受写入？

后续发生了哪些修改？

只保存最终状态无法完整回答。

Event Sourcing 是可借鉴的设计模式。

Microsoft Azure Architecture Center 说明 Event Sourcing 将状态变化保存为事件序列，通过事件流记录历史并允许重建状态。

官方资料：

https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

但 Event Sourcing 也增加并发、Schema 演进、查询和运维复杂度，并不适合所有系统。

因此本项目不建议立即改造整个平台。

优先对高风险治理动作建立 Event-Sourced Governance Ledger。

包括正式发布、修改、删除、权限授予、Policy 激活、Containment、Break-glass 和 Recovery。

六、Governance Ledger 不应只是 WordPress 发布记录表

传统表：

content_id
post_id
published_at
status

有运营价值，但只覆盖最终结果的一部分。

治理事件账本还应记录：

Intent Accepted
       ↓
Artifact Frozen
       ↓
Evidence Accepted
       ↓
Editorial Approved
       ↓
Authorization Issued
       ↓
Runtime Assurance Passed
       ↓
Effect Reserved
       ↓
WordPress Command Dispatched
       ↓
External Effect Observed
       ↓
Effect Independently Verified

这不要求每次生成大量人工审批表。

而是让受信组件在关键边界生成结构化事件和关联关系。

每项事件要回答：

发生什么、谁声明发生、依据什么、针对哪个对象、与此前哪些事件关联、可信程度怎样。

七、严格区分 Command、Decision、Event、Observation

PublishRequested

表示有人请求发布。

它不等于：

PublishAuthorized

表示受信授权机制允许发布。

授权又不等于：

PublishDispatched

请求已经发给 WordPress。

WordPress 返回成功，可记录：

WordPressWriteAcknowledged

但它仍不等于：

PublishedStateVerified

后者需要额外的外部状态核验。

不能把 PublishRequested 直接标记为 PUBLISHED。

也不能把 HTTP Request Sent 直接视为 Effect Confirmed。

事件语义清晰，是证据可信的前提。

八、如何定义统一的 Assurance Evidence Event？

建议使用版本化 Schema。

{
  "schema_version": "1.0.0",
  "event_id": "EV-047-0007",
  "event_type": "POLICY_DECISION_RECORDED",

  "intent_id": "INT-047-001",
  "workflow_id": "WF-047-001",

  "subject": {
    "workload_id": "seo-publisher"
  },

  "target": {
    "site_id": "SITE-A",
    "resource_type": "wordpress.post",
    "resource_id": "ARTICLE-047"
  },

  "action": "wordpress.publish",

  "artifact": {
    "digest_algorithm": "sha256",
    "digest": "<artifact-digest>"
  },

  "evidence_refs": [
    "EVD-047-001",
    "APP-047-001"
  ],

  "decision": "ALLOW",

  "policy": {
    "version": "POLICY-72"
  },

  "causation_event_id": "EV-047-0006",

  "event_time": "2026-10-31T00:00:00Z",
  "recorded_at": "2026-10-31T00:00:01Z",

  "integrity": {
    "record_digest": "<record-digest>",
    "signer_ref": "<trusted-signer-ref>"
  }
}

示例 ID、版本、时间仅用于解释。

subject.workload_id 必须由受信认证机制确定，不能直接相信客户端自填字段。

event_time 是声明的事件时间。

recorded_at 是证据系统接收或记录时间。

两者不应默认一致。

九、Causal Event Graph：时间顺序为什么不够？

假设：

08:00:00 Approval Issued
08:00:01 Publish Dispatched
08:00:02 WordPress Updated

时间顺序合理，却不能证明因果关系。

审批可能对应 Article A。

发布可能对应 Article B。

WordPress 更新可能来自人工管理员。

因此需要 Causal Event Graph，使用明确语义的关联，而不是时间接近性。

Approval(APP-001)
       │ authorizes
       ↓
PublishIntent(INT-001)
       │ evaluated_by
       ↓
PolicyDecision(DEC-001)
       │ permits
       ↓
EffectCommand(CMD-001)
       │ dispatched_as
       ↓
WordPressRequest(REQ-001)
       │ correlated_with
       ↓
ObservedPost(POST-001)
       │ verified_by
       ↓
Verification(VRF-001)

目标是让系统能沿着可核验的关系，从最终生产效果追溯到授权与审批。

十、W3C PROV：跨系统证据关系的标准化语义

W3C PROV 是本篇重要参照。

其数据模型围绕：

Entity、Activity、Agent

以及生成、使用、归属和派生关系展开。

PROV-O 使用 OWL 2 表达相关本体，支持异构系统交换 Provenance 信息。

官方资料：

https://www.w3.org/TR/prov-overview/

https://www.w3.org/TR/prov-o/

在 SEO/GEO 自动化中：

Article Artifact 可以视为 Entity。

Fact Check Process 可以视为 Activity。

Editorial Reviewer 可以视为 Agent。

Published WordPress Post 是另一个 Entity。

Article Artifact
      ↓ used by
Editorial Review Activity
      ↓ generated
Approval Evidence

Approved Artifact
      ↓ used by
Publishing Activity
      ↓ generated
Published Artifact

但是：

W3C PROV 负责表达 Provenance 关系，并不会自动验证所描述关系是否真实。

攻击者依然可能构造格式合法、内容虚假的 Provenance 图。

因此还需身份、签名、事件完整性和外部效果核验。

十一、Causal Graph 如何处理多个 Agent 与并发任务？

Multi-Agent Workflow 不一定是线性链。

Research Agent 同时执行多项资料研究，Fact Check 同时核对不同参数，Editorial 在证据全部满足后才批准。

Source A ─────┐
              │
Source B ─────┼──→ Fact Verification
              │
Source C ─────┘

随后：

Fact Verification ──┐
                     ├──→ Editorial Approval
Risk Assessment ────┘

所以 Causal Event Graph 应支持多父节点和显式依赖集合。

{
  "event_id": "EV-APPROVED",
  "depends_on": [
    "EV-FACT-CHECK-PASS",
    "EV-RISK-REVIEW-PASS",
    "EV-ARTIFACT-FROZEN"
  ]
}

这比单一 previous_event_id 适合描述分布式因果关系。

还应区分执行顺序、业务依赖、证据支持与授权关系。

它们并不一定相同。

Graph 中每条边必须具有明确语义，不能用“有关联”替代所有因果和授权关系。

十二、Trace ID 很有价值，但不能成为唯一因果依据

OpenTelemetry Trace Context 使用 Trace ID、Span ID 等关联分布式调用。

官方资料：

https://opentelemetry.io/docs/specs/otel/trace/api/

非常适合连接 Research Agent、Fact Check、Policy Engine、Publisher 和 WordPress Gateway。

但是：

Trace ID 本身不是可信授权。

它可能来自不可信输入，也不一定覆盖异步队列中的所有事件。

Same Trace ID

不能直接推出：

Same Authorized Intent

更不能推出：

Same Approved Artifact

建议分别保存：

Trace ID
Intent ID
Workflow ID
Artifact Digest
Approval ID
Decision ID
Effect ID

Trace ID 用于观测关联。

Intent ID 用于业务身份。

Artifact Digest 用于内容绑定。

Approval ID 指向批准证据。

Effect ID 对应外部效果。

这些对象可以形成证据图，但不能互相替代。

十三、Tamper-evident Logging：到底能够证明什么？

Tamper-evident Logging 不是绝对保证记录永远不能修改。

其目标是：

在明确的密码学、信任和存储条件下，已经形成的记录发生未授权修改后，验证过程能够发现。

例如日志：

EV-001
EV-002
EV-003

如果 EV-002 被改变，应能识别差异。

但同时必须考虑：

日志是否一开始就被伪造？

重要事件是否没有被记录？

签名密钥是否安全？

攻击者能否重建完整哈希链？

不同审计者是否看到了不同版本的历史？

这些问题不能只靠单次 SHA-256 计算解决。

十四、Hash Chain：如何检测日志中间内容发生改变？

一种简单模型是哈希链：

H0 = Trusted Genesis Digest

H1 = SHA256(H0 || Event1)

H2 = SHA256(H1 || Event2)

H3 = SHA256(H2 || Event3)

Event2 改变，后续摘要也改变。

但如果攻击者控制完整日志数据库，他可能修改 Event2 并重新计算 H2、H3。

如果没有独立保存受信 H3、相应签名或外部检查点，验证者可能无从知道原链已经被替换。

因此：

内部哈希链接本身不等于独立可信的防篡改证明。

还需要可信锚点、受保护的签名密钥、独立保存的检查点或其他可验证机制。

实际实现还应规定：

规范化序列化。

哈希算法版本。

字段排序。

编码方式。

日志流身份。

链起点和重置规则。

否则不同实现可能计算出不同 Digest。

十五、Merkle Tree：为什么需要包含证明和一致性证明？

对于不断增长的证据系统，可以使用 Merkle Tree。

Merkle Tree 将记录组织为哈希树，并用根哈希表达特定集合的完整性承诺。

IETF RFC 9162 定义 Certificate Transparency v2，包含：

Merkle Inclusion Proof：核验某记录属于指定 Tree Head 对应的日志。

Merkle Consistency Proof：核验两个树状态之间满足追加一致性。

官方资料：

https://www.rfc-editor.org/rfc/rfc9162.html

RFC 9162 属于 Certificate Transparency v2 的实验性协议规范，不是 SEO Agent 日志标准。

本项目可借鉴其 Merkle 机制，但不能因此声称直接得到完整的 Agent 审计可信保证。

十六、包含证明不等于事件完整性证明

假设 Ledger 包含：

EV-001
EV-002
EV-003
EV-004

EV-003 有有效 Inclusion Proof。

在对应密码学与检查点可信条件下，它支持证明 EV-003 属于该日志树。

但它不能证明：

所有应该记录的事件都已经存在。

假设真实生产发生：

Unauthorized WordPress Update

却绕过 Evidence Collector。

日志中从未有这件事。

Merkle Tree 仍可能保持一致，包含证明也完全有效。

Cryptographic Integrity 与 Event Completeness 是两种不同问题。

前者核验已记录数据，后者必须核验该出现的事件是否出现。

十七、Transparency Log 还要考虑分叉视图

RFC 9162 讨论 Misbehaving Logs，包括不同客户端看到不一致日志视图的风险。

因此签名有效也不能自动排除系统向不同验证者展示不同历史。

应考虑独立 Checkpoint、Consistency Proof、验证者之间的状态比较。

Sigstore Rekor 提供现实参照：通过透明日志记录软件供应链签名相关元数据，并支持查询、包含证明和日志审计。

官方资料：

https://docs.sigstore.dev/logging/overview/

Rekor 面向软件供应链透明性，不是开箱即用的 WordPress 授权、发布、修订和业务效果治理数据库。

本项目借鉴可验证日志思想。

十八、AWS CloudTrail：启用验证与真正执行验证是两回事

AWS CloudTrail Log File Integrity Validation 使用哈希和数字签名，为日志文件提供完整性验证依据。

启用此功能后，可以产生相关 Digest Files。

但 AWS 文档明确区分：

启用日志文件完整性验证，并不意味着已经执行日志文件完整性验证。

还必须实际运行验证过程。

官方资料：

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html

同理：

tamper_evident_logging_enabled = true

不能自动推出：

audit_integrity_verified = true

验证需要记录：

检查范围。

验证方法。

信任锚点。

校验结果。

失败明细。

证据时间。

验证主体。

安全功能已启用与安全性质已验证，是不同结论。

十九、Evidence Completeness：如何发现本应存在却缺失的事件？

假设 WordPress 当前有 100 篇新发布文章。

Effect Ledger 只有 98 条发布记录。

可能是两条日志丢失，也可能是人工直接发布、采集延迟或映射异常。

无论如何，都不能直接声明：

All Publications Verified

需要 Expected Event Inventory。

例如在给定时间窗口：

ObservedWordPressEffects

表示外部被观察到的受保护效果集合。

RecordedAuthorizedEffects

表示 Ledger 中可关联有效 Effect ID 的集合。

通过关联：

UnattributedEffects
=
ObservedWordPressEffects
-
MatchedAuthorizedEffects

集合差必须基于资源 ID、版本、动作和时间窗口，而不仅是计数。

两个集合数量相等，仍可能指向不同对象。

Evidence Completeness 应以真实业务对象与效果覆盖关系为依据，而不是日志总量。

二十、Evidence Completeness 不应依赖同一个生产者

假设 Publisher 自己记录：

Publish Started
Publish Authorized
Publish Completed

然后自行统计：

Evidence Completeness = 100%

如果 Publisher 漏记一次发布，它可能根本不知道缺失。

因此至少要有不同信任边界的数据源。

Publishing Gateway Ledger
          ↕
WordPress Posts State
          ↕
WordPress Revisions
          ↕
Deployment / Workflow Records
          ↕
Independent Observer

但这些来源不一定完全独立。

WordPress REST API 和 Revision API 仍依赖同一个 WordPress 系统。

它们是不同的数据视图，不构成两个完全独立的信任根。

所以完整性报告必须说明：

检查覆盖了哪些来源，这些来源之间有哪些共同失效风险。

二十一、Evidence Freshness：曾经正确的证据，为什么现在可能不再有效？

第（四十三）篇要求授权绑定当前 Safety Epoch，第（四十六）篇要求 Runtime Assurance 重新检查生产状态。

证据系统也必须遵守。

例如上午 09:00 文章获得批准，10:00 被修改，10:30 Publisher 发起正式发布。

审批记录未被篡改，签名也有效，但审批针对旧版本文章。

Approval Signature = VALID

不能推出：

Approval Applicable Now = TRUE

必须区分：

Evidence Integrity：记录没有发生未授权改变。

Evidence Freshness：满足当前动作所要求的时间、状态或版本条件。

Evidence Applicability：记录确实适用当前主体、资源、版本和动作。

缺一不可。

二十二、Evidence Freshness 不等于越新越可信

正式技术规范可能长期有效。

临时授权可能只有几分钟有效期。

不能统一使用：

max_age = 60 seconds

应按证据类型定义规则。

仅有：

EvidenceAge < TTL

也可能不足以支持授权。

时效性必须与证据所支持的具体 Claim 绑定。

二十三、时间戳不等于可信时间证明

Agent 可以写：

event_time = 2026-10-31T00:00:00Z

但这是自报时间。

应区分事件发生、记录、接收与验证的时间。

分布式节点时钟也存在偏差，不能仅凭两个时间戳大小确定严格因果顺序。

RFC 3161 定义 Time-Stamp Protocol，可通过可信时间戳服务为数据在某特定时间前已存在提供相关证据。

官方资料：

https://www.rfc-editor.org/rfc/rfc3161.html

但可信时间戳不能自动证明业务陈述真实，也不能证明实际外部效果已发生。

建议至少保留：

event_time
recorded_at
observed_at
verified_at

高风险场景再根据需要增加可信时间来源与验证结果。

二十四、Audit Integrity：审计系统自身需要权限约束

若 Publisher 可以同时：

发布文章。

修改发布日志。

删除异常记录。

替换审批证据。

修改审计配置。

就可能影响审计结论。

因此第（四十四）篇的 Separation of Duties 应用于 Evidence Plane。

Evidence Producer 生成事件。

Evidence Collector 接收、验证、保存事件。

Evidence Verifier 独立验证证据。

Evidence Administrator 维护基础设施，但不应不受约束地修改历史证据。

Governance Auditor 检查证据是否足以支持系统结论。

NIST SP 800-92 提供日志管理指导，NIST SP 800-53 包含 Audit and Accountability 等控制，OWASP Logging Cheat Sheet 讨论日志源可信性、敏感信息、日志保护和机制测试。

官方资料：

https://csrc.nist.gov/pubs/sp/800/92/final

https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

上述是安全工程参照。这里的角色分工是项目设计，不是这些规范已统一定义的 Agent 角色。

二十五、不能把所有敏感数据写入 Evidence Ledger

证据越多不总意味着治理越好。

不应为证明 WordPress 操作经过授权，把以下内容直接写进日志：

WordPress Application Password。

Access Token。

Secret Key。

完整登录 Cookie。

不必要的个人信息。

OWASP Logging Cheat Sheet 对敏感信息有明确指导。

建议优先保存：

受控身份引用。

证据 ID。

Artifact Digest。

授权决策。

必要资源标识。

签名。

可信来源引用。

配合数据最小化、日志访问控制、加密、保留期限、脱敏和日志注入防护。

Hash 不等于匿名化。

可枚举敏感数据的简单哈希仍可能被反推或推断。

Evidence Ledger 应尽可能证明操作，而不是复制业务秘密。

二十六、Cross-System Reconciliation：真正要对账什么？

WordPress 发布至少要比较三个状态。

Desired State：批准的生产目标。

POST_STATUS = publish

EXPECTED_SLUG = article-047

APPROVED_DIGEST = SHA256-A

Command State：向 WordPress 实际发送的请求。

Effect ID = EFF-047

Submitted Digest = SHA256-A

Observed State：从 WordPress 独立读取的实际状态。

POST_ID = 1000102

STATUS = publish

OBSERVED_DIGEST = SHA256-B

如果 Approved Digest 与 Observed Digest 不一致，不能立即断言恶意篡改。

可能是内容规范化方法不同、WordPress HTML 处理、短代码、区块渲染、插件过滤，或真实的未经授权修改。

但可以明确：

现有证据不足以证明发布效果与批准 Artifact 一致。

需要进入：

EVIDENCE_INCONSISTENT

进一步核验。

二十七、WordPress Revisions 能提供什么，不能提供什么？

WordPress REST API 提供 Posts 与 Post Revisions 资源。

官方资料：

https://developer.wordpress.org/rest-api/reference/posts/

https://developer.wordpress.org/rest-api/reference/post-revisions/

可以检查：

当前 Post ID。

发布状态。

更新时间。

部分内容字段。

历史修订。

但 Revisions 不能自动视为完整授权审计。

它可能记录内容变化，却不一定包含：

Agent Intent。

Policy Decision ID。

Approval Digest。

Safety Epoch。

Governance Quorum。

所以：

WordPress Revisions 提供内容变化信息，不直接替代治理授权证据。

需结合 Effect ID、Post ID、Revision ID、Artifact Digest 与时间窗口进行关联。

还要考虑 WordPress 权限、修订保留配置与插件行为。

二十八、跨系统对账至少识别六种异常

Missing Authorization：真实 Effect 存在，缺少有效授权。

Missing Effect：已批准、已派发的操作，却找不到外部效果。

Artifact Mismatch：实际版本与批准版本不同。

Duplicate Effect：同一 Intent 产生未经允许的重复效果。

Unattributed Modification：WordPress 出现更新，无法关联合法的受保护操作或已登记人工修改。

Evidence Gap：业务操作和结果可观察，但必要中间证据缺失。

不同异常应有不同处置。

Missing Effect 不一定表示必须重试创建，也可能是外部系统已接受操作、观察暂时不可用。

Evidence Gap 应触发核验，不能自动变成补发生产指令。

二十九、Effect Unknown：外部结果不确定时怎么办？

Cloudflare Queues 默认采用至少一次投递。

WordPress REST API 也不能简单视为原生提供业务 Intent 级严格幂等事务。

因此可能出现：

Command Dispatched
       ↓
WordPress Created Post
       ↓
Network Response Lost
       ↓
Effect State Unknown

此时重新创建可能产生重复。

Evidence Plane 应先记录：

EFFECT_OUTCOME_UNKNOWN

随后根据 Effect ID、Intent ID、目标 Post、请求 Digest、WordPress 当前状态以及必要修订和审计记录执行 Reconciliation。

取得足够证据后，再判断是否重新派发、更新已有资源或升级人工处置。

对应第（四十六）篇：

Unknown External Effect → Reconcile Before Retry。

三十、Independent Verification：验证者为什么不能完全依赖被验证者？

Publisher 写入：

Effect = SUCCESS

再由同一个 Publisher 自己判断：

Evidence = VERIFIED

表面有两个结论，但如果都来自同一不可信判断，就没有新增独立证据。

建议 Evidence Verifier 与业务执行主体有明确的信任边界。

Publisher 提交 Effect ID。

Verifier 使用独立只读凭据读取 WordPress。

Verifier 从受信 Evidence Store 获取批准 Artifact 摘要。

Verifier 核对 Post 内容与状态。

Verifier 生成自己的核验结果。

不一定非要使用另一家云厂商。

重点是它能否独立获得证据、独立验证事实、不会仅仅复述 Publisher 声明。

独立验证来自独立的证据获取与判断，不只是名称不同。

三十一、Continuous Evidence Verification：不能只在发布完成时检查一次

发布后仍可能发生变化。

WordPress 管理员修改正文。

插件更新内容。

自动化任务覆盖 SEO Meta。

页面被设置为 noindex。

某条 Redirect 被调整。

所以 Evidence Verification 应覆盖生命周期：

Pre-effect Verification
          ↓
Effect-time Evidence
          ↓
Post-effect Verification
          ↓
Periodic State Reconciliation
          ↓
Drift Detection
          ↓
Governance Review

但检测到新状态并不自动意味着过去的记录失效。

文章经过合法更新后，当前内容自然可能与发布当日不同。

应通过版本链确认每一次合法变化，核验当前状态能否从已经登记的操作历史合理解释：

Observed Current State
          ↑
Authorized State Transitions

不能要求所有页面永远保留最初的内容 Digest。

三十二、Forensic Replay：重放证据与状态，而不是重新执行生产

事故发生后，企业需要知道：

错误文章如何发布？

哪个 Agent 发起修改？

Policy 当时为何允许？

是否存在越权？

WordPress 错误内容来自哪次操作？

这需要 Forensic Replay。

在本项目中，它首先指：

利用事件记录和证据，重建某段时间内的状态变化与决策过程。

不是再次向 WordPress 执行原来的写入。

Replay:
Approval Issued
      ↓
Policy ALLOW
      ↓
Effect Reserved
      ↓
WordPress Write Dispatched
      ↓
Observed State

取证重放过程中应保持：

Production Writes = DISABLED

除非另行发起经过授权的 Recovery Procedure。

否则为了调查事故，可能再次制造相同的错误效果。

三十三、Forensic Replay 必须保存历史规则版本

假设事故发生时：

Policy Version = 71

现在运行：

Policy Version = 75

用当前 Policy 重新评估历史请求，可能得到不同结果。

当时：

ALLOW

现在：

DENY

这不必然意味着历史记录被篡改，可能只是规则真的改变。

因此应区分：

Historical Decision Reconstruction：使用当时的 Policy、身份、资源与运行上下文解释历史决定。

Current Policy Evaluation：用当前规则判断相同请求今天是否允许。

不能混用。

历史验证应保留 Policy Bundle Digest、Runtime Contract Version、Artifact Digest、Authorization Record、Safety Epoch、Governance Root Version 和必要环境假设。

没有版本化治理证据，就无法可靠解释历史治理决策。

三十四、Evidence Ledger 本身失陷时怎样恢复？

第（四十四）篇提出 Governance Recovery，第（四十六）篇提出 Runtime Recovery。

现在需要 Evidence Plane Recovery。

假设 Ledger 遭到攻击：

部分记录被删除。

签名密钥疑似泄露。

某个检查点与独立保存的状态不一致。

不能只执行：

Restore Database Backup

然后宣布：

Evidence Integrity = PASS

因为备份也可能受到影响。

完整恢复应：

冻结受影响的证据写入路径。

隔离疑似失陷的签发身份。

验证独立 Checkpoint。

核验可信历史范围。

识别缺失或不一致的事件。

对比 WordPress 等外部状态。

评估受影响的治理决定。

轮换必要密钥和权限。

建立新的可信日志链与验证边界。

形成 Recovery Attestation。

关键是：

恢复后明确哪些历史证据仍然可信，哪些只能标记为 Unknown。

不能为了 Dashboard 变绿而抹除证据缺口。

三十五、Evidence Verification 需要明确失败语义

证据系统不应只返回 PASS 或 FAIL。

建议至少区分：

例如 WordPress API 暂时不可用，不等于一定 COMPROMISED，更可能是 UNVERIFIABLE。

但对高风险新写入：

UNVERIFIABLE

也不应该被默认为：

ALLOW

需要区分：

证据状态判断 与 业务授权决定。

前者描述我们知道什么，后者决定现在可以做什么。

三十六、建立 Evidence Verification Manifest

每次重要验证应生成版本化 Evidence Verification Manifest。

verification_id: EVM-047-001

subject:
  type: wordpress.publish
  intent_id: INT-047-001
  effect_id: EFF-047-001

scope:
  site_id: SITE-A
  article_id: ARTICLE-047

required_evidence:
  - artifact_approval
  - policy_decision
  - authorization
  - runtime_assurance
  - effect_command
  - external_observation

integrity:
  hash_chain_check: REQUIRED
  checkpoint_check: REQUIRED
  source_identity_check: REQUIRED

causality:
  intent_binding: REQUIRED
  artifact_binding: REQUIRED
  authorization_binding: REQUIRED

external_reconciliation:
  wordpress_post_state: REQUIRED
  content_version_match: REQUIRED

result:
  status: NOT_YET_EXECUTED

limitations:
  - external_source_availability
  - configured_revision_retention

这里明确使用 NOT_YET_EXECUTED，因为只是待实施 Schema，不是真实执行结果。

实际执行后，应记录：

Verifier 身份。

验证程序版本。

使用的信任锚点。

检查范围。

验证时间。

发现的缺口。

结果证据引用。

必要时对验证结果签名。

Verification Manifest 应成为相对独立的证据，不是 Publisher Agent 的自我复述。

三十七、如何落实到现有 SEO Publisher？

对于 WordPress + Cloudflare Worker + GitHub Actions 环境，不需要立即建设大型 Provenance Graph Platform。

从高风险 WordPress Effect 开始。

第一阶段：统一业务标识

建立：

Intent ID
Artifact ID
Artifact Digest
Approval ID
Policy Decision ID
Effect ID
WordPress Post ID

明确定义生成、绑定和验证规则，避免多个 Agent 各自构造同一个业务 Intent 的不同标识。

第二阶段：建立最小事件账本

记录：

INTENT_ACCEPTED
ARTIFACT_APPROVED
POLICY_ALLOWED
EFFECT_RESERVED
EFFECT_DISPATCHED
WORDPRESS_OBSERVED
EFFECT_VERIFIED

关键事件应由适合的受信组件生成，而非全部由 Publisher 自行声明。

第三阶段：增加 Evidence Gap 检测

正式发布要关联：

有效批准。

当前内容 Digest。

允许决策。

Effect ID。

真实 WordPress Post ID。

独立回读结果。

缺少必要证据，不得标记完全 VERIFIED。

第四阶段：跨系统对账

定期核对 Effect Ledger、WordPress Posts、WordPress Revisions、必要的 GitHub / Worker 执行记录。

无法解释的生产变更登记为：

UNATTRIBUTED_EFFECT

第五阶段：防篡改可检测能力

对关键事件进行规范化、摘要、签名、追加式存储，以及独立 Checkpoint 备份。

但不能因为用了哈希数据库，就声称绝对不可篡改。

第六阶段：独立 Evidence Verification

将结果写入 Governance Dashboard。

发布状态从：

PUBLISHED

进一步区分：

PUBLISHED
+
EFFECT_VERIFIED
+
EVIDENCE_VERIFIED

各状态可一起展示，但含义必须不同。

三十八、Evidence Plane 不应取代运营数据体系

SEO/GEO 自动化已有 GSC、GA4、Looker Studio、技术 SEO 监测、GEO Citation Tracking 和内容质量审核。

Evidence Plane 不应该把这些全部重建。

GSC 能帮助判断页面的搜索表现。

GA4 能分析用户访问和转化。

它们不能直接证明某次 WordPress 写入使用了有效的 Approval Digest。

Evidence Ledger 能支持证明发布遵守指定治理流程，但不能证明文章会获得 Google 排名。

必须维持：

Governance Evidence
       ↓
Production State
       ↓
Search Visibility
       ↓
User Behavior
       ↓
Business Outcome

治理证据回答系统是否按受控程序执行；业务分析回答执行后产生了什么效果。

两者关联但不能混淆。

三十九、如何监测 Evidence Plane 健康？

建议指标：

最重要的不是：

Evidence Records Generated

日志数量越多，不等于可信程度越高。

真正要问：

关键生产效果能否被完整、独立、可重复地解释。

四十、Game Day：让 Evidence Plane 主动接受故障

场景一：删除中间事件。

检查能否识别缺口或完整性异常。

场景二：修改已签名记录。

检查摘要和签名验证能否识别。

场景三：生成签名有效但内容虚假的声明。

检查是否仍要求独立业务事实核验。

场景四：WordPress 有文章，但 Ledger 没有 Effect ID。

检查是否触发 Unattributed Effect 调查。

场景五：WordPress 操作成功，但日志延迟到达。

检查是否能够区分延迟与确定性缺失。

场景六：两个不同 Artifact 共享同一 Intent。

检查绑定关系是否被拒绝或进入异常处置。

场景七：Log Collector 不可用。

检查高风险操作是否按策略阻断、暂存或进入受控恢复。

场景八：Verifier 与生产使用不同历史 Policy。

检查能否发现版本不一致，而不是得出错误历史判断。

演练必须在测试环境或可控范围执行。

证据系统不仅应展示正常记录，还必须能够发现缺失、伪造、冲突和不可验证状态。

四十一、十五条 Assurance Evidence Invariants

Invariant 1

Log Exists
≠
Event Truth Established

Invariant 2

Cryptographic Integrity
≠
Evidence Completeness

Invariant 3

Signed Claim
≠
Verified Business Fact

Invariant 4

Every Protected Effect
must have an attributable Intent.

Invariant 5

Every Authorized Effect
must bind to the approved Artifact.

Invariant 6

Policy Decision
must bind to the actual protected action.

Invariant 7

Trace ID
must not substitute for authorization.

Invariant 8

Evidence Freshness
must be evaluated for its intended use.

Invariant 9

Missing Evidence
must not silently become PASS.

Invariant 10

Unknown External Effect
requires reconciliation.

Invariant 11

Historical Decision Verification
requires applicable historical policy.

Invariant 12

Tamper-evident Logging
requires independently verifiable trust anchors.

Invariant 13

Evidence Producer
must not be the sole authority
for verifying its own critical claims.

Invariant 14

Forensic Replay
must not repeat production effects.

Invariant 15

Unattributed Production Effect
→
Governance Investigation

这些约束共同说明：

系统不仅要生成执行证据，还要验证其来源、完整性、适用性、因果关系以及与真实外部效果的一致性。

---

结语：可信自治系统不是拥有更多日志，而是能独立解释每一次生产效果

回顾最近的推进。

第（四十二）篇研究为什么多个 Agent 局部正确仍不足以证明整个工作流正确。

第（四十三）篇让治理规则成为机器可执行的生产控制。

第（四十四）篇约束谁有权制定、修改和紧急绕过规则。

第（四十五）篇引入形式化方法，寻找策略组合和状态转换的危险路径。

第（四十六）篇将经过验证的约束推入真实生产执行环境。

但直到第（四十七）篇，我们才进一步面对：

如果系统声称已经遵守所有约束，凭什么相信这些声明？

Policy Engine 可以输出 ALLOW。

Runtime Monitor 可以输出 SAFE。

Publisher 可以输出 SUCCESS。

WordPress 可以返回 201 Created。

但这些信息各自成立，并不自动形成可信的授权与执行证据链。

真正需要的是：

Policy Decision
       ↓
Authorization Evidence
       ↓
Runtime Assurance Decision
       ↓
Effect Command
       ↓
External Effect
       ↓
Observed State
       ↓
Causal Evidence Graph
       ↓
Independent Verification

这条链必须回答：

谁发起操作？

谁批准？

批准的是哪份 Artifact？

使用哪版 Policy？

操作发生时授权是否有效？

执行的实际内容是什么？

WordPress 最终产生何种效果？

证据是否完整？

证据是否仍适用？

是否存在无法解释的状态差异？

任何环节缺失，系统都不能用一句：

Everything Passed

掩盖未知事实。

更不能把：

No Error Reported

理解为：

No Governance Violation

因此成熟 Agent Governance 必须从单纯 Runtime Monitoring 进入 Evidence Verification。

它不仅记录发生了什么，还要核验证据是否支持系统对自身行为的声明。

Trusted Source Identity
          ↓
Structured Governance Events
          ↓
Versioned Evidence Artifacts
          ↓
Tamper-evident Ledger
          ↓
Causal Event Graph
          ↓
Evidence Completeness Check
          ↓
Cross-System Reconciliation
          ↓
Independent Verification
          ↓
Continuous Governance Assurance

这是 Assurance Evidence Plane for SEO/GEO Autonomous Systems。

从 Continuously Monitored and Runtime-Enforced Autonomous System 继续推进到：

Evidence-verifiable Autonomous Governance System。

A trustworthy autonomous system must not only enforce its rules. It must preserve independently verifiable evidence that the intended controls governed the actual production effects.

可信自治系统不仅要执行治理规则，还必须保留可独立验证的证据，证明这些规则确实约束了真实生产效果。

---

官方技术依据与研究边界

1. W3C PROV — Provenance Model 与 PROV-O

W3C PROV 为 Entity、Activity、Agent 及其来源关系提供模型与语义。

它可支持跨 Agent Causal Evidence Graph 的来源表达，却不会自动核实业务陈述真实。

https://www.w3.org/TR/prov-overview/

https://www.w3.org/TR/prov-o/

2. IETF RFC 9162 — Certificate Transparency Version 2.0

RFC 9162 讨论 Merkle Inclusion Proof、Consistency Proof 与日志审计机制。它是 Certificate Transparency v2 实验性协议，不是 Agent Governance 标准。

https://www.rfc-editor.org/rfc/rfc9162.html

3. Sigstore Rekor — Transparency Logging

Rekor 提供软件供应链透明日志与相关核验机制。本文借鉴可验证日志思想，不将其当成完整业务治理数据库。

https://docs.sigstore.dev/logging/overview/

4. AWS CloudTrail — Log File Integrity Validation

CloudTrail 使用摘要文件、哈希与数字签名提供日志完整性验证，并区分功能启用与实际验证。

https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html

5. NIST SP 800-92 — Guide to Computer Security Log Management

为企业日志管理基础设施与流程提供安全工程指导。

https://csrc.nist.gov/pubs/sp/800/92/final

6. NIST SP 800-53 — Security and Privacy Controls

包含 Audit and Accountability 等相关控制，可用于审计、权限与证据保护参考。

https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

7. OWASP — Logging Cheat Sheet

包含日志源可信性、日志保护、敏感信息和日志注入等实践指导。

https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

8. Microsoft Azure — Event Sourcing Pattern

描述将状态变化保存为事件序列的架构模式及其权衡。

https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourcing

9. WordPress — Posts 与 Post Revisions REST API

可读取文章及修订相关状态，但不自动包含完整 Agent 授权审计。

https://developer.wordpress.org/rest-api/reference/posts/

https://developer.wordpress.org/rest-api/reference/post-revisions/

10. OpenTelemetry — Tracing API

提供分布式 Trace Context 及关联能力，不能替代授权与身份验证。

https://opentelemetry.io/docs/specs/otel/trace/api/

11. IETF RFC 3161 — Time-Stamp Protocol

可信时间戳可为数据在指定时间之前已存在提供相关证据，不等于业务事实证明。

https://www.rfc-editor.org/rfc/rfc3161.html

本项目原创工程设计

以下为本项目对上述标准和工程思想的组合性设计：

• Assurance Evidence Plane
• Event-Sourced Governance Ledger
• Causal Event Graph for AI Agent Governance
• Assurance Evidence Event Schema
• Evidence Completeness Verification
• Evidence Freshness and Applicability Model
• Cross-System Effect Reconciliation
• Independent Evidence Verifier
• Evidence Verification Manifest
• Evidence Plane Recovery
• Counterexample-driven Evidence Game Day
• Continuous Evidence Verification
• Evidence-verifiable Autonomous Governance System

这些机制适合进一步落实到 WordPress、Cloudflare Worker、GitHub Actions、Governance Ledger、Evidence Registry 和自动审计系统，但不应被描述成 W3C、NIST、IETF、AWS、Sigstore、Microsoft 或 WordPress 统一发布的 Agent 证据治理标准。

---

第（四十八）篇预告：Assurance Case Automation——如何证明证据足以支持系统的安全结论？

第（四十七）篇解决：

如何验证关键运行时证据的来源、完整性、适用性、因果关系和外部效果对应关系？

但接下来：

即使所有证据都是真的，也不代表这些证据足以支持某个系统级安全结论。

Policy Decision 真实。

Authorization Record 真实。

WordPress Effect 真实。

Runtime Attestation 真实。

但是系统仍可能遗漏某次权限撤销、未建模的执行路径，或者关键安全约束。

所以第（四十八）篇建议进入：

Assurance Case Automation / Claim–Argument–Evidence / Goal Structuring Notation / Evidence Sufficiency / Assurance Argument / Defeasible Reasoning / Assumption Tracking / Confidence Assessment / Continuous Assurance Case / Evidence-driven Governance Decision

Governance Claim
        ↓
Explicit Assumptions
        ↓
Assurance Argument
        ↓
Required Evidence
        ↓
Evidence Sufficiency Check
        ↓
Counterargument / Defeater Analysis
        ↓
Independent Review
        ↓
Continuous Assurance Case

从 证据本身是否可信 进一步推进到：

证据是否足以证明整个自治系统的关键安全主张？

目标：Evidence-backed and Argument-verified Autonomous Governance System。