不要为三个审阅方维护三套事实
保险方关心损失与控制，审计方关心流程与批准，客户关心受到什么影响以及是否需要行动。若团队分别从记忆编写三份报告，时间、金额和根因很容易冲突。先建立一份受控事实底稿，再从中生成不同视图。
底稿只收录可验证事实：UTC时间线、受影响路径、保护范围与范围外调用、本地估算、供应商账单、控制动作、恢复测试和责任人。推断单独标记，不把最可能原因写成已确认根因。
统一事实底稿要能追到原始证据
每条重要结论关联日志导出、配置版本、账单或批准记录，并保存文件哈希、生成时间和保管位置。哈希可以证明交付后文件是否改变，但不能证明内容本身正确，因此还需要来源负责人复核。
所有时间转换为UTC，同时保留来源系统原时区。费用区分运营估算和最终账单，客户影响区分观察到的结果与理论风险；这些标签能避免审阅者把不同证据强度混成一个数字。
按对象最小化，不等于删掉不利事实
保险视图可包含承保期间、损失计算、已实施控制和合同要求；审计视图包含批准链、例外、检测与修复验证；客户视图包含其站点的时间、受影响功能、数据状态和后续动作。各视图都应保留支持其结论的关键事实。
最小化的是无关个人数据、其他客户信息、API密钥、原始提示词和不必要的内部机密，不是对组织不利的证据。删减表要记录删除类别、理由、执行人与批准人，保证后续能够解释版本差异。
| 目录项 | 统一底稿 | 保险方视图 | 审计方视图 | 客户视图 |
|---|---|---|---|---|
| UTC时间线 | 完整 | 承保相关事件 | 含批准与变更 | 仅该客户影响 |
| 费用 | 估算与账单分列 | 损失计算 | 对账与控制 | 必要影响范围 |
| 调用路径 | 覆盖及范围外 | 与损失相关 | 完整责任链 | 该站点路径 |
| 个人/对话数据 | 默认排除或严格受控 | 不提供无关内容 | 按审计必要性 | 不含他人数据 |
| 文件哈希与删除日 | 必须 | 交付清单 | 证据保全 | 适用材料 |
证据包目录本身就是交付物
目录为每个文件写明编号、标题、事件版本、来源、创建人、时间范围、敏感级别、哈希、适用对象和计划删除日期。不要让审阅者面对一包名为final2或screenshot的文件自行猜测。
建议按01_事实底稿、02_时间线、03_费用对账、04_控制与恢复、05_批准记录、06_对象视图和07_删除记录组织。文件名不包含客户个人信息，访问权限按最小需要设置。
交付前做一次跨视图一致性检查
自动比较事件编号、开始结束时间、受影响主机名、最终金额和根因状态，再由事实负责人审阅语义。若客户视图写已解决，而审计视图仍标记根因未确认，应修正措辞或解释两者关注范围，而不是让矛盾流出组织。
交付记录包含发送对象、批准人、文件版本、渠道和接收确认。后续更新底稿时，不应静默覆盖已交付版本；生成新版本并说明变化，才能保持证据链。
事件关闭包括按期删除，而非无限保留
证据保全需要期限和依据。达到删除日期后确认是否仍有法律、合同或审计保留要求；没有则按记录删除，并保留不含原始内容的删除证明。产品数据字段与保留边界可继续在隐私说明中核对。
把“费用事件结束后，怎样给保险方、审计方和客户分别准备证据”的事件证据包目录用于第一次真实安装。免费下载 AI Cost Circuit Breaker，先从 Monitoring 开始，验证预期信号和回退方式后再启用强制控制。