vpp-ai-platform/docs/03-safety-chain.md
stewart hu 11f19a661a Integrate peer review findings into architecture docs
- 01: add eight testable hard invariants (self-approval ban, duty
  separation, digest-bound approvals, permit-only effects, LLM-less
  degraded operation)
- 03: approval staleness model — proposal digest, FRESH_CHECK/STALE
  states, APPROVED→AUTHORIZED split with revocable ExecutionPermit;
  gateways accept permits, never bare plans
- 05: rules packaged as versioned, testable Policy Packs pinned in
  proposal lineage
- 02: approval workbench reshaped into a Case Desk (DecisionCase as
  the operator's accountability unit)
- 10 (new): cross-province federation boundary — signed artifacts
  only, plus three phase-1 no-rework reservations
- 08: add M5 shadow-run milestone as phase-1 acceptance form
- 00/04/07: object table, doc map, and walkthrough consistency updates
- add brainstorming.md (peer review source document)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019u5SLNweVio6ozJX7yfxQr

🔮 View transcript: https://logs.lojong.info/s/e8u90k3t33w590r7b5y7yzqh
2026-09-01 20:44:12 -04:00

157 lines
8.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 03 · 可信执行链:Proposal 状态机与包络自治
可信执行链是认知平面与控制平面之间唯一的通道,也是本平台在等保与调度合规语境下的
「真正产品」——评审与验收看的就是这条链的完整性与留痕。
## 1. Proposal 对象
一切拟执行动作(市场申报、用户邀约、控制计划、调度方案)统一为 Proposal:
```yaml
Proposal:
id: string # 全局唯一
type: BID | INVITATION | CONTROL_PLAN | DISPATCH_PLAN
timescale: ANNUAL | MONTHLY | DAY_AHEAD | INTRADAY | REALTIME
originator:
agent: string # 发起 Agent
trigger: MANUAL | EVENT | SCHEDULED
task_id: string
payload: object # 类型化载荷(申报曲线 / 邀约清单 / 控制设定值序列)
lineage: # 血缘(P5)
tool_calls: # 每个数字的来源
- {tool: string, version: string, inputs_ref: string, outputs_ref: string}
data_refs: [string] # 引用的数据快照
ledger_version: string # 读取的持仓账本版本
envelope_ref: string | null # 命中的包络(null = 必走人工)
digest: string # 载荷 + 血缘的不可变内容摘要(审批与许可的绑定对象)
status: <状态机,见 §2>
audit: [...] # 状态迁移全记录:时间、执行者(系统/人)、依据
```
**硬约束**:`payload` 中任何数值字段必须能在 `lineage.tool_calls` 中找到来源(P2 的机器可校验形式,规则校核阶段强制检查)。
## 2. 状态机
```mermaid
stateDiagram-v2
[*] --> DRAFT: Agent 生成
DRAFT --> RULE_CHECK: 提交
RULE_CHECK --> REJECTED: 规则不通过
RULE_CHECK --> SIMULATION: 通过
SIMULATION --> PENDING_HUMAN: 仿真告警(一票升级)
SIMULATION --> ENVELOPE_CHECK: 仿真通过
ENVELOPE_CHECK --> AUTO_APPROVED: 包络内
ENVELOPE_CHECK --> PENDING_HUMAN: 包络外 / 无包络
PENDING_HUMAN --> APPROVED: 人工批准(可多级)
PENDING_HUMAN --> REJECTED: 人工驳回
AUTO_APPROVED --> FRESH_CHECK: 执行前现势复核
APPROVED --> FRESH_CHECK: 执行前现势复核
FRESH_CHECK --> AUTHORIZED: 复核通过,签发 ExecutionPermit
FRESH_CHECK --> STALE: 实质状态已变化,审批失效
STALE --> RULE_CHECK: 重新走链(视变化幅度沿用或重批)
AUTHORIZED --> RELEASED: 网关凭许可受理
RELEASED --> EXECUTING: 控制平面 / 外部接口受理
EXECUTING --> COMPLETED: 执行完成,反馈回传
EXECUTING --> ROLLED_BACK: 异常触发回退
REJECTED --> [*]
COMPLETED --> [*]: ExecutionReport → 复盘
ROLLED_BACK --> [*]: 异常报告 → 复盘 + 告警
```
要点:
- **规则校核**(确定性规则引擎):合规性(交易规则、申报格式)、约束校验(资源约束、合同边界、账本一致性)、权限校验(发起 Agent 是否有权发起该类型)、血缘完整性;
- **仿真验证**:按类型选择——申报类走收益/风险情景回测,控制类走功率平衡/潮流仿真;仿真告警**一票升级**人工,没有例外;
- **权限校验**(规则校核内含,落实 I1/I2):审批人不得出现在该 Proposal 的发起链路中;AI 无任何通往「批准」迁移的路径;
- **实现形态**:持久化工作流(durable workflow)。审批可能悬挂数小时,状态机必须可恢复、超时可配(如申报截止前 30 分钟未批自动升级告警)。
### 2.1 审批绑定与失效(Staleness,落实 I3)
审批的对象不是「这个 Proposal」,而是「**这个摘要版本**的 Proposal 在**这个窗口内**生效」:
```yaml
Approval:
proposal_digest: string # 绑定不可变摘要——载荷任何改动即另一次审批
approver: {id, role} # 来自既有权限系统(I2 职责分离)
scope: {effect_type, limits} # 批准的效果范围与金额/电量上限
validity: {from, to} # 有效窗口
evidence_versions: # 审批时所依据的证据版本
policy_pack: string
ledger_version: string
data_snapshot_refs: [...]
```
**失效条件**:有效窗口过期;或依据的实质证据发生变化(引用资源离线、账本持仓变动、
政策包升版、遥测显著偏离审批时快照)。失效检测由执行前**现势复核(FRESH_CHECK)**承担。
### 2.2 授权与执行许可(AUTHORIZED / ExecutionPermit,落实 I4)
人工/自动批准 ≠ 可以执行。批准与执行之间可能相隔数小时,物理世界会变。
下发前由授权环节做**现势复核**:重跑关键校验(资源在线、约束仍满足、审批未失效),
通过后签发执行许可:
```yaml
ExecutionPermit:
proposal_digest: string # 与批准的摘要一致
issued_at / expires_at: ts # 短时效(如控制类分钟级、申报类至截止时刻)
effect_limits: {...} # 从 Approval.scope 继承收窄
revocable: true # 可吊销(吊销 = 网关拒收 + 边缘回退策略)
```
**网关只认许可,不认计划**:交易平台适配器与执行引擎的受理入口只接受
`(Proposal, ExecutionPermit)` 且验证摘要一致、许可未过期未吊销。
即使一个已批准的计划被泄露或重放,没有有效许可也无法产生外部效果。
*典型场景*:08:30 申报获批 → 09:00 某 10 MW 储能站离线 → 09:30 适配器请求许可
→ 现势复核发现核定容量已失效 → STALE,回到规则校核重走(容量核减后的新摘要需重批或落在包络内自动通过)。
## 3. 包络(Envelope)模型
```yaml
Envelope:
id: string
scope:
proposal_type: BID | INVITATION | CONTROL_PLAN | DISPATCH_PLAN
timescale: [...]
resource_set: string # 适用资源/用户集(引用资源池分组)
bounds: # 按类型定义,示例:
# BID: 价格 ∈ [p_min, p_max],电量 ∈ [q_min, q_max],持仓偏离 ≤ x%
# CONTROL: 单用户削减 ≤ 合同可中断容量,总削减 ≤ y MW,时段 ∈ 允许窗口
# INVITATION: 仅限已签自动邀约协议用户群,激励单价 ≤ z
validity: {from, to} # 有效期,到期必须重新审批
approval:
level: L1 | L2 | L3 # 包络本身的审批级别(多级审批)
approved_by: [...]
escalation: # 收缩条件
- 连续 N 次包络内执行偏差超阈 → 包络自动挂起,回归人工
- 复盘 ReviewFinding 建议收缩 → 触发重审
```
### 3.1 自治拨盘(运营节奏)
| 阶段 | 包络状态 | 效果 |
|---|---|---|
| 上线初期 | 空集 | 一切 Proposal 走人工,等价传统模式 |
| 试运行 | 窄包络(如申报价格 ±5% 于预测基准) | 常规日自动,波动日人工 |
| 成熟运行 | 按复盘数据逐步放宽 | 人工只处理异常与包络续批 |
包络的扩与缩都由复盘数据驱动并留痕——「自主决策」能力的增长是可审计的。
## 4. 异常回退
- **许可吊销**是最高优先级的回退手段:吊销后网关立即拒收后续指令,
边缘终端按断连策略退回上一批准计划或安全曲线(04 篇 §3);
- 执行中任何环节异常(校核失败、执行偏差超阈、通道故障)→ 回退至 Runtime 安全控制:
控制类回退到上一批准计划或安全停机曲线(边缘终端本地持有,见 04 篇);
申报类在截止前可撤单重报,截止后转入偏差管理流程。
- 回退动作本身也是留痕事件,并强制生成复盘任务。
## 5. 【待补充:包络边界初值 —— 需要业务侧输入】
> **TODO(业务)**:以下参数需由运营团队按湖北现货规则与合同实际确定,是包络模型落地的第一批配置:
>
> 1. 申报类包络:价格边界相对什么基准(电价预测值?历史分位数?),初始偏离容差取多少;
> 2. 控制类包络:分资源类型(空调/储能/工业可中断)的单点削减上限与恢复速率约束;
> 3. 包络审批层级 L1/L2/L3 分别对应公司内哪些岗位/会签流程;
> 4. 「连续 N 次偏差超阈挂起包络」中 N 与阈值的初值。