用途：在提出运营改进方案前，先确认交付表现的真实口径，识别哪些定义选择会虚高报告数字。适合供应链、物流、客户服务的数据审计场景。
所需数据：订单级字段包括 order_id、requested_delivery_date（客户要求）、promised_delivery_date（承诺）、actual_delivery_date、完整性信息（行数或数量的订购与交付对比）以及状态/取消标记；可用维度包括承运商、地区、客户、产品族。若缺少 requested_delivery_date，需明确说明只能计算基于承诺日期的层级，无法识别销售缓冲，并建议后续补录。
主要能力：先做数据验证（重复行、不可能日期、取消订单及处理方式，并在输出中报告计数，不静默清洗）；在同一人群上按最严格排在最后计算指标阶梯：L1 相对承诺日期且使用当前容差窗口（未知则展示+3天并标注）；L2 相对承诺日期零容差；L3 相对要求日期零容差；L4 订单级完整交付的OTIF（9/10行不算90%准时，而是一个不完整订单）；L5 分母保留取消订单的OTIF。以表格呈现各层结果、下降差值及原因（容差、缓冲、部分交付、取消）。再按差异最大的维度分解差距，指出集中驱动因素；分析尾部而非均值，报告延迟4天以上占比与最差十分位；报告前用原始行单次直接重算头部OTIF核对。
需显式检查的陷阱：锚点选择，承诺与要求日差平均值大于0.5天时量化其对KPI的影响；容差是政策而非事实，有争议时展示敏感性曲线；取消订单移出分母会美化指标；行级平均会高估订单级完整性。
输出：阶梯表（定义、结果%、差值、原因）、三条发现句（变化点/集中位置/需要的决策）、定义脚注（锚点日期、容差、完整规则、取消处理）。示例与合成数据图表见 https://github.com/gulmezeren2-byte/otif-analytics 。来源方法包为 industrial-engineering-ai-skills（MIT）。