You're building a dbt project for an artisan cheese producer in Sibiu, Romania — connecting milk purchases, production batches, and sales records into a profitability model by cheese variety, with automated quality tests.
A dbt project is a set of SQL files — called models — connected by reference declarations that the framework uses to track dependencies and run tests. Unit 3 introduces the framework before you build anything.
The discipline skills: writing dbt models with declared dependencies and ref(), applying staging-to-mart layer architecture inside a framework, and writing automated tests — unique, not_null, accepted_values, relationships — that verify data properties after every run.
The AI-direction lesson: AI generates dbt models that run. The question is whether you understand what the framework is doing or are just trusting AI's explanation. AI will describe how models relate, how tests protect the data, how the DAG resolves dependencies — and those descriptions may not match the actual SQL. Reading the code AI produces, not the explanation it offers, is the verification habit that starts here. A dbt project where all tests pass can still produce wrong profitability numbers. The tests verify structure. You verify meaning.
Your Role
You're building a dbt project that connects Mihai's three data sources into a profitability model. The SQL is the same kind you wrote in P1 and P2. What's new is the framework — models, dependencies, automated tests. How you break the work into tasks is your call.
What's New
Last time you extracted API data, designed a schema from source profiles, and built staging and mart layers in raw SQL scripts. You handled idempotency manually — making sure re-running the pipeline didn't create duplicates.
This time, dbt handles idempotency for you. Models use CREATE OR REPLACE by default, so running the pipeline twice produces the same result without manual checks. The framework encodes a property you had to build yourself before.
The genuinely new piece is automated testing. dbt's built-in tests — unique, not_null, accepted_values, relationships — check structural properties of your data after every run. But structural correctness is not the same as business correctness. All tests can pass while the profitability numbers are wrong. Deciding which tests actually protect Mihai's numbers — and which just confirm things the database already guarantees — is the real decision in this project.
Tools
- Python — via your Miniconda
deenvironment - DuckDB — analytical database for all three sources
- SQL — transformation logic inside dbt models
- dbt Core + dbt-duckdb adapter — transformation framework (new this project). The unit that introduces dbt walks through setup.
- Claude Code — your AI agent, doing the implementation work
- Git / GitHub — version control
Materials
You'll receive:
- Pipeline specification — what to build, Mihai's requirements, verification targets
- Three data source files — production log, sales records, milk purchases
- dbt project template — project structure,
dbt_project.yml, andprofiles.ymlconfigured for DuckDB - Verification checklist — row counts, staging counts, profitability spot-checks
- Project governance file — CLAUDE.md with the full ticket breakdown
- Ticket backlog — work broken into sequenced tickets