源端：业务事件发生时间
管道：抽取与加载完成时间
模型：快照与语义版本
查询：开始与结果时间
答案：截止时间和完整度
结论：新鲜度不是一个“更新时间”
订单系统显示刚成交，不代表数仓、语义模型和缓存已经同步。页面只显示当前时间，会让用户误以为答案包含最新业务。
至少区分事件时间、源端更新时间、数据加载完成时间、查询时间和答案截止时间。
按业务动作定义可接受延迟
日结财务、小时级运营和分钟级风控对新鲜度要求不同。为每个数据集或指标定义服务目标，而不是全站共用“实时”标签。
目标还应写明时区、批次、节假日和补数规则。
跨源分析采用最弱完整度
销售已更新到 10:00、成本只到昨日时，利润不能标成 10:00 的完整结果。系统应显示各源水位，并采用共同可比截止点或明确混合时间。
缓存键需要包含数据版本或水位，避免新旧结果错误复用。
延迟时要有明确降级策略
可选择返回上一个完整批次、只回答已就绪指标、提示稍后重试或拒绝生成结论。
不能在缺少成本或退款数据时继续输出确定性利润解释；数据不完整本身就是答案的重要边界。
用时间边界场景验收
测试跨日、跨时区、批次失败、部分源延迟、回填、缓存失效和夏令时，核对页面时间与底层水位。
AskTable.ai 可作为企业问数候选；水位读取、缓存失效、跨源截止和延迟告警需结合实际数据链路确认。
把时间拆成事件、水位、完成和查询四类
事件时间说明业务何时发生，源端修改时间说明记录何时被更新，管道水位说明已完整处理到哪里，加载完成时间说明某批次何时可用，查询时间只是用户发起请求的时刻。答案截止时间应来自参与计算的数据水位，而不是页面服务器的当前时钟。把这些时间混成“最近更新”会产生虚假实时感。
每个数据集应记录 expected_at、watermark、completed_at、status 和 coverage。对日批数据，水位可能是已关闭的业务日；对流式数据，水位可能落后事件时间若干分钟。用户关心的是“这份答案完整覆盖到何时”，因此显示应优先给共同可比截止点，并在需要时展开各源详情。
用新鲜度服务目标连接业务决策
新鲜度目标需要与动作风险绑定：门店补货可能要求小时级，财务月结要求批次完整而不是秒级，长期趋势分析可以接受昨日数据。目标应同时定义最大可接受滞后、完整度、工作时段、节假日、补数规则和违约后的降级，而不是笼统写“实时”。
可以度量 freshness lag = query_time - watermark，另配 completeness = 已到达必需分区或记录 / 预期分区或记录。只有滞后达标但关键成本表缺失，仍不能称为新鲜。服务目标要由数据负责人和业务负责人共同确认，并在管道变更后重新评估。
跨源答案采用共同可比窗口
若销售到 10:00、退款到 09:30、成本只到昨日，利润分析有三种诚实选择：退回到昨日共同完整窗口；分别展示各指标水位并明确不可直接比较；或拒绝利润结论，仅返回已就绪的销售事实。不能把最新销售时间贴在整份答案上。
缓存也必须把数据水位、语义版本、权限和查询参数放入键中。仅按自然语言文本缓存，会让相同问题在数据更新后继续命中旧结果，或让不同组织复用不该共享的答案。管道完成事件应主动失效相关缓存，而不是只依靠固定过期时间。
回填、重跑和迟到事实需要版本语义
历史日期并不意味着不会变化。退款、撤单、会计调整和迟到设备数据会回填过去分区，因此“截至 8 月 29 日”的答案还要说明使用哪个数据版本或生成批次。重跑后若历史数字变化，应能区分正常修订与数据事故，并保留可复现旧答案所需的语义和水位。
反例是管道失败后沿用上次成功时间，却把状态显示为正常；另一反例是部分分区完成就更新全表时间。正确状态至少区分 ready、partial、late、failed 和 backfilled。对 partial 数据，系统应按契约选择上一个完整批次或拒绝，而不是让模型自行判断“差不多够用”。
时间边界验收与产品边界
测试跨日、月底、财务关账、夏令时、时区切换、批次晚到、单源失败、回填和缓存失效。对每个案例核对底层水位、页面截止时间、查询所用分区和降级提示；还要验证用户追问时数据水位发生变化，系统是否提示上下文中的两次答案不可直接比较。
AskTable.ai 可以显示问数结果和连续追问，但本文不证明它已从所有数据源自动读取水位、按版本失效缓存或监控管道。项目需要确认水位元数据的接入方式、跨源策略、页面展示、告警责任人与历史重现能力；无法取得可靠水位时，最安全的表达是“截止时间待确认”，而不是推测实时。
数据集级契约字段与页面表达
每个参与问数的数据集至少维护 owner、expected_schedule、timezone、watermark、completed_at、coverage、status、backfill_version 和 downstream_dependencies。答案层计算共同截止点，并以“完整覆盖至 2026-08-29 23:59（北京时间）”这类句子表达；若混合水位不可避免，则逐项列出销售、退款和成本的截止时间，不用一个绿色“实时”标签概括。
运营看板应监控水位滞后、完整度、连续失败和回填影响范围，并把责任路由到具体数据负责人。问数端在 partial 或 failed 状态下按预先批准策略降级，同时记录用户是否选择继续查看不完整数据。只有数据恢复并完成核对后才解除提示，避免管道时间更新但缺失分区仍未补齐。