Why it exists
The job passed.
The dashboard is still wrong.
Most analytics reliability issues don't begin with a crash. They begin quietly — and by the time a stakeholder notices, the bad numbers have already been in three board reports.
FAILURE MODE 01
A filter moves from JOIN to WHERE
A LEFT JOIN becomes an inner join. Active customers with no orders disappear from retention metrics. The diff looks fine. CI passes.
Silent — hours to daysFAILURE MODE 02
A source table arrives half-full
The ingestion job completes. Row count is below baseline. Three downstream models rebuild on partial data before anyone checks.
Detectable — if you're watchingFAILURE MODE 03
A schema change breaks a downstream model
A column is renamed upstream. The model that depends on it keeps running — returning NULLs until someone queries it directly.
Silent — days to weeksFAILURE MODE 04
Stale data flows into live dashboards
The scheduler misses a window. The model rebuilds from a timestamp that's 48 hours old. The dashboard keeps loading — with yesterday's numbers.
Detectable — with freshness checksRelium is built for these quiet failures. It looks at metadata, SQL structure, and lineage so teams can catch anomalies before the first confused stakeholder asks why the numbers changed.
The goal is not to replace dbt. The goal is to add an evidence layer around dbt and SQL pipelines — what changed, what might be broken, which downstream models are exposed, and what to check first.
The current MVP was built and tested on a 511,000-row synthetic e-commerce warehouse with source tables, dbt-style models, multi-hop lineage, SQL risk detection, Slack alerts, and incident reports.