noCV
LAKE-105 · Build reliable models

Preserve historical merchant plans in revenue breakdowns

Practice briefTaskAdvanced

M-17 upgrades from Starter to Growth in June. Joining today's merchant record moves all earlier revenue into Growth and rewrites quarterly comparisons.

Focused work estimate
3h 30m + prerequisites
Priority in the scenario
Medium
Engineering practice
Slowly changing dimensions · Temporal joins · Integrity constraints

Estimated field mix

  • Data engineering70%
  • Database engineering30%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

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 marketplace reports daily sales to merchants. Refund joins inflate revenue, merchants close books in different time zones, and backfills compete with nightly loads. All source orders and merchants are synthetic.

Setup prerequisites

  • SQL joins and aggregates
  • Batch pipelines
  • Metric definitions

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Join sales to the plan effective at the sale instant.
  • Reject overlapping effective intervals per merchant.
  • Represent missing history explicitly instead of using today's plan.

Implementation constraints

  • Use inclusive-start, exclusive-end intervals and document their boundary.

Verification to include

  • Assign sales before and at the upgrade instant correctly.
  • Detect interval overlaps and gaps without double-counting.

Deliverables

  • Historical dimension model and interval checks

Rollout and recovery

Backfill synthetic history and retain the prior dimension version until totals reconcile.

Value of the work

For the engineer: Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases.

For the team: Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product.

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.