← Back to Pattern Catalog
Engineering Challenge
Interactive Example

Snapshot Drift

Quick answer

Snapshot drift happens when the same historical reporting period produces different results later.

Snapshot drift occurs when a report for January, March or any other historical period changes after it is rebuilt with newer data, late corrections or different transformation logic.

The problem is not always that the new result is wrong. The problem is that the model does not clearly distinguish the originally published snapshot from the later corrected rebuild.

Interactive Example

The January snapshot was published as 120,000. A March rebuild now shows 128,500.

Toggle between the originally published snapshot and a later rebuild. The reporting period is the same, but the result changes.

Timeline
31 Jan
Snapshot published
January report is frozen at 120,000.
12 Mar
Late correction arrives
A backdated record changes January history.
15 Mar
Snapshot rebuilt
The January result now calculates as 128,500.
Report mode
January snapshot as published
January total120,000

The January snapshot was published with the data and corrections known at the reporting cut-off.

Key idea

Snapshot drift is not just a number changing. It is a missing modeling decision: should this report show the originally published output, the as-known view or the corrected rebuild?

Why it happens

Old reporting periods are rebuilt with newer knowledge.

A snapshot is often treated as a simple query result for a reporting date. But if the underlying source history changes, the same query may produce a different answer later.

Late arriving recordsBackdated correctionsChanged dimension historyRebuilt pipelinesChanged business rulesMissing publication time
Typical symptoms

Users see different numbers for the same reporting period.

✓ Month-end totals change after reload✓ Old dashboards no longer match exported reports✓ Audit teams cannot reproduce previous submissions✓ Backfills change historical KPIs✓ Corrections leak into already published snapshots
Root cause

Snapshot date, knowledge date and publication date are different concepts.

A snapshot date answers which business period is being reported. A knowledge date answers what the platform knew when the query was evaluated. A publication date answers what was officially released to users.

Snapshot drift appears when these concepts are collapsed into one column or hidden inside rebuild logic.

How to prevent it

Make snapshot reproducibility explicit.

Persist published snapshots
Store the exact output that was released to reporting users.
Track visible time
Query historical reports using what was known at the reporting cut-off.
Track publication time
Store published_at, snapshot_version or reporting_run_id for frozen outputs.
Separate report modes
Distinguish original, as-known and corrected rebuilds.
Related patterns

Snapshot drift is solved by reproducibility and publication-time modeling.

Snapshot Reproducibility
Defines how historical reports can be reproduced for the same reporting date.
Publication-Time Modeling
Separates what was true, what was known and what was officially published.
Bitemporal Modeling
Preserves when corrected history became visible to the platform.
Historical Correction
Handles late or retroactive corrections without silently rewriting history.
Try it

Validate whether your snapshots can drift.

Use Target Table Validation to check snapshot grain, historical semantics and reproducibility risks in generated reporting tables.

Validate a target table →