Model Registry

Kurzzusammenfassung

• Model Registry steuert kontrollierte Stage-Transitions von Research bis Production.
• Business-Nutzen: weniger Produktionsrisiko durch nachvollziehbare Freigaben.
• BPMN-Leitpfad: Task Register candidate version → Gateway Transition gates passed? → Outcome Stage changed/held.
• Qualitätsregel: Keine Transition ohne vollständiges Validierungs- und Repro-Paket.

Ziel

Registry-Transitions sind technisch, fachlich und regulatorisch abgesichert und über Audit-Trail nachvollziehbar.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Register candidate version	Candidate-Run als Modellversion anlegen	Artefakt: Model Version; Responsible: ML Engineer
Task: Attach validation package	Performance-, Robustheits-, Bias-, Betriebschecks anhängen	Artefakt: Validation Package; Responsible: ML Validation
Gateway: Transition gates passed?	Checks für Quality/Risk/Repro/Ops-Readiness	Nein: Stage hold; Accountable: Model Owner
Outcome: Stage changed/held	Transition zu Staging/Production oder Halt mit Auflagen	Artefakt: Transition Decision Log

Kontrollen

Governance- und Risiko-Aspekte

• Für Production sind fachlicher + technischer Sign-off Pflicht.
• Registry-Objekt referenziert Daten-, Feature- und Code-Version.
• Rollback-Kandidat muss vor Production-Transition existieren.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Vollständiges Validation Package bei Transition	100 %	ML Validation	Transition-Block
Durchlaufzeit Stage-Review	≤ 2 Arbeitstage	Model Owner	> 2 Tage: Governance Board
Prod-Modelle ohne Rollback-Kandidat	0	MLOps	sofortige P1-Eskalation

Entscheidung

• Transition-Gates sind vollständig geprüft und signiert.
• Registry-Eintrag enthält alle Referenzartefakte.
• Rollback-Readiness ist nachgewiesen.

Stage-Transition-Gates (verpflichtend)

Jede Stage-Transition ist nur zulässig, wenn alle Gate-Nachweise vorliegen und versioniert referenziert sind.

Transition	Gate	Pflichtnachweis	Ablehnungsgrund
Research → Staging	Backtest-Gate	Backtest-Report mit Zeitraum, Kostenmodell, KPI-Delta vs. Baseline	Kein belastbarer Out-of-Sample-Nachweis
Research → Staging	Drift-Baseline-Gate	Dokumentierte Drift-Baseline (Features + Targets) inkl. Schwellenwerte	Keine Baseline für späteres Drift-Monitoring
Staging → Production	Approval-Record-Gate	Signierter Approval-Record (Model Owner, Risk, ggf. Compliance)	Fehlender/unklarer Freigabeentscheid
Staging → Production	Rollback-Plan-Gate	Ausführbarer Rollback-Plan mit RTO/RPO, Triggern und Verantwortlichen	Kein testbarer Rückfallpfad

Mindestanforderungen je Pflichtnachweis

• Backtest: enthält mindestens Datenfenster, Turnover-/Kostenannahmen, KPI-Unsicherheit (z. B. Konfidenzintervall) und Failure-Cases.
• Drift-Baseline: enthält Referenzverteilungen, Segmentierung, Alert-Schwellen und Verantwortliche für Re-Baselining.
• Approval-Record: enthält Entscheider, Entscheidung, Bedingungen, Laufzeit von Ausnahmen und Verweis auf Evidenz.
• Rollback-Plan: enthält technische Schritte, Kommunikationsplan, maximal akzeptierte Downtime und letzte stabile Version.

Einheitliches Decision-Log-Feldset

Alle Stage-Entscheidungen (promote, hold, reject) nutzen den einheitlichen Feldsatz gemäss Decision Logging.

Feld	Pflicht	Beschreibung
decision_id	Ja	Eindeutige ID
decision_timestamp	Ja	UTC-Zeitpunkt
decision_outcome	Ja	accept, reject, override
decision_rationale	Ja	Entscheidungsbegründung
registry_model_version	Ja	Betroffene Modellversion
target_stage	Ja	Zielstage (staging/production)
backtest_report_ref	Ja	Referenz auf Backtestnachweis
drift_baseline_ref	Ja	Referenz auf Drift-Baseline
approval_record_ref	Ja	Referenz auf Freigabedokument
rollback_plan_ref	Ja	Referenz auf Rollback-Plan

Glossar-Begriffe

Diese Seite nutzt die kanonischen Begriffe Model, Promotion, MLflow Model Version und Registry Stage.

Versionierung

Jede Modellversion verweist auf Trainingsdaten, Code-Commit und Evaluationsreport.

Stages

• Research
• Staging
• Production
• Archived