Part 1. Introduction: SDD for Data

In Volume 1, SDD was applied to a web application: mission, stack, roadmap, feature spec, plan, verification, and implementation. In a data platform the same logic holds, but the main risk shifts. In an application an agent can mistake a route or UI. In data, an agent can silently change the meaning of a metric, the grain of a mart, freshness, the personal-data policy, or compatibility with downstream consumers.

That is why SDD Data does not start with SQL. It starts with the question: what promise does the data product make to its consumer?

What you will build

The study project is a DataLakeHouse of the fictional bank Bank Severny Most. By the end of the book you will have a local dbt project that builds the final marts:

• mart_customer_360;
• mart_card_turnover_daily;
• mart_payment_risk_signals;
• mart_credit_portfolio_quality;
• mart_open_api_consents.

All data is synthetic. The Russian banking context is used as a set of constraints: personal data, payments, consents, risk signals, regulatory reporting. This is a study architecture, not a legal guide.

How SDD Data differs from a regular dbt course

A regular dbt course often starts with select * from source. Here the order is different:

1. First, the platform mission.
2. Then the product spec and contract.
3. Then raw/staging.
4. Then marts.
5. Then verification facts and the reviewer report.

dbt remains the main transformation tool, but it does not become the source of meaning. Meaning lives in specifications. SQL must execute a fixed promise, not create it after the fact.

Brief SDD recap

SDD is a cycle in which an agent does not start with implementation. First a human and the agent lock down intent, boundaries, decisions, and verification facts. Then the agent writes code or SQL against the approved files. After implementation a separate review checks not only "did the tests pass", but whether the result matches the specification.

For data, this cycle looks like this:

describe the data product -> define the contract -> implement the dbt model
-> run verification facts -> assess impact on the contract -> gather release evidence

Three rules to keep in mind from chapter one:

• the specification lives in the repository, not in the chat;
• a verification fact must come with a command, SQL, or a manual reviewer step;

• author and reviewer must work in different modes, even if it is the same

CLI agent after /clear.

First risk: a silent change of meaning

Imagine the agent added product_code to mart_customer_360. The SQL compiles, dbt tests may pass, but the grain is no longer "one row per customer_id". For a downstream consumer this is a contract-breaking change: a report that was counting clients starts counting client-product pairs. In a web application such a defect is often visible immediately. In data it can make its way into a report, a KPI, or a risk model a week later.

SDD Data exists precisely for cases like these. It forces you to write before SQL:

• what grain is promised;
• which fields are required;
• which fields are forbidden;
• which checks tolerate change;
• who confirms drift or breaking changes.

Reader breakdown

On first reading it is easy to mistake this book for yet another dbt walkthrough: install an adapter, write models, run dbt build, get green output. This is the wrong frame. dbt here plays the same role as a testing framework in a regular application: it makes part of the behavior verifiable, but does not decide what exactly

must be true for the business. If the reader does not hold on to this distinction from chapter one, all artifacts further on will start to look like bureaucracy.

It helps to picture the study bank as an organization where a single table passes through several hands. The operations team exports the source. The data engineer aligns types. The analyst builds a report. The risk team looks at a signal. The executive reads an aggregate. An error in SQL may stay local, but an error in the meaning of a mart spreads along this chain. That is why SDD Data tries to protect not just the code, but the agreement between people: what a row means, which fields are allowed, what data age is acceptable, who confirms a change.

From here the main rhythm of the volume emerges. First the reader records the promise, then makes it executable, then proves it with facts, then hands it off to an independent review. This feels slower than writing SQL right away, but in the study project the difference shows up quickly: as soon as PII, consent, or a risk signal appears, the "quick SQL" starts making decisions it has no right to make. A good agent speeds things up only when the boundaries have already been named.

If after this chapter you are left with a feeling that all the words can be replaced by a single "build the mart" command, you should stop. Such a command asks the agent to be an analyst, an architect, a reviewer, and a risk owner all at once. In Volume 1 this was dangerous for a feature. In data it is more dangerous: the final table may look tidy, but already be telling an untruth.

Practice

Open the example:

cd book3/examples/bank-lakehouse
bash smoke_all.sh

If dbt is not installed, smoke will still generate synthetic data and verify the structure. After installing dependencies it will run a full dbt build.

Minimum output

After this part you should have chosen your reading mode:

• the study local track on DuckDB;
• mapping to the production environment as a reference layer, not as required

infrastructure;

• an understanding that the book is building not "a bank in general", but one reproducible

data-product process.

Write in your working notes:

First pass: I am building a local DataLakeHouse for the bank on dbt-duckdb; I do not
adopt the production mapping until the practical credit.

Typical mistake

Beginners try to immediately swap DuckDB for a "real" stack. This is

premature. On the first pass it is more important to see the link between the specification and the verifiable mart. If the local version does not hold grain, tests, and the PII policy, the production cluster will only accelerate the mistake.

Check questions

1. Why can't you start with SQL in a data project?
2. What changes if the final mart contains PII?
3. What must be the source of truth: the dbt model or the data-product specification?