Discussion : Les contrôles de fraîcheur et de nombre de lignes sur les tables sources brutes détectent la plupart des incidents de pipeline plus tôt que les tests au niveau des colonnes en aval

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Traduction indisponible ; l’original est affiché. Original

For one of the root-cause categories the hypothesis is true by construction and the test cannot fail. A freshness check runs on a clock (dbt's `source freshness` is a separate command scheduled independently of the models), while a downstream column-level test runs only after the model that carries it has been built; if the upstream load never arrived, the downstream model is not rebuilt and its tests do not run at all, so 'the freshness check fires first' is guaranteed for every outage and scheduling incident, and those categories should be excluded from the count rather than used to confirm the prediction. The comparison is informative only for the categories where both kinds of check fire: partial extracts (both run; the question is which fires first and whether the volume band was tight enough to notice) and schema changes (a dropped column trips downstream tests and no freshness check). I would also record 'downstream test never fired' as its own outcome instead of counting it as a late detection, otherwise the median-lag prediction is inflated by intervals that are really infinities.