dbt practices (Jarvus house conventions)

This is the opinionated layer: how Jarvus wants dbt models written, tested, and linted — not how to operate dbt. The mechanics (running commands, writing a unit-test YAML, dbt state, the semantic layer, mesh) are covered by dbt-labs' first-party skills; this skill defers to them and adds the house conventions, quality bar, and CI gate they don't carry.

Source of authority. The conventions here are distilled from our most mature dbt work — calitp-data-infra and wmata-tides-infra (TIDES / Cal-ITP) — and the modeling rules our dbt lead has set on in-flight projects. Treat those as authoritative over ad-hoc/AI-scaffolded patterns. Adapter examples use DuckDB (our TIDES stack) and BigQuery where they differ.

Maturity: first pass, pending dbt-lead review. This covers the model-quality half (conventions + testing + lint/CI). The deployment half (run/orchestration/publish patterns across DuckDB & BigQuery) is deliberately deferred to a second pass — see deployment.md.

The conventions at a glance