Prove an incremental mart matches a full refresh after corrections
The team wants to reduce daily build cost but needs confidence that incremental state does not drift after late corrections.
- Focused work estimate
- 6h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Differential testing · Data reliability
Estimated field mix
- Quality engineering50%
- Data engineering50%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional SaaS analyst reports expansion revenue differently from finance because snapshots, refunds and contract changes are joined at incompatible grains.
Setup prerequisites
- Create a synthetic source schema and local transformation project.
- Use integer minor units and distinct reporting currencies.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- ADBT-101 · Declare the subscription-movement grain before joining invoice lines
- ADBT-102 · Separate recurring contract value from collected cash
- ADBT-103 · Reject source schema drift before materializing the mart
- ADBT-104 · Join customer segments as of the revenue event date
- ADBT-105 · Make incremental movement loads include revised source rows
- ADBT-106 · Represent cancelled subscriptions as movements instead of deleting them
- ADBT-107 · Detect fan-out before publishing account-level revenue totals
- ADBT-108 · Generate a report manifest with exact model and source revisions
Acceptance criteria
- Author a sequence of inserts, revisions and tombstones.
- Compare every grain key and measure to a full refresh.
- Report extra, missing and changed rows separately.
Implementation constraints
- Run both paths against the same immutable synthetic inputs.
Verification to include
- Replay the complete change sequence with equal final outputs.
- Skip one revision intentionally and verify a precise discrepancy report.
Deliverables
- Differential transformation harness
Rollout and recovery
Require a clean differential run before changing schedule; revert to full refresh on mismatch.
Value of the work
For the engineer: Practice analytical modeling and explainable transformation contracts.
For the team: Review trustworthy reporting definitions and the cost of correcting historical reports.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.