Acceptance Criteria

Kurzzusammenfassung

• Gateway_Acceptance ist der verbindliche Qualitäts- und Risiko-Gate vor Freigabe.
• Entscheidungen erfolgen ausschliesslich als promote, hold oder reject.
• Schwellenwerte, Guardrails und Ausnahmewege sind messbar und auditierbar definiert.
• Die Gate-Entscheidung referenziert reproduzierbare Evidenz aus MLflow, Prefect und OpenMetadata.

Gateway-Standard (verbindlich)

Entscheidungslogik

1. Prerequisites prüfen: vollständige Artefakte aus Backtesting, Portfolio Construction, Data Quality.
2. Hard Guardrails prüfen: Verletzung führt direkt zu reject (oder hold bei behebbarer operativer Ursache).
3. KPI-Schwellen prüfen: nur bei erfüllten Mindestwerten ist promote möglich.
4. Ausnahmen prüfen: nur befristet und dokumentiert über Gateway_ExceptionApproval.
5. Entscheidung protokollieren: inkl. Rationale, Owner, Zeitstempel, Referenz-IDs.

Messbare Schwellen (Mindeststandard)

Dimension	Promote-Schwelle	Hold-Bereich	Reject
OOS-Performance vs. Benchmark	Netto-Alpha > 0 und IR >= 0.5	IR 0.3-0.5	IR < 0.3 oder negatives Alpha
Stabilität über Folds/Regime	>= 70 % positive Folds, kein Regime-Kollaps	60-70 % positive Folds	< 60 % positive Folds
Risiko	Drawdown, VaR, Exposure innerhalb Limits	temporäre Grenznähe mit Mitigation	Hard-Limit-Verstoss
Umsetzbarkeit	Kosten/Slippage/Turnover im Budget	leichte Überschreitung mit Plan	signifikante Budgetüberschreitung
Reproduzierbarkeit	Lauf reproduzierbar (Daten, Code, Seeds)	Teilartefakte nachlieferbar	Reproduktion nicht möglich

Hard Guardrails (ohne Ausnahme für Promote)

• Kritischer Leakage-Befund.
• Fehlende Daten-Lineage oder unbekannter Data Owner.
• Unvollständiger Audit-Trail (kein run_id, kein flow_run_id, keine Sign-off-Identität).
• Verletzung regulatorischer Restriktionen (z. B. Instrument-/Marktbeschränkung).

Dokumentierte Ausnahmen (über Gateway_ExceptionApproval)

Eine Ausnahme ist nur gültig, wenn alle Bedingungen erfüllt sind:

• Konkreter Grund: technisch/fachlich mit Impact-Analyse.
• Zeitliche Begrenzung: eindeutiges Ablaufdatum oder max. Anzahl Läufe.
• Kompensationsmassnahmen: zusätzliche Kontrollen und engeres Monitoring.
• Owner + Genehmiger: benannte Rollen mit Sign-off.
• Reversion-Kriterium: klar, wann Ausnahme automatisch endet.

Zentrale Gate-Referenz

Die zentrale Gate-Entscheidungslogik wird ausschliesslich hier gepflegt:

• Gateway_DQDecision (DQ pass/warn/fail)
• Gateway_ExceptionApproval (befristete Ausnahme ja/nein)
• Gateway_Acceptance (promote/hold/reject)
• Gateway_Retrain (retrain auslösen ja/nein)

Unterseiten referenzieren diese Logik, um Duplikate zu vermeiden.

Sign-off-Datensatz (Pflichtfelder)

Feld	Beschreibung	Quelle
decision	promote, hold, reject	Approval Record
rationale	fachliche + risikobezogene Begründung	Approval Record
mlflow_run_id	Referenz auf Validierungsrun	MLflow
prefect_flow_run_id	Referenz auf Gate-Orchestrierung	Prefect
openmetadata_entity_ref	Referenz auf Modell-/Daten-Entity	OpenMetadata
exceptions	Liste aktiver Ausnahmen inkl. TTL	Exception Record
approvers	Rollen + Personen + Zeitstempel	Sign-off

Matrix-Gap-Check: Gateway_Acceptance

Status: schliessbar / abgedeckt, sofern folgende Evidenz im Gate-Paket vorhanden ist:

• Messbare KPI-Schwellen und Ergebnis je Schwelle,
• Guardrail-Ergebnis (pass/fail) inkl. Abbruchlogik,
• dokumentiertes Entscheidungslog mit Rationale,
• Tool-Referenzen (mlflow_run_id, prefect_flow_run_id, openmetadata_entity_ref).

BPMN-Kontext

• IDs: Gateway_Acceptance
• Input-Bezug: Validierungsartefakte aus Backtesting, Risikoanalyse und Portfolio-Konstruktion.
• Entscheidungsbezug: Zentrale Gate-Entscheidung (promote/hold/reject) für den Übergang in UserTask_Approval.
• Output-Bezug: Freigabepaket oder dokumentierter Rücksprung in Nacharbeit/Retrain.