Orchestrators
dbt — planned
manifest.json is the model graph; run_results.json is what actually happened. Both are artefacts, not APIs. This integration is planned: documented here as reference, not connectable from the admin today.
dbt's artefacts are unusually good. manifest.json is a complete
description of the model graph, including every test that is defined; run_results.json
records status and timing per node for an invocation. Together they answer which models ran,
how long each took, and which tests exist.
The more useful question is usually which tests do not exist. A well-tested project
full of unique and not_null assertions is validating the rows that
arrived; if rows were diverted upstream, every one of those tests passes.
dbt today
A dbt project kept in a connected GitHub repository is read as code during discovery, like
any other repository — models, sources and macros included. Run artefacts are not read yet,
but a run_results.json can be attached to the incident as a file and used as
evidence.
The sources that ship today are GitHub, Google Cloud Logging, Jira Cloud and the optional Windows agent. Everything below this point describes the planned dbt integration: what it is designed to read, and why.
What Decim will read from dbt
The intended read-only surface for this integration. It is reference material for the roadmap — and useful on its own, because these are the views and APIs worth knowing during an incident whether or not any tool reads them for you.
| What | From | Why it matters |
|---|---|---|
| Model graph | target/manifest.json | Nodes, sources, refs and the full lineage between them |
| Test definitions | manifest.json nodes of type test | And, by absence, which models have no coverage |
| Run outcomes | target/run_results.json | Status, execution time and message per node |
| Source freshness | target/sources.json | Max loaded_at per source, and whether it breached |
| Compiled SQL | target/compiled/** | What actually ran, after Jinja rendering |
| Materialisation | manifest.json node config | Table, view or incremental — decides the failure modes |
| Incremental strategy | node config incremental_strategy | Merge, append or delete+insert — the duplication risk |
Permissions it is designed around
Written out in full, because "read-only access" is not a specification. These are the grants the planned integration is designed around and may change before it ships. Nothing below grants the ability to write, and row access would be requested only on the specific tables you name. You do not need to create any of this today.
# dbt Core: artefacts are written to target/ on every invocation.
# A planned agent would be pointed at wherever CI persists them.
/opt/dbt/project/target/manifest.json
/opt/dbt/project/target/run_results.json
/opt/dbt/project/target/sources.json
# Read-only ACL, same pattern as any other log directory.
setfacl -Rm u:decim-agent:rX /opt/dbt/project/target
# dbt Cloud: the same artefacts are retrievable per run.
GET /api/v2/accounts/{account}/runs/{run}/artifacts/manifest.json
GET /api/v2/accounts/{account}/runs/{run}/artifacts/run_results.json
# A read-only service token is sufficient.What it would build
What this source would contribute to the pipeline topology and to the evidence available during an investigation:
- The full transform graph, including source-to-model edges
- Which models have no tests — the coverage gap, stated explicitly
- Per-model duration, for the same anomaly check that works on Airflow tasks
- Incremental materialisation strategies, which predict the duplication failure modes
Today, topology is built from code in GitHub, and each connection is marked direct or inferred. The design direction for sources like this one is a provenance model: a step found in a definition is declared, a step seen running is observed, one that is both is verified, and where two sources disagree the disagreement is kept as a drift note rather than resolved silently. That model is planned, not shipped.
Failure modes it would surface
What this source is uniquely good at proving — and, just as usefully, at disproving. An investigation that can refute a hypothesis cheaply is worth as much as one that confirms it. Until the integration ships, the same signals can be checked by hand, or requested by Decim as a check your team runs.
| Failure mode | The signal |
|---|---|
| Model built with no rows | Execution time far below its own baseline |
| Duplicate rows after a backfill | Incremental strategy is append rather than merge |
| Loss upstream of dbt entirely | Source freshness breach with all model tests passing |
| Test never existed | Model present in manifest with no associated test nodes |
Limits
What this source cannot tell you, even once it is read. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest cause unclear.
- Artefacts describe dbt's view of the world and stop at its boundary — loss before
rawis invisible to them manifest.jsonreflects the project as compiled, so a model added and reverted between runs leaves no trace- Tests that were skipped rather than run appear with a status that is easy to misread as passing
Related integrations
- Apache Airflow — The metadata database holds connections, variables, pools and manual state — none of it in git.
- Snowflake — ACCOUNT_USAGE gives a year of query, copy and task history — including rows loaded and rows rejected.
- BigQuery — INFORMATION_SCHEMA.JOBS gives every statement, its referenced tables and its output row count.
See all integrations, or how the sources are combined into one graph.
Get started
Investigating a dbt pipeline?
Bring an incident you already know the answer to. If Decim gets it wrong, that is a more useful demo than one where it doesn't.