Should Our Next dbt Move Be Tests, Model Cleanup, Ownership Cleanup, or Upstream Source Repair?

What should we fix first in dbt?

The first dbt fix should match the first place trust is actually breaking. If the raw evidence is unstable, repair the source path first. If quiet failures keep reaching stakeholders, start with tests. If nobody can explain the logic, clean up the models. If the logic is understandable but nobody owns changes cleanly, fix ownership. And if the business still cannot name the real broken decision, dbt is not the first problem.

That is a more useful answer than “our dbt project is messy.”

I hear that sentence a lot. It usually bundles four different problems into one label:

• source fields are drifting before dbt ever sees them
• the project compiles, but bad data still reaches dashboards quietly
• the SQL technically works, but nobody can explain which model owns the metric anymore
• the logic is mostly fine, but reviews, approvals, and change discipline have fallen apart

Those are not the same repair lane.

Treating them as the same repair lane is how teams spend six weeks doing cleanup and still leave the next forecast review with the same trust problem.

This article is meant to stay narrower than the existing nearby pieces on the site.

5 dbt Implementation Mistakes That Kill Data Trust covers the common failure patterns. The dbt Project Health Scorecard helps you grade overall project health. How to Scope a Data Foundation Cleanup Before You Hire Anyone helps you frame the broader cleanup brief.

The gap this page is trying to close is smaller and more operational:

When the room agrees the dbt layer feels risky, what is the first remediation move?

Why teams pick the wrong first fix

Most teams do not lack opinions about what is broken.

They lack a forcing function that makes them separate evidence quality, failure detection, model clarity, and change ownership.

So the repair plan usually gets written in blended language:

• clean up the project
• tighten governance
• refactor key models
• improve source quality
• add some tests

Every one of those might be true.

That does not mean every one of them should lead.

The practical mistake is sequencing. If the source path is still unstable, a model refactor mostly reorganizes chaos. If tests are the real gap, a big cleanup sprint can still leave the next bad record undetected. If ownership is the weakest point, you can refactor perfectly and still ship new confusion the next week because nobody has reviewer authority.

That is why the first move matters so much. The first move is not supposed to solve the whole dbt program. It is supposed to remove the tightest trust bottleneck fast enough that the next operating moment goes better.

The market data points in the same direction. dbt Labs’ 2025 State of Analytics Engineering report found that poor data quality remained the number-one hurdle for 56% of respondents and that 38% planned to increase investment in data quality and observability.¹ That is not a sign teams need more generic cleanup language. It is a sign they need a clearer way to decide what deserves to lead the repair queue.

The decision tree I would use in a real remediation meeting

Use this tree when someone says the dbt layer is the problem and the room needs to choose one first move instead of another blended wishlist.

The tree is intentionally strict.

It is supposed to stop the room from saying “all of it” for one more week.

Gate 0: can the business name one broken metric and one decision?

Start here because a surprising number of dbt cleanup requests are still translation problems wearing technical clothes.

If nobody can answer these questions clearly, do not pretend the first fix lives inside the repo:

• which metric or report is failing trust?
• which meeting or workflow keeps breaking because of it?
• what decision changes if the number is repaired?

If the answers are still fuzzy, you do not have a remediation sequence yet. You have a scoping problem.

That does not mean the dbt project is healthy. It means the room has not separated the technical symptom from the business ask. In practice, this is where a sprint like Translate the Ask creates more leverage than another round of SQL cleanup, because the next technical move is still being chosen against a blurry target.

A reliable operator tell: three different leaders describe the same problem using three different nouns. One says pipeline trust. One says dashboard reliability. One says warehouse cleanup. That is usually not one clean dbt-first issue. That is blended problem framing.

Gate 1: is the number already unstable before dbt transforms it?

If the answer is yes, start with upstream source repair.

This is the branch teams skip because dbt is where the pain becomes visible.

But visibility is not the same thing as origin.

If lifecycle stages are entered differently by rep, campaign associations arrive late, IDs drift across systems, or one critical field is half-optional in practice, dbt ends up doing one of two bad jobs:

1. it normalizes the mess just enough that downstream users think the number should be trustworthy
2. it gets blamed for instability that was already baked into the source evidence

That is why this branch should lead when the break starts before transformation.

Use source repair first when:

• the same field arrives with different meanings by team or region
• a sync or connector drops important state transitions
• source freshness breaks are more common than model logic bugs
• every mart inherits the same duplicates or null-heavy rows

The practical goal here is not a beautiful source model. It is one trustworthy intake path for the metric family in scope. If you cannot hold that line, downstream elegance is mostly theater.

Gate 2: would a bad row or source change reach stakeholders before anyone noticed?

If yes, tests usually come first.

This branch is different from source repair.

Source repair asks whether the evidence is bad before dbt. Test-first asks whether the project is failing to catch bad evidence or broken assumptions before the business sees them.

I would choose tests first when the room can mostly explain the model logic, but trust still breaks because there is no reliable tripwire.

Typical examples:

• a source column changes shape and nothing alerts until a dashboard looks wrong
• duplicates quietly inflate a funnel or revenue view
• a status value expands upstream and the logic does not know what to do with it
• a core mart is business-critical but still has almost no meaningful assertions

