data_updater_v2.dbt.jobs

The dbt job census: named croppings over ONE dbt asset graph.

There is exactly one dbt asset graph (built from the manifest). Workloads crop it with dbt selection syntax; mode conveys execution intent through stable run tags (update incremental, build adds —full-refresh, repair accepts a JSON dbt/vars tag carrying explicit ids/dates to the same SQL). A readiness declaration beside a workload is its sensor: the raw products whose landings it waits for (sensors.readiness_probe); the configs row of the same name is its kill switch (sensors.execution_gate).

The workloads, as the graph grows (one per semantic unit, a repair beside it where the models keep state, the full build for a cold start):

facts_update          the facts graph in dependency order — the catalog (eras,
                      securities, the index spans, days and changes), the events
                      (splits, dividends), the daily prices, the intraday views, the
                      calendar-aligned crypto table, and the analytics views over them —
                      every night once the five daily price tables have landed for the
                      session (the universes, their changes and the calendar land by
                      schedule before them). The metric facts are not its (excluded):
                      two runs never rebuild one table at once
facts_metrics_update  the metric facts (``tag:metrics``: the listings', the short side's,
                      the coins') once the night's metrics have landed — the listings'
                      after their daily prices, the coins' last of all, after the coin
                      minutes (``jobs.metrics``) — so the night's counts, caps and coin
                      values are in the facts the same night
(both)                a required product whose update job is switched off is not waited on
                      (``sensors.readiness_probe``): the jobs come on one at a time
facts_repair      the daily price facts recomputed forward from a day (and the aligned
                  crypto table rewritten from it), by hand: a run tagged ``dbt/vars``
                  ``{"from": "2026-09-01", "symbols": ["TECL"]}`` (symbols optional)
                  reaches the same SQL
dbt_full_build    every model from scratch (--full-refresh): a cold start or a rebuild

Classes

LocationDbt

Front door: main.py calls LocationDbt.definitions() — nothing else.

definitions

definitions() -> dg.Definitions