Use this to score an existing dbt project in under an hour. Give one point for each check that's fully true today. It's the same ground a Data Foundation Audit covers, condensed into a self-assessment.
Figure 1. Most checks live in the dbt layers, but CI and operations cut across the whole stack.
Figure 2. Each kind of logic lives in exactly one layer, so a change is made once and flows right.
Sources
Every raw table is declared as a dbt source, not referenced by hard-coded name
Source freshness is configured for every source that feeds a business metric
Each source has an owner and a description
Staging models are one-to-one with source tables and only rename, cast and clean
No model selects directly from raw tables outside staging
Modelling
A clear layer structure (e.g. staging → intermediate → marts) is followed consistently
Naming conventions (stg_, int_, fct_, dim_) are documented and enforced
Each mart has a stated grain ("one row per …") in its description
No circular or tangled dependencies; the DAG reads left to right
Very large "god models" are split into testable intermediate steps
Business logic lives in one place, not copied across models
Testing
Primary keys have unique and not_null tests
Foreign keys have relationships tests
Accepted-values tests guard status and type columns
Key metrics have at least one sanity test (e.g. non-negative revenue)
Test failures alert someone, not just a log file
Tests run on every pull request, not only in production
Documentation & semantics
Every mart and its key columns are described
dbt docs are generated and reachable by the team
Core metrics (revenue, MRR, active users…) have one written definition
BI tools use those shared definitions instead of re-implementing them
Exposures map which dashboards depend on which models
Workflow & CI
All changes go through pull requests with review
CI builds and tests modified models (slim CI / state-based selection)
Separate dev and prod targets; nobody develops against prod
dbt and package versions are pinned
Operations, cost & access
Orchestration runs are monitored and failures are visible
Expensive models are identified and materialised appropriately (incremental where it pays)
Warehouse roles follow least privilege; service accounts are separate from people
A runbook explains how to deploy, backfill and recover
Figure 3. Business logic lives once, in intermediate and marts; everything downstream refs it rather than copying it.
How to read your score
Figure 4. Breaks are caught on the pull request, before merge; production failures page a person.
Give yourself 1 point for each check you fully pass (30 checks, max 30).
Score 25–30 of 30: solid foundation; focus on cost and new use cases.
15–24 of 30: works, but numbers will drift. Prioritise testing and shared metric definitions.
Under 15 of 30: expect conflicting dashboards. Fix sources, keys and tests before building more.
Using the scorecard spreadsheet? It also lets you mark a check Partly, worth 0.5 points, so half-points are possible: anything from 25 up reads as 25–30, from 15 up to 24.5 as 15–24, and below 15 as under 15. These bands are a rule of thumb, not a benchmark.