自动化能减少重复工作，但不保证新鲜度、准确性或相关性。AI摘要仍是待核查的建议。
保留数字背后的证据
与使用的数据集核对数字，保留时期、单位、过滤条件和计算版本。独立核查重要计算。不得用编造值填补缺失，也不能把预测当成观测结果。
安排错误处理与复核
明确复核者、接收者和纠错责任人。展示部分失败；重新发送最近有效的旧报告不会使其变新。发布前核查内容和收件人，测量实际节省，而非承诺普遍收益。
| 项目 | 需记录的检查 |
|---|---|
| 数字 | 可追溯的来源、公式和范围 |
| AI摘要 | 核查主张与限制 |
| 分发 | 核查状态和接收者 |
来源与核查
- NIST — Generative AI Profile, confabulation and evaluation
- Government Analysis Function — Communicating uncertainty
时区与迟到事件
报告期间由事件时间和结算规则决定。
- 分别记录事件时间、接收时间和业务时区。虚构例中，23:30 UTC在固定偏移UTC+02:00下是次日01:30。PostgreSQL带时区的时间戳不会保留原始时区名称。
- 采用包含起点、不包含终点的区间。先在业务时区确定边界，再转换为UTC。测试夏令时切换、月末和没有时间的日期；本地一天不能总按24小时替代。
- 规定允许的延迟和报表截止时间。重放同一标识，区分新事件与重复记录。保留已发布版本并记录修订影响；水位线是到达时间的估计，不是数据完整性的保证。
可复现的验收案例
虚构示例：数据不代表客户或实际观察结果。
查看案例输入
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}预期判断
在指定时区中，该事件属于10月9日。也保留UTC时刻。
验证步骤
- 定义报告时区及参考时刻。
- 重现午夜附近的事件。
- 保留UTC、本地日期及截点规则。 加入时钟调整时存在歧义的本地时间，保留偏移量和时区，而不是推断具体时刻。
能把接收日期当作事件日期吗？
只有报表定义明确要求时才可以。保存两种时间，并解释迟到事件如何处理。
一手资料：PostgreSQL — Date/time types. 相关方法：阅读实用指南.