Prove the pipeline works

Use a deliberate validation sequence

Each command answers a different question:

1. Validation checks whether the project and its file dependencies are set up correctly.
2. Rendering shows the exact SQL after dates and table update settings are applied.
3. A small run checks whether a few dates behave correctly.
4. Comparing the output with the source checks whether it answers the business question.

Keeping these questions separate makes a failure easier to locate.

Validate the project

bruin validate commerce/pipeline.yml

Resolve missing file dependencies, invalid settings in asset headers, or SQL errors before running data. A clean validation does not prove the result is correct, but a failed validation means the pipeline is not ready to test.

If this is a new database and you did not create the table in the previous lesson, create the output tables once:

bruin run commerce/pipeline.yml \
  --start-date 2026-01-01 \
  --end-date 2026-01-03 \
  --full-refresh

Skip this command when the tables already exist. Normal interval runs should not use --full-refresh.

Show the SQL for the changed table

bruin render commerce/assets/analytics/customer_daily_revenue.sql \
  --start-date 2026-01-01 \
  --end-date 2026-01-03

Inspect the output for:

• The intended destination table.
• An inclusive January 1 lower bound.
• An inclusive January 3 upper bound.
• The customer join on customer_id.
• Paid-only recognized revenue logic.

Run the course interval

bruin run commerce/pipeline.yml \
  --start-date 2026-01-01 \
  --end-date 2026-01-03

The run should execute the files in dependency order and run the checks attached to each asset.

Compare counts and totals

bruin query --connection duckdb-default \
  --description "compare customer daily revenue output counts and totals" \
  --query "SELECT COUNT(*) AS output_rows, SUM(total_orders) AS orders, SUM(paid_orders) AS paid_orders, SUM(recognized_revenue) AS recognized_revenue FROM analytics.customer_daily_revenue;"

Expected result before the recovery exercise in the next section:

output_rows: 5
orders: 6
paid_orders: 4
recognized_revenue: 279.50

Now compare the reporting table total with the order model:

bruin query --connection duckdb-default \
  --description "compare recognized revenue in the fact and reporting models" \
  --query "SELECT SUM(recognized_revenue) AS fact_revenue FROM analytics.fct_orders;"

Both totals should be 279.50. If the row checks pass but these totals differ, investigate the join or the calculation that groups orders by customer and date.

Ask your coding agent

Checkpoint

Keep the command output or a short summary with the pull request. A reviewer should be able to see that validation passed, the SQL used the intended dates, checks ran, and the reporting total matched the order model.