Pipeline topology
Your repository names three targets. We observed four.
Code is one source of truth among several, and often not the primary one. Decim builds the graph from every provider it can reach, and is honest about where they disagree.
Every node carries its provenance
Coverage is the share of your topology that is genuinely verified — not a diagram that merely looks confident.
verified
In a definition and observed running
Both worlds agree. This is the part of your pipeline you can trust.
declared
Written down, never observed
A dead branch, or a step that silently stopped. Both are worth knowing about.
undocumented
Running, in no definition
The reject table nobody created on purpose. Frequently where your missing rows went.
drifted
Defined twice, and they disagree
A mapping in the repository and a mapping in the database. Only one of them executes.
Where the picture comes from
Source control
GitHub, GitLab, Bitbucket, Azure DevOps — files, commits, diffs and pull requests.
Database catalogs
Tables, foreign keys, and stored procedure bodies read from sys.sql_modules.
Schedulers
SQL Agent jobs in msdb, cron, systemd timers, and the steps inside them.
Cloud services
Where the definition lives in a service rather than a repository — Glue, Data Factory.
Runtime observation
What the agent actually watched happen. Works with no repository connected at all.
Tracing
Per-stage row counts from OpenTelemetry spans, wherever a pipeline is instrumented.
Get started
Bring us a pipeline that broke last week
The fastest way to evaluate this is a real incident you already know the answer to. If Decim gets it wrong, that is a far more useful demo than one where it doesn't.