Promotion Strategy

Kurzzusammenfassung

• Promotion Strategy regelt den Weg vom validierten Candidate in den produktiven Betrieb.
• Business-Nutzen: höhere Produktionsstabilität bei nachvollziehbaren Release-Entscheidungen.
• BPMN-Leitpfad: Task Run promotion checks → Gateway All promotion gates passed? → Outcome Promote/hold/rollback.
• Gate-Logik: Entspricht Gate C (Production Ready) mit explizitem Fallback.

Ziel

Promotion erfolgt nur bei erfüllten KPI-, Risiko-, Repro- und Betriebsanforderungen sowie dokumentierter Rollback-Strategie.

Ablauf

BPMN-Schritt	Mechanik (Task/Gateway/Outcome)	Artefakte & Verantwortlich
Task: Build promotion dossier	Candidate-Evidenz aus Tracking/Registry/Monitoring bündeln	Artefakt: Promotion Dossier; Responsible: Model Owner
Task: Execute promotion gates	Automatisierte + manuelle Checks (KPI, Drift-Risiko, Ops-Readiness)	Artefakt: Gate Report; Responsible: MLOps + Risk
Gateway: All promotion gates passed?	Entscheidung Promote/Hold/Reject mit Auflagen	Hold/Reject: Massnahmenplan; Accountable: Approval Board
Outcome: Promote/rollback	Stage-Transition oder Rückfall auf letzte stabile Version	Artefakt: Release Decision

Kontrollen

Governance- und Risiko-Aspekte

• Candidate muss reproduzierbar in Zielumgebung validiert sein.
• Canary/Shadow-Rollout ist für kritische Use Cases verpflichtend.
• Ausnahmen sind befristet und explizit freigegeben.

Messbare Akzeptanzkriterien

Kriterium	Grenzwert	Verantwortlich	Eskalation
Erfüllte Promotion-Gates vor Transition	100 %	Approval Board	Promotion-Block
KPI-Delta vs. Baseline (Primary KPI)	≥ +2 % oder genehmigte Ausnahme	Model Owner	Hold + Review
Eskalationszeit bei Gate-Fail (prod-nah)	≤ 30 min	MLOps On-Call	> 30 min: P1 Incident

Entscheidung

• Promotion-Dossier und Gate-Report sind vollständig.
• Reproduzierbarkeit und Transition sind verifiziert.
• Rollback-/Incident-Plan ist freigegeben.

Übergang Research → Prod

• technische Validität (Stabilität, Laufzeit)
• fachliche Validität (Backtesting, Robustheit)
• Governance-Freigabe (Risk/Compliance)

Rollback

Bei Drift oder KPI-Verletzung erfolgt Rückfall auf letzte freigegebene Version.

Trennung: Technische Promotion vs. fachliche Freigabe

Promotion wird in zwei strikt getrennte Entscheidungsräume aufgeteilt. Eine technische Freigabe ersetzt nicht die fachliche Freigabe.

Entscheidungsebene	Zweck	Verantwortlich	Ergebnis
Technische Promotion	Nachweis, dass Modell in Zielplattform sicher und stabil betrieben werden kann	MLOps + ML Engineering	tech_ready = true/false
Fachliche Freigabe	Nachweis, dass fachlicher Nutzen, Risikoakzeptanz und Policy-Konformität erfüllt sind	PM + Risk (ggf. Compliance)	business_approved = true/false

Mindestgates technische Promotion

• Reproduzierbarer Deploy-Build inkl. identischem Environment Fingerprint.
• Erfolgreicher Smoke-/Canary-Test in prod-naher Umgebung.
• Monitoring-, Alerting- und Rollback-Mechanik aktiv.

Mindestgates fachliche Freigabe

• PM bestätigt Ziel-KPI und Business-Kontext.
• Risk bestätigt Risikoakzeptanz, Limitkonformität und Ausnahmebehandlung.
• Bei High-Risk-Use-Cases: Compliance-Zeichnung vorhanden.

Handshake mit PM/Risk-Gates (verpflichtend)

Die produktive Aktivierung erfolgt nur bei erfolgreichem Handshake zwischen Technik und Fachbereich.

Schritt	Gate	Prüfnachweis	Blocker
1	TECH_GATE_PASS	Gate-Report mit Deploy-, Canary-, Monitoring-Checks	technische Instabilität/offene Incidents
2	PM_GATE_PASS	PM-Freigabe mit KPI-Zielbild und Scope	unklarer Business-Impact
3	RISK_GATE_PASS	Risk-Freigabe inkl. Limit- und Szenarioprüfung	offene Risikoauflagen
4	JOINT_RELEASE_ACK	gemeinsamer Release-Record (PM + Risk + MLOps)	fehlende End-to-End-Verantwortung

Handshake-Regeln:

• Kein RISK_GATE_PASS ohne gültigen technischen Gate-Report.
• JOINT_RELEASE_ACK ist nur innerhalb von 24h nach PM/Risk-Freigabe gültig; danach Re-Check.
• Overrides sind zeitlich befristet und müssen ein exception_expiry enthalten.

Einheitliches Decision-Log-Feldset

Alle Promotionentscheidungen müssen mit dem Standard-Feldsatz aus Decision Logging dokumentiert werden.

Feld	Pflicht	Beschreibung
decision_id	Ja	Eindeutige ID
decision_timestamp	Ja	UTC-Zeitstempel
decision_outcome	Ja	accept, reject, override
decision_rationale	Ja	Begründung inkl. Gate-Status
tech_gate_report_ref	Ja	Referenz technischer Gate-Report
pm_gate_ref	Ja	Referenz PM-Freigabe
risk_gate_ref	Ja	Referenz Risk-Freigabe
joint_release_ack_ref	Ja	gemeinsamer Handshake-Record
rollback_plan_ref	Ja	verknüpfter Rollback-Plan
exception_expiry	Bedingt	Pflicht bei Override