Your change request
A teammate proposes the Cobalt order model and historical segment join for a dashboard. Prepare a review packet: model contract, source-to-output lineage, before/after evidence, failure checks, affected consumers, release decision and recovery plan. No real warehouse or website schema is changed by this exercise.
Attempt before the reference
Name which checks prove row identity, valid types, latest-version behavior, historical match cardinality, metric totals and completeness. Which checks can pass while segment attribution is still wrong? What would you ask a dashboard owner before accepting a definition change?
Reference solution
Use source→validated changes→current order state→effective segment match→metric output. At each edge specify grain, key, time interpretation, allowed missingness and failure owner. Compare incremental target to an independently rebuilt target; compare fact counts and amounts before/after temporal enrichment. Inspect boundary examples and unmatched records. Matching totals alone cannot detect use of latest segment for historical facts.
A useful evidence table
Keep compact proof for normal and failure paths. Never replace the expected row sets with a screenshot of green status alone.
check | expected | observed | decision
b2 then replay | 2 completed / 15000 | record result | pass/fail
stale deletion replay | o2 stays deleted | record row | pass/fail
mid-batch failure | unchanged target | compare rows | pass/fail
temporal baseline | 4 / 32000 | record result | pass/fail
overlap injection | publication blocked | error evidence | pass/fail
missing B | UNMAPPED 2 / 10000 | record result | pass/failReview a breaking definition
A request changes “completed value” to include cancelled orders. This is a semantic change, not a harmless refactor. Name affected dashboards, document old/new definitions, compare representative outputs, seek metric-owner approval and choose a versioned transition or planned coordinated release. Do not silently preserve the old metric name while changing its meaning.
Recovery and ownership
For this scratch exercise, preserve the source fixture and reviewed previous model; rebuild in a separate local database and compare outputs before replacing a derived model. For real work a qualified team must define recoverable data backups, permissions, transaction boundaries, incident owner and tested recovery. This project does not provide a universal cloud deployment or migration script.
Portfolio and interview defense
A truthful claim is “Built and tested local incremental and historical attribution models on fictional sources, with replay, rollback, overlap and reconciliation evidence.” Do not claim production dbt delivery, certification or measured business savings. Answer: why is a unique_key not a uniqueness test; why are tombstones useful; why does a temporal join need cardinality checks?
Reviewer rubric
Score 0–2 each for contracts, independent evidence, consumer impact, recovery plan and truthful explanation. Record one limitation and one next experiment. These are self-review exercises, not employer assessments or saved course credentials.
Authoritative reference
dbt Labs, incremental-model documentation. Use it to compare your source/key/filter assumptions with a mature modelling workflow; the exercise is implemented in SQLite, not a dbt adapter.
Try the activity before reading its reference. Keep your sources, commands and assumptions with your work. Companion activities are unsaved self-practice and do not award a certificate or change lesson progress.