Plan、apply、verify 是安全模型
Mqttable 为什么把 MQTT 写操作、负载、故障注入和报告持久化都变成显式确认计划。
2026年6月24日
Mqttable 工程团队
Mqttable 工程团队Mqttable 允许 Agent 帮忙做 MQTT 操作，但不允许它们静默修改本地状态。安全模型很简单：先 plan，人工确认后 apply，然后通过重新读取状态 verify。
Interactive diagram
状态机：draft input、masked plan、人工确认、apply、verify evidence。
交互图占位。等图生成后，用正式交互组件替换这里。
Plan
Plan 阶段会用运行时同一份 contract 校验 action input。结果是一个有界计划，包含 operation、side effects、masked diff、risk、validation notes、expires_at 和 confirmation token。
Apply
Apply 不接受原始业务 payload。它只消费已保存的 plan 和 confirmation token。这样可以防止模型或客户端在最后一刻替换 Broker、payload、toxic 或 TLS reference。
Verify
Verify 针对 operation 重新读状态。Broker 更新就读回 Broker。Runtime control 就读运行时状态。Report persist 就读 report store。结果是证据，不是承诺。
最需要这个模型的地方
Broker 配置、Connection 配置、publish、订阅、定时消息、Benchmark run、Proxy 故障注入、TLS reference binding 和报告持久化，都应该走这条链路。