Datakwaliteit als beleid: enforce en observe in de pipeline

Datakwaliteit wordt in veel datapijplijnen nog steeds behandeld als iets wat in code verstopt zit. Er is ergens een if-statement, ergens een drempelwaarde, ergens een waarschuwing in een notebook. Zolang de engineer die het gebouwd heeft nog in de buurt is, lijkt dat werkbaar. Maar zodra de vraag bestuurlijk wordt, schiet die werkwijze tekort. Dan is niet voldoende dat een controle “ongeveer zo werkt”. Dan moet duidelijk zijn welke regel gold, waarom die gold en wat er gebeurde toen de check faalde.

Precies daar maakt Latero Runtime een principiële keuze. Niet de notebook bepaalt wat zwaar genoeg is om te blokkeren. Dat ligt vast in configuratie, in versiebeheer, per stap van de keten.

Wat de policy in de praktijk vastlegt

Een kwaliteitscheck in Latero Runtime heeft altijd drie vaste eigenschappen.

check_id is de naam van de controle. Daarmee koppelt Latero Runtime een concrete checkfunctie aan het beleid dat ervoor geldt.

mode bepaalt het gedrag bij een mislukking. In enforce-modus stopt de verwerking. In observe-modus loopt de pipeline door, maar wordt de afwijking wel volledig vastgelegd.

severity zegt iets over de ernst van de bevinding. In observe-modus bepaalt dat hoe zwaar de melding meeweegt in logging en opvolging. In enforce-modus verandert severity niets aan de hoofdregel: een mislukking blijft blokkerend.

Dat klinkt eenvoudig, maar het effect is groot. De beslissing om wel of niet door te gaan verdwijnt uit de notebooklogica en wordt een expliciet beleidsbesluit.

Een voorbeeld van check policy configuratie

In een Latero Runtime-implementatie staat het checkbeleid in configuratie die door de consumer wordt beheerd. Een verkorte weergave ziet er zo uit:

check_policy:
  landing_to_raw:
    files_present:
      severity: low
      mode: observe
      check_category: volume
    checksum_match:
      severity: high
      mode: enforce
      check_category: validity
    timeliness_sla:
      severity: medium
      mode: observe
      check_category: timeliness

  raw_to_bronze:
    files_present:
      severity: high
      mode: enforce
      check_category: volume
    all_columns_present:
      severity: high
      mode: enforce
      check_category: schema
    column_type_match:
      severity: high
      mode: observe
      check_category: schema
    row_count_match:
      severity: high
      mode: enforce
      check_category: volume

  bronze_to_silver:
    mapping_present:
      severity: high
      mode: enforce
      check_category: referential
    null_rate_in_range:
      severity: high
      mode: enforce
      check_category: completeness
    no_schema_drift:
      severity: high
      mode: enforce
      check_category: schema

  silver_to_gold:
    mapping_present:
      severity: high
      mode: enforce
      check_category: referential
    null_rate_in_range:
      severity: high
      mode: enforce
      check_category: completeness
    timeliness_sla:
      severity: high
      mode: observe
      check_category: timeliness

Het patroon is helder. Vroeg in de keten is er meer ruimte om signalen te observeren. Naarmate data dichter bij silver en gold komt, wordt het beleid strenger. Dat is logisch: hoe later een fout ontdekt wordt, hoe groter de impact.

Waarom dit beter werkt dan logica in code

Het belangrijkste verschil is niet technisch maar organisatorisch. Als een engineer timeliness_sla in code van blokkerend naar niet-blokkerend verandert, is dat achteraf moeilijk terug te vinden. Als dezelfde wijziging in YAML gebeurt, is het een expliciete beleidswijziging met auteur, commit en datum.

Dat maakt discussies ook zuiverder. Dan gaat het niet langer over de vraag of “de notebook dit toevallig doet”, maar over de vraag of een bepaalde controle op een bepaald punt in de keten terecht op observe of enforce staat.

Drie concrete beleidsafwegingen

Bij landing_to_raw is checksum_match terecht enforce. Als een bestand onderweg wijzigt, is de rest van de keten onbetrouwbaar geworden. Doorgaan heeft dan geen zin.

Bij raw_to_bronze is all_columns_present ook enforce. Ontbreekt in een levering een verwacht veld, dan kan geen betrouwbare bronze-tabel worden opgebouwd.

Bij bronze_to_silver is null_rate_in_range cruciaal voor elk numeriek veld dat later in rapportages verschijnt. Dit zijn geen willekeurige checks; het zijn precies de velden waarop de bruikbaarheid van de volgende laag rust.

Wat dit bestuurlijk oplevert

Latero Runtime legt elke uitgevoerde controle vast in de kwaliteitsregistratie, inclusief check_id, uitkomst, severity, mode en details. Daardoor is later niet alleen zichtbaar dat een controle is uitgevoerd, maar ook welk beleid op dat moment gold.

Dat is de kern van het verschil tussen “we doen kwaliteitschecks” en “we kunnen aantonen hoe kwaliteitsbeleid in de pipeline is toegepast”.