Time series and forecasting · insight-0255
Store first-reported and final actuals so forecast accuracy uses the right version
- Evidence type
- practitioner heuristic
- Difficulty
- medium
- Roles
- Data analyst, Data scientist, ML engineer
- Industries
- aviation, insurance, energy
Summary: situation, action, reason, boundary
Situation
Revenue figures are updated days after the flight date, and accuracy reports are rerun against the latest table.
Action
Keep vintages: store each actual with its load timestamp, train on the version available at each origin, and state which version accuracy reports use.
Reason
Point-in-time correctness applies to targets as well as features; revisions are information that did not exist when the forecast was made.
Boundary
Revenue, macro statistics, insurance claims development, energy meter data.
Symptom or risk
Training on revised actuals while serving on first-reported values creates skew, and scoring old forecasts against revised data changes past accuracy numbers without explanation.
Exceptions
If revisions are tiny and rare, documenting them may be enough.
Trade-offs
Vintage storage costs space and complicates queries.
Pitfalls
Deduplicating late updates by keeping the first row and silently dropping the correction, or the reverse.
Example
The synthetic flight_day_raw table contains duplicates where half carry a late revenue update.
Lessons and concepts
Claims and their sources
Point-in-time joins can filter on a created timestamp so backfilled or corrected values do not leak into training data.