The procedure

build, metric and init follow all seven steps. ask and analyze change no pipeline code, so they look, ask, check their own queries and end with a receipt. review looks, checks and gives the receipt.

1. Look#

It reads your repo, your definitions and your contracts first, and the schema if it can reach one read-only. Whatever it can find out, it doesn't ask.

2. Ask#

Only questions it can't answer itself, and that change the result: at most 5, together, each with a suggested default. If nobody's there to answer, it uses the defaults and lists them as assumptions.

From a real build on the demo shop:

1. "What kind of lifetime value should the mart hold?" Realized, to date (Recommended)
2. "Should subscription revenue (MRR) count toward LTV, or only order revenue?" Orders only, MRR shown apart (Recommended)
3. "Which customers get a row?" All customers, flagged (Recommended)

3. Contract first#

Before any code, it writes down what one row means, the keys, the columns and their units. See Contracts.

4. Build#

The code follows your stack and your conventions: dbt, Airflow, Dagster, plain SQL or pandas. Tests ship with it, and they have to run, not just be declared. Anything destructive, like rebuilding raw data, needs your confirmation first.

5. Check#

It runs the checker on what it wrote, fixes real findings and reports the rest.

6. Receipt#

Every task ends by saying what was built, what was checked, what wasn't and why, what it assumed, and any conflicts. See The receipt.

7. Remember#

Your answers go into DATA.md and the contracts, so nobody is asked twice. They never go into rule settings: those are yours to change.