← Back to Learn
ENGINEERING CHALLENGE

Snapshot Drift

Detect when a historical snapshot rebuilt today no longer matches the result originally produced for the same reporting date.

Snapshot drift reveals hidden changes in source history, dimensions, transformation logic and reporting cutoffs.

Problem

The same historical snapshot can produce a different result after rebuild.

A month-end or quarter-end snapshot may be rebuilt from mutable source history long after the original report was published.

If source records, dimensions, business logic or visibility cutoffs have changed, the rebuilt result can differ from the original even though the reporting date is identical.

Without explicit drift detection, teams may discover these differences only after an audit, reconciliation failure or user complaint.

Changed historical totalsNon-reproducible reportsCurrent-dimension leakageUndocumented restatementsAudit mismatch
Interactive example

The original March snapshot contains 1.250 contracts. A later rebuild contains 1.286.

Compare the original result, an unexplained rebuild and a controlled restatement.

Execution context
31 Mar
Original snapshot1.250
15 Jun
Rebuilt snapshot1.286
Reporting interpretation
The published month-end result
Contract count1.250 contracts

The original March snapshot reflects the source data, dimensions and transformation logic available at the reporting cutoff.

Key idea

A changed result is acceptable only when the difference is explained and the original snapshot remains identifiable.

Core concepts

Snapshot drift compares two executions of the same historical reporting contract.

The original snapshot and the rebuilt snapshot must use the same reporting date, source cutoff, dimension perspective and business logic before their results can be compared meaningfully.

Original snapshot
The result produced and optionally published at the historical reporting cutoff.
Rebuilt snapshot
The result generated later for the same reporting date.
Drift
Any unexplained difference in rows, measures, classifications or coverage.
Restatement
An intentional corrected result that remains distinguishable from the original.
Why it happens

Historical inputs and reporting logic continue to change after publication.

Source systems can correct past transactions, reload dimensions or deliver late-arriving records. Engineering teams can also change joins, filters and calculation logic.

A later rebuild sees this newer world unless the original knowledge and execution context were preserved.

Source corrections
Historical source rows are changed, backdated or reloaded after the original snapshot.
Dimension drift
Current dimension attributes leak into a historical rebuild.
Logic drift
Transformation rules, filters or business definitions change over time.
Cutoff drift
The original ingestion, visibility or publication cutoff is not preserved.
Common modeling approaches

Preserve the inputs and execution context required for reproducibility.

Persist published snapshots
Store the official output when exact reproduction is a hard requirement.
Preserve knowledge cutoffs
Record visible-time, ingestion-time or publication-time boundaries.
Version business logic
Track transformation, rule and code versions used for each snapshot run.
Run drift reconciliation
Compare rebuilt and original outputs at row and aggregate level.
Snapshot execution metadata
snapshot_date
source_cutoff
knowledge_cutoff
logic_version
dimension_version
published_at
row_count
control_total
Validation checks

Detect and explain every difference between original and rebuilt output.

Reporting date is identicalSource and knowledge cutoffs are preservedTransformation version is knownHistorical dimensions use the intended perspectiveRow-level differences are classifiedControl totals are reconciledIntentional restatements remain explicit
Why it matters

Snapshot drift separates reproducibility failures from legitimate restatements.

Not every difference is wrong. A corrected or restated report can be valid, but it must not silently replace the historical output users originally received.

Drift analysis explains whether a difference comes from source corrections, changed logic, dimension leakage or an approved restatement.

This protects trust in historical KPIs and makes reporting changes auditable.

RELATED TEMPORAL MODELS

How Snapshot Drift connects to other historical patterns

Snapshot drift is the failure mode that appears when historical reconstruction, correction handling and reporting cutoffs are not controlled together.

Snapshot Reproducibility
Defines the controls required to rebuild a historical snapshot consistently.
As-Known Reporting
Preserves the knowledge cutoff used by the original report.
Historical Correction
Explains how source corrections should affect rebuilt and published outputs.
Publication-Time Modeling
Distinguishes corrected truth from the officially released snapshot.
Related Patterns
Snapshot ReproducibilityAs-Known ReportingHistorical CorrectionPublication-Time ModelingSnapshot Fact Modeling
Try it

Investigate a historical snapshot that changed after rebuild.

Use the Historical Data Assistant to reason about cutoff drift, source corrections, dimension leakage, logic changes and report restatements.

Open Historical Data Assistant →