Data Quality

Kurzzusammenfassung

• Das DQ-Gate steuert, ob Daten in Feature-Training, Backtests und Scoring eingehen dürfen.
• Business-Nutzen: stabilere Modellqualität und weniger Fehlalarme im Betrieb.
• BPMN-Leitpfad: Task Execute DQ suite → Gateway Pass/Warn/Fail → Outcome Release/Flag/Quarantine.
• Gate-Logik: DQ-Fail blockiert Gate B (Pilot Ready) automatisch.

Ziel

Pro Dataset ist der aktuelle DQ-Status inkl. Regelverletzung, Severity und Verantwortlichkeit nachvollziehbar hinterlegt.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Execute DQ suite	Checks auf Schema, Vollständigkeit, Freshness, Outlier/Domain-Constraints	Artefakt: dq_report.json; Responsible: Data Engineering
Task: Persist DQ status	Status (pass/warn/fail) an Catalog-Entity + Partition schreiben	Artefakt: DQ-Stamp + Timestamp; Responsible: Data Steward
Gateway: Threshold met?	Domainspezifische Limits (z. B. Missing-Rate, Delay) auswerten	Fail: Quarantine + Incident; Accountable: Data Owner
Outcome: Release/Flag/Quarantine	Veröffentlichung, Warnmarkierung oder Isolierung	Artefakt: Release-Decision

DQ-Regeln verknüpft mit Gateway-Outcomes

Regelklasse	Beispielregel	PASS	WARN	FAIL	OVERRIDE
Schema	Pflichtspalten vorhanden, Datentypen korrekt	100 % erfüllt	nicht kritisch abweichend (z. B. neue optionale Spalte)	Pflichtspalte fehlt oder Typbruch kritisch	nur mit Data-Owner + Platform-Lead Freigabe, max. 24 h
Vollständigkeit	Missing-Rate pro kritischem Feld	≤ 0.5 %	> 0.5 % bis 2 %	> 2 %	nur für nicht-kritische Consumer, befristet
Freshness	Delay ggü. SLA	≤ SLA	bis +30 min	> +30 min	nur bei dokumentiertem Upstream-Incident
Referenz-/Domainkonsistenz	gültige Identifier/Range	≥ 99.9 %	99.0–99.9 %	< 99.0 %	nicht zulässig bei regulatorischen Feldern

Incident-Pfade je Outcome

Gateway-Outcome	Operative Wirkung	Incident-Pfad	Eskalation
Pass	Release für nachgelagerte Nutzung	kein Incident, nur Audit-Event	n/a
Warn	Release mit Flag und Ablaufdatum	Low/P3 Incident + Massnahmenplan innerhalb 1 Arbeitstag	bei > 3 Warns/7 Tage: Governance Board
Fail	Hard Stop, Quarantine	P2/P1 Incident innerhalb 10 min, Root-Cause-Task verpflichtend	Incident Manager → Head of Domain
Override	Zeitlich begrenzte Ausnahmefreigabe	Pflicht: verlinktes Incident + Risk Acceptance + Enddatum	automatisches Re-Approval nach 24 h

Override-Policy (formal)

• Ein Override darf nur erteilt werden, wenn ein aktiver Incident existiert und ein Workaround dokumentiert ist.
• Freigabekette: Data Owner (Accountable) + Incident Manager (Co-Approval).
• Overrides sind auf einzelne Datasets/Partitionen begrenzt und nicht vererbbar.
• Nach Ablauf erfolgt automatische Rückkehr zu warn oder fail, sofern keine neue Entscheidung dokumentiert ist.

Kontrollen

Governance- und Risiko-Aspekte

• DQ-Regelsätze sind versioniert; Änderungen brauchen fachliche Freigabe.
• Warnfreigaben sind zeitlich befristet und benötigen Risikoakzeptanz.
• Fail-Status erzeugt zwingend Incident-Link.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Ausführung Pflichtregeln je produktiver Partition	100 %	Data Engineering	fehlend: Hard Stop
Freshness-Verzug EOD-Daten	≤ 30 min gegen SLA	Data Owner	> 60 min: P2 Incident
Zeit bis Incident-Erstellung bei Fail	≤ 10 min	Platform Ops	> 15 min: Incident Manager

Entscheidung

• DQ-Status ist aktuell, versioniert und verlinkt.
• Gateway-Outcome ist fachlich freigegeben.
• Warn/Fail/Override-Fälle besitzen Massnahmen- und Eskalationsplan.

⋮⋮⋮

Quality Gates (BPMN: CallActivity)

• Schema-Konformität
• Nullwert-/Vollständigkeitsregeln
• Referenzdaten- und Identifier-Konsistenz
• Zeitliche Plausibilität / Freshness

Gate-Ergebnisse

• Pass: Veröffentlichung in Curated/Feature Layer
• Warn: Veröffentlichung mit Flag + Eskalation
• Fail: Hard Stop, Incident und Nacharbeit
• Override: befristete Ausnahme unter Risikoakzeptanz

BPMN-Kontext

• IDs: CallActivity_QualityGate, Gateway_DQDecision
• Input-Bezug: DQ-Suite-Ergebnisse (pass/warn/fail) inkl. Severity und Regelversion.
• Entscheidungsbezug: Gateway_DQDecision entscheidet Release, Warn-Flag oder Quarantäne; Gate-Standards sind zentral dokumentiert in /docs/research-risk/acceptance-criteria.
• Output-Bezug: Freigabe in Downstream-Pipeline oder Übergabe an ServiceTask_Quarantine/Incident.