Redbook Pipeline

src/redbook/dbt turns the 5 raw Redbook tables — landed by Redbook Ingestion — into the reference data the Stock pipeline resolves a dealer's listing against. It's a small, uniform medallion pipeline: five raw tables, each walking the same raw → staging → intermediate → marts chain, on a fixed weekly schedule.

Medallion architecture: the same shape, five times over

Every raw table goes through the same four layers. Only the vehicles, makes, and families tables reach a mart — legacy map and cipher key stop at intermediate, because nothing downstream needs a curated view of either; they're consumed directly by Stock's key-resolution logic instead.

Every _stg model does the same three things: dedup the raw rows down to one per natural key, cast/trim the vendor columns, and generate a surrogate key. Every _int model is a pure pass-through of its _stg model plus an updated_at timestamp — no business logic is added at that layer. See Staging, dedup & marts for the actual dedup logic and why the project's own materialization config doesn't match what's really running.

How often this runs

One Snowflake task, REDBOOK_DBT_RUN_WEEKLY, runs the entire project — not a per-model schedule:

snippet.hclhcl

"REDBOOK_DBT_RUN_WEEKLY" = {
  database_key     = "SPECIFICATIONS_DB"
  schema_key       = "REDBOOK_SCHEMA"
  dbt_project_name = "REDBOOK_DBT"
  schedule_cron    = "0 10 * * FRI UTC"  # Every Friday at 10am UTC
  role             = "DRIVE_{ENV}_ROLE_DBT"
  schedule_type    = "cron"
  warehouse_key    = "DRIVE_WH"
}

Every Friday at 10:00 UTC — the Terraform comment calls this "9pm Sydney time (AEDT)"; that's only accurate during daylight saving. Outside DST, 10:00 UTC is 8pm AEST, an hour earlier than the comment states.
Runs dbt run unfiltered — no --select, so every model in the project runs every time, not just the ones with new data.
On warehouse DRIVE_WH, the same general-purpose warehouse dbt uses elsewhere (not a dedicated Redbook warehouse, unlike Stock's STOCK_WH).
Enabled in both staging and prod as checked in (enable_redbook_task defaults to true in both, with prod's own comment noting "weekly redbook updates needed").

This lines up with the vendor's own delivery cadence: Redbook emails a new data drop every Thursday, and the dbt task runs the following day.

At a glance


dbt project	`src/redbook/dbt`, target `SPECIFICATIONS_DB.REDBOOK_SCHEMA`
Raw tables	5 — vehicles, makes, families, legacy map, cipher key
Schedule	`REDBOOK_DBT_RUN_WEEKLY`, cron `0 10 * * FRI UTC`, unfiltered `dbt run`
Dedup pattern	`QUALIFY ROW_NUMBER() OVER (PARTITION BY <natural key> ORDER BY ingested_at DESC) = 1` in every staging model
Test posture	Project-wide `severity: warn` — failing tests don't block the weekly run
Consumed by	Stock's key-resolution logic, reading the intermediate layer directly — not the marts

Start here

What are the 5 raw tables, and how do they relate to the vendor's full data set? Raw ingestion & the Redbook data model — the ERD, and which of the vendor's 7 files this repo actually ingests.
How does dedup actually work, and what's the marts layer for? Staging, dedup & marts.
Where does NVIC fit in? NVIC mappings — a static seed this project publishes, consumed by Stock.