A model review moves from analytical intent to operating consequences.
  1. PurposeAudience, decision, and grain
  2. LineageSources, references, and joins
  3. ContractTests, meaning, and limitations
  4. OperationMaterialization, cost, and recovery

Begin with purpose and grain

Before reading individual expressions, establish what one row represents, who uses the model, which decisions it supports, and what makes a record unique. An unclear grain makes joins, aggregations, tests, and metric definitions difficult to evaluate.

  • Can the model’s purpose be stated without describing its SQL?
  • Is its grain explicit and stable?
  • Are keys and expected cardinality understood?
  • Does the name communicate the model’s role?

Trace dependencies instead of treating files in isolation

References should make lineage visible and distinguish raw sources, staging transformations, intermediate logic, and consumer-facing models. Review whether a change in an upstream column, filter, or join can be traced to the outputs it affects.[2]

Review question: Could another engineer explain where an important output field came from and which downstream models would change if its source logic changed?

Test the contract that matters

Generic tests are useful when they represent real expectations. A blanket collection of not-null and unique checks can still miss the relationships, accepted ranges, conditional rules, freshness, and business invariants that determine whether the data is safe to use.[3]

  • Connect each important test to a meaningful failure.
  • Place tests at the layer where the expectation becomes true.
  • Review severity and failure handling rather than assuming every test blocks delivery.
  • Keep custom logic understandable enough to maintain.

Review joins, filters, and time logic deliberately

Many analytical defects enter through unexpected many-to-many joins, silent row loss, inconsistent time zones, incomplete history, or filters that encode undocumented policy. Compare row counts and key distributions where the risk warrants it.

Treat materialization as an operating decision

Views, tables, incremental models, and ephemeral models trade simplicity, cost, latency, and recovery behavior differently. The review should connect materialization to data volume, update pattern, downstream demand, rebuild strategy, and warehouse behavior.[4]

Make documentation answer user questions

Descriptions should clarify meaning, grain, important assumptions, source limitations, and ownership. Repeating the column name in prose satisfies a field without helping a consumer make a decision.

A compact review checklist

  • Purpose, audience, and grain are explicit.
  • Sources and dependencies are traceable.
  • Keys, joins, filters, and time logic preserve the intended records.
  • Tests represent consequential expectations.
  • Materialization matches cost, latency, and recovery needs.
  • Documentation explains meaning and limitations.
  • Build, review, deployment, and failure ownership are understood.

Sources and further reading

  1. Dagitali dbt demo repository — public evidence for the deliberately limited project described below.
  2. dbt reference: ref function — official guidance for model dependencies and lineage.
  3. dbt documentation: Data tests — official guidance for assertions about models and resources.
  4. dbt documentation: Materializations — official definitions and configuration considerations.

Related Dagitali evidence: The dbt demo technical profile links to a deliberately small public starter project. Its limited scope is useful for inspecting basic references and schema tests, but it is not presented as a production analytics platform.

Continue exploring

Related serviceReview data-science and analytics services

Related insightReview pipeline operability

Apply the guidanceExplore the Engineering Clarity Review