This is where teams often over-rotate into refactoring. They dislike the shape of the project, so they want to reorganize it. But if the immediate pain is that bad data keeps reaching leadership quietly, the shortest path back to trust is usually a stronger test wall, not a bigger architectural rewrite.

The lived-in rule I use is blunt: if the next bad source change would still become a stakeholder surprise, tests are probably underweighted in the first-fix sequence.

Gate 3: can someone explain which model owns the metric and why the logic is shaped that way?

If not, choose model cleanup first.

This is the branch for logic sprawl.

The data is not obviously dirty. The project may even have decent baseline testing. But the metric still feels fragile because nobody can answer simple ownership questions inside the DAG:

• which mart should the business actually trust?
• where do the important business rules live?
• why does this exception happen here instead of upstream?
• which model is redundant, stale, or carrying legacy logic nobody wants to delete?

That is model cleanup territory.

This usually shows up after a dbt project has been useful for a while. The business needs changed. New marts were added under deadline pressure. Someone left. A fast patch became permanent. Now the project still works, but it no longer explains itself.

When this is the lead branch, the first win is clarity, not maximal elegance. Pick one metric family, one subject area, or one decision path and make the model chain explainable again. If you try to cleanse the whole project at once, you usually ship more motion than trust.

Gate 4: is there a named owner and review path for changes?

If not, ownership cleanup should lead.

This is the branch that gets missed by technically strong teams.

The SQL might be understandable. The models might even be tested reasonably well. But the project still behaves like a trust risk because the change discipline is weak:

• no one can say who approves business-logic changes
• one analyst is still the unofficial memory layer for caveats and edge cases
• PRs get merged without a real reviewer for metric logic
• incidents happen, but the team never tightens the review rule that would have prevented the next one

That is not mainly a code-structure problem.

It is a governance problem inside the working dbt flow.

Ownership cleanup often means writing down smaller things than people expect:

• who can approve a metric-definition change
• who reviews source-contract changes
• what needs sign-off before a mart used in executive reporting is altered
• which incidents force a new test, runbook note, or approval gate

If the room keeps asking for a cleanup sprint but the same class of avoidable drift keeps returning, this branch deserves a hard look.

When dbt is not actually the first problem

Sometimes the tree sends you back out of the dbt layer entirely.

That is not a failure.

It is the right answer when the trust break sits in one of these places instead:

• teams still disagree on the metric definition itself
• the reporting artifact is wrong for the meeting
• the workflow around the number is broken even if the warehouse logic is fine
• leadership is using “fix dbt” as shorthand for a broader data-foundation or decision-translation problem

That is why this article should not replace broader cleanup scoping. It should sharpen it.

A lot of teams use dbt as the container for organizational debt because it is where business logic becomes visible. The better move is to ask whether the next repair belongs in transformation at all. If the answer is no, admit it early and save the team from a cleanup sprint that never had the authority to solve the real problem.

A table for fast triage in the room

If the conversation is getting muddy, this is the comparison table I would put on screen.

Four examples that make the branches easier to see

Example 1: sourced pipeline keeps moving after the rep updates CRM fields

If the same source opportunity is getting different lifecycle or attribution treatment before dbt sees it, start with source repair.

You might still need downstream cleanup later. But until the source contract stabilizes, every mart is carrying the same poison forward.

Example 2: revenue dashboards break quietly after a source change

If one critical source field changed shape and leadership only noticed after the board-prep run, start with tests.

The room does not need a lecture about long-term architecture first. It needs a stronger tripwire between change and stakeholder surprise.

Example 3: the team has three marts that all look like the answer

If analysts keep rebuilding queries because nobody trusts which mart is canonical, start with model cleanup.

That is the sign that the project still works mechanically but has lost its explanatory shape.

Example 4: every metric change still depends on one person remembering the caveats

If the project relies on one unofficial reviewer or one heroic analyst to keep logic honest, start with ownership cleanup.

That kind of drift often survives even a clean refactor, because the real missing piece is not SQL quality. It is change discipline.

What a good first-fix plan should look like

The output of this exercise is not “we fixed dbt.”

It is something tighter:

• one lead branch
• one named owner
• one proof-of-fix condition
• one next operating moment where the business should feel the change

Examples:

• Source repair first: clean lifecycle stage history and campaign association rules for one pipeline metric before the next forecast review
• Tests first: add high-signal tests plus one alerting/reporting path to the marts feeding executive revenue reporting
• Model cleanup first: collapse one duplicated metric family into one clear canonical mart and retire the look-alikes
• Ownership cleanup first: define reviewer authority and change rules for revenue or pipeline marts used in recurring leadership reporting

That is what makes the work real.

If the plan still sounds like “tighten governance and refactor key models,” the room has probably not picked a first move yet.

Download the gate sheet

Use this worksheet when the remediation conversation starts drifting back into blended cleanup language. It is designed to get the team to choose one lead branch and one proof-of-fix condition before the next repair sprint starts.

Sources

1. dbt Labs, 2025 State of Analytics Engineering and related report summary figures cited in The dbt Project Health Scorecard. dbt Labs reported poor data quality as the top hurdle for 56% of respondents and found that 38% planned to increase investment in data quality and observability.

If the tree shows the fix clearly belongs inside the warehouse and dbt layer, Data Foundation is the right broader lane. If the room still cannot describe the real broken decision without collapsing into technical nouns, start with Translate the Ask instead.