Zentrale Konzepte

Kurzzusammenfassung

• Diese Seite definiert die fünf verbindlichen Kernbegriffe für alle Prozessseiten und BPMN-Verknüpfungen.
• Business-Nutzen: einheitliche Sprache zwischen Fachbereich, Data/ML-Engineering, Governance und Operations.
• Prozess-Nutzen: jeder Begriff ist an klare Artefakte (OpenMetadata, MLflow, Prefect) und BPMN-Knotenklassen gebunden.
• Kontroll-Nutzen: Pflichtmetadaten und Anti-Patterns verhindern uneinheitliche Freigaben und Audit-Lücken.

Glossar-Referenz (kanonische Begriffe)

Diese Seite verwendet ausschliesslich die kanonischen Begriffe aus dem Glossary: Signal, Feature, Model, Data Product, Promotion, Data Pipeline, DQ, MLflow, Prefect, OpenMetadata.

Verbindliche Kernbegriffe

1) Signal

Fachliche Definition
Ein Signal ist eine zeitbezogene, fachlich interpretierbare Aussage mit Entscheidungsrelevanz (z. B. Risikoanstieg, Trendbruch, Qualitätswarnung), die als Input für Priorisierung, Selektion oder Eskalation dient.

Technische Repräsentation im Stack

• OpenMetadata-Entity: Table/Topic inkl. signal_type, domain, freshness_sla als Tags/Properties.
• MLflow: Run-Artefakt (signal_report.json) mit zugehörigen Metriken und Datenreferenzen.
• Prefect: Flow-Task-Output (signal_payload) inkl. Run-ID und Timestamp.

Minimale Pflichtmetadaten

• signal_id (stabil, eindeutig)
• event_time und as_of_time
• source_dataset + Version/Partition
• owner (fachlich) und producer (technisch)
• quality_status (passed, warning, failed)

Typische Anti-Patterns

• Signal ohne eindeutigen Zeitbezug oder ohne as_of_time.
• Fachliche Bedeutung nur im Code, nicht in Metadaten dokumentiert.
• Signal wird direkt als Modellfreigabe interpretiert (Semantik-Verwechslung).

BPMN-Knotenklassen & zugehörige Seiten

• Task: Erzeugung/Anreicherung im Pipeline-Schritt (/docs/orchestration-prefect/flows, /docs/data-catalog-openmetadata/ingestion).
• Gateway: Plausibilitäts- oder Qualitätsentscheidung (/docs/data-catalog-openmetadata/data-quality, /docs/data/quarantine).
• User Task: Fachliche Prüfung bei Grenzfällen (/docs/research-risk/manual-data-review).
• End Event: Signal veröffentlicht oder verworfen (/docs/consumption/publish-dashboard, /docs/observability/alerts).

2) Feature

Fachliche Definition
Ein Feature ist eine reproduzierbar berechnete, modellierbare Eingangsvariable mit klarer Herleitung, Versionierung und Qualitätsbewertung.

Technische Repräsentation im Stack

• OpenMetadata-Entity: Table/View im Feature-Store-Kontext inkl. Lineage zu Rohdaten und Labels.
• MLflow: Run-Parameter/Tags für feature_view, feature_set_version, optional Feature-Importance-Artefakte.
• Prefect: Materialisierungs-Artefakt aus Feature-Flow (z. B. feature_batch.parquet + DQ-Report).

Minimale Pflichtmetadaten

• feature_name und feature_version
• entity_key und join_key
• calculation_logic_ref (Code/SQL-Referenz)
• freshness + valid_from/valid_to
• dq_status und letzter DQ-Check-Zeitpunkt

Typische Anti-Patterns

• Leakage durch Nutzung von Zukunftsinformationen.
• Unversionierte Feature-Definitionen („silent changes“).
• DQ-Status fehlt, obwohl Feature produktiv verwendet wird.

BPMN-Knotenklassen & zugehörige Seiten

• Task: Feature-Berechnung und Materialisierung (/docs/data/feature-store, /docs/orchestration-prefect/flows).
• Gateway: DQ-Gate vor Weitergabe (/docs/data-catalog-openmetadata/data-quality, /docs/data/quarantine).
• User Task: Manuelle Freigabe bei auffälliger Distribution (/docs/research-risk/manual-data-review).
• End Event: Feature-Set als konsumierbares Artefakt bereitgestellt (/docs/data/warehouse, /docs/consumption/api).

3) Model

Fachliche Definition
Ein Model ist eine versionierte Abbildungslogik, die aus Features eine Vorhersage, ein Ranking oder eine Entscheidungsempfehlung erzeugt.

Technische Repräsentation im Stack

• OpenMetadata-Entity: MLModel-bezogene Dokumentation/Lineage-Verweise (mindestens Verknüpfung auf Daten- und Feature-Assets).
• MLflow: Run + registrierte ModelVersion mit Stage-Historie.
• Prefect: Trainings-/Evaluations-Flow-Artefakte (train_report, eval_report, model_uri).

Minimale Pflichtmetadaten

• model_name, model_version, run_id
• training_data_ref und feature_set_version
• Kernmetriken inkl. Evaluationszeitpunkt
• code_sha + Runtime/Image-Referenz
• model_owner + Freigabestatus

Typische Anti-Patterns

• Modellversion ohne nachvollziehbare Datenreferenz.
• Registry-Transition ohne validiertes Evaluationspaket.
• Produktionseinführung ohne definierten Rollback-Kandidaten.

BPMN-Knotenklassen & zugehörige Seiten

• Task: Training, Logging, Registry-Eintrag (/docs/ml-lifecycle-mlflow/experiments, /docs/ml-lifecycle-mlflow/tracking, /docs/ml-lifecycle-mlflow/model-registry).
• Gateway: Reproduzierbarkeit/Quality-Gates (/docs/ml-lifecycle-mlflow/tracking, /docs/research-risk/acceptance-criteria).
• User Task: Formale Freigabeentscheidung (/docs/research-risk/approval-process).
• End Event: Modellversion in Ziel-Stage fixiert (/docs/ml-lifecycle-mlflow/promotion-strategy, /docs/serving/deployment).

4) Data Product

Fachliche Definition
Ein Data Product ist ein fachlich verantwortetes, wiederverwendbares Datenangebot mit klaren Qualitätszielen, SLA und Nutzungskontext.

Technische Repräsentation im Stack

• OpenMetadata-Entity: primär Dataset/Table mit Ownership, Purpose, Policy, SLA, Lineage.
• MLflow: Referenzierte Input-/Output-Datensätze als Run-Tags/Artefakte (Nachvollziehbarkeit, nicht Primärspeicher).
• Prefect: Publikationsartefakt eines Flows (Version, Schema, DQ-Resultat, Publish-Status).

Minimale Pflichtmetadaten

• product_name + domain
• owner und steward
• purpose/zugelassener Nutzungskontext
• sla_freshness und dq_slo
• access_policy und Klassifikation

Typische Anti-Patterns

• „Datenablage“ ohne benannten Owner als Data Product deklarieren.
• Zweckbindung fehlt oder widerspricht tatsächlicher Nutzung.
• SLA wird genannt, aber nicht überwacht.

BPMN-Knotenklassen & zugehörige Seiten

• Task: Ingestion, Katalogisierung, Publikation (/docs/data-catalog-openmetadata/ingestion, /docs/data-catalog-openmetadata/purpose, /docs/consumption/publish-dashboard).
• Gateway: Governance-/Policy-Gate (/docs/data-catalog-openmetadata/ownership, /docs/research-risk/approval-process).
• User Task: Steward-/Owner-Freigabe (/docs/data-catalog-openmetadata/ownership).
• End Event: Data Product offiziell publiziert und konsumierbar (/docs/consumption/users, /docs/consumption/dashboard).

5) Promotion

Fachliche Definition
Promotion ist der kontrollierte Übergang einer Modellversion zwischen freigegebenen Stages (z. B. Research → Staging → Production) auf Basis dokumentierter Gates.

Technische Repräsentation im Stack

• OpenMetadata-Entity: Auditierbarer Verweis auf freigegebene Modellversion und zugehörige Datenprodukte.
• MLflow: Stage-Transition einer ModelVersion inkl. Comment, Approver, Timestamp.
• Prefect: Orchestrierter Promotion-Flow mit Gate-Checks und Deployment-Trigger.

Minimale Pflichtmetadaten

• model_version + from_stage + to_stage
• approval_ref (Ticket/Entscheidungsprotokoll)
• Nachweise für repro_check, dq_check, risk_check
• approver + Zeitstempel
• rollback_version (verpflichtend für Production)

Typische Anti-Patterns

• Stage-Wechsel per Ad-hoc-Klick ohne Gate-Nachweise.
• Tracking vollständig, aber keine Registry-Transition-Dokumentation.
• Production-Promotion ohne Rückfallpfad.

BPMN-Knotenklassen & zugehörige Seiten

• Task: Candidate registrieren, Deployment vorbereiten (/docs/ml-lifecycle-mlflow/model-registry, /docs/serving/deployment).
• Gateway: Gate-Entscheidung für Transition (/docs/ml-lifecycle-mlflow/promotion-strategy, /docs/research-risk/acceptance-criteria).
• User Task: Governance-/Risk-Sign-off (/docs/research-risk/approval-process).
• End Event: Promotion abgeschlossen oder blockiert (/docs/observability/decision-logging, /docs/orchestration-prefect/incident-management).

Abgrenzungen

Tracking vs Registry

• Tracking dokumentiert wie ein Run entstanden ist (Parameter, Metriken, Artefakte, Reproduzierbarkeit).
• Registry steuert welche Modellversion in welcher Stage eingesetzt werden darf.
• Konsequenz: vollständiges Tracking ist notwendige, aber nicht hinreichende Bedingung für Promotion.

DQ-Check vs Governance-Freigabe

• DQ-Check prüft technische/fachliche Datenqualität (Vollständigkeit, Freshness, Plausibilität).
• Governance-Freigabe bewertet Zweckbindung, Risiko, Verantwortlichkeit und Regelkonformität.
• Konsequenz: bestandener DQ-Check ersetzt keine formale Freigabeentscheidung.

Signal vs Feature

• Signal ist fachlich interpretierter Hinweis für Entscheidung oder Monitoring.
• Feature ist modelltechnische Eingangsvariable mit reproduzierbarer Berechnung.
• Konsequenz: ein Signal kann aus Features abgeleitet sein, ist aber kein automatisches Trainingsfeature.

Data Product vs Modellartefakt

• Data Product ist ein konsumierbares, dauerhaft verantwortetes Datenangebot.
• Modellartefakt ist ein technisches Ergebnis eines konkreten Runs/Versionierungsstands.
• Konsequenz: Modellartefakte sind Inputs für Betrieb, aber kein Ersatz für Data-Product-Governance.

Navigationshilfe („Wenn X unklar ist, dann Seite Y“)

• Wenn Pflichtmetadaten im Katalog unklar sind → /docs/data-catalog-openmetadata/ingestion.
• Wenn DQ-Regeln und Quarantänepfade unklar sind → /docs/data-catalog-openmetadata/data-quality und /docs/data/quarantine.
• Wenn Feature-Herleitung oder Feature-Versionierung unklar ist → /docs/data/feature-store.
• Wenn Run-Reproduzierbarkeit unklar ist → /docs/ml-lifecycle-mlflow/tracking.
• Wenn Stage-Wechsel/Promotion-Gates unklar sind → /docs/ml-lifecycle-mlflow/model-registry und /docs/ml-lifecycle-mlflow/promotion-strategy.
• Wenn Freigabe- und Verantwortungsprozess unklar ist → /docs/research-risk/approval-process.
• Wenn BPMN-Linking-Konventionen unklar sind → /docs/development/bpmn-linking.