Course overview/Pipeline development4 of 4

Pipeline runs, run types, validation, and inspection

Back to course

Pipeline development - Step 13 of 14

Pipeline runs, run types, validation, and inspection

Choose a run type, validate the change, and inspect results.

Each command answers a different question

Do not start with the largest pipeline run. First check whether the configuration is valid, then read the generated SQL, then run the smallest scope that can prove the change.

This order separates configuration problems, query problems, and data problems. It also makes a failed run easier to explain and fix.

Command glossary

  • bruin validate checks pipeline configuration and can validate a specific asset or the current project. It catches configuration and schema issues before a full run.
  • bruin render produces the SQL or materialized output for a SQL asset without running the asset. Use it to review filters, joins, variables, and generated materialization logic.
  • bruin run executes a pipeline or asset. You can give it a path, environment, date range, tags, or a selector to limit the scope.
  • Run interval is the --start-date and --end-date range used for a run. Use a small interval while testing an incremental model.
  • Selector targets assets using dbt-style syntax, such as +fct_orders for an asset and its upstream dependencies. It is useful when a path alone is not the right scope.
  • Quality check runs an assertion about the output, such as whether a primary key is unique or a required column is present. A completed process is not enough if the data is wrong.
  • Full refresh runs with --full-refresh and rebuilds historical output. Review the size, downstream effect, and table protection settings before using it.

A normal development sequence

bruin validate
bruin render assets/daily_customer_revenue.sql --start-date 2026-07-01 --end-date 2026-07-01
bruin run --start-date 2026-07-01 --end-date 2026-07-01 assets/daily_customer_revenue.sql

If the project needs a development environment, add the appropriate --environment value to the command. The important part is to keep the scope small until the result is understood.

Inspect after the command succeeds

  • Compare row counts with the expected interval.
  • Check for duplicate keys at the model's grain.
  • Inspect a few known records and recent source updates.
  • Read failed or warning checks instead of treating them as noise.
  • Check lineage when a downstream report changes unexpectedly.

Sign up to our newsletter

Practical updates on open-source data pipelines, AI analysts, governance, and what we are shipping at Bruin.