Orchestrators
dbt
manifest.json is the model graph; run_results.json is what actually happened. Both are artefacts, not APIs.
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.
What Decim reads from dbt
Every item below is read-only, and each is a specific view, endpoint or file rather than a category of access. If something here is unacceptable in your environment, it can be removed from the query catalogue — see the agent for how that works.
| 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 required
Written out in full, because "read-only access" is not a specification. Nothing below grants the ability to write, and row access is requested only on the specific tables you name.
# dbt Core: artefacts are written to target/ on every invocation.
# Point the agent 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 builds
What this source contributes 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
Nodes learned from a definition are marked declared; nodes observed running are marked observed; nodes both declared and observed are verified. Where two sources disagree, the disagreement is recorded as a drift note rather than resolved silently.
Failure modes it surfaces
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.
| 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 integration cannot tell you. Stated because an investigation that overstates its sources produces confident wrong answers, which is worse than an honest blocked.
- 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.