Purpose + Entitlement + Governance Check (Gate A)

Kurzzusammenfassung

Diese Seite beschreibt Gate A: die verbindliche Prüfung von Zweckbindung (Purpose), Nutzungsrechten (Entitlements/Lizenzen) und Ownership für ein Dataset, bevor es im Hauptprozess weiterverwendet wird.
Gate A sitzt direkt nach der Ingestion (validated curated dataset + Output‑Contract) und vor dem Data Quality Gate. Es geht hier um “Darf dieses Dataset für diesen Use‑Case genutzt werden und ist es korrekt dokumentiert?” — nicht um DQ‑Metriken.
OpenMetadata ist der zentrale Ort für die Gate‑A‑relevanten Metadaten (Owner, Purpose, Classification, Entitlement‑Referenz, Links/Lineage‑Bezüge).
BPMN‑Leitpfad (Gate‑A‑Detail): Purpose / Use-Case Check → License / Entitlement Check → Ownership & Governance Metadata Check → Gate A passed.

Einordnung: Gate A ist Schritt 3 im Hauptprozess der Gesamtarchitektur und hängt fachlich an die Ergebnisse aus Ingestion (Data Pipeline: ELT + Validierung) an.

Ziel

Sicherstellen, dass jedes ingestierte Dataset einen klaren Zweck hat und im Kontext des Projekts (Stock‑Picking via Score) zulässig ist.
Sicherstellen, dass Entitlements/Lizenzen pro Provider/Dataset dokumentiert sind und zur geplanten Nutzung passen.
Sicherstellen, dass Ownership (Owner/Steward) und die wichtigsten Metadaten vollständig sind, bevor Downstream‑Schritte (DQ‑Gate, Feature Pipeline, Training) starten.

Scope & Abgrenzung

In Scope (diese Seite / Gate A):

Zweckbindung (Use‑Case / Allowed Use) pro Dataset
Entitlements/Lizenzen (Provider‑Bezug, Referenz, Nutzungskontext)
Ownership (Owner/Steward), Klassifikation, Retention
“Ownership & Governance Metadata Check” als Metadaten‑Vollständigkeitscheck (kein IAM-/Policy-Enforcement)
Markierung/Protokollierung des Gate‑A‑Ergebnisses (Run‑Artefakt + OpenMetadata‑Status)

Out of Scope (separate Schritte/Seiten):

Datenabruf, ELT‑Schritte, Output‑Contract‑Erzeugung → Ingestion (Data Pipeline)
DQ‑Regeln und PASS/FAIL‑Entscheidung → Data Quality Gate (Regeln)
Incident‑/Ticket‑Abläufe → Incident Management
Feature Engineering, Label Construction, Model Training, Backtesting, Portfolio Construction

Eingangssignale und Inputs

Gate A arbeitet mit drei Inputs, die im Projekt als “Source of Truth” gelten:

Validated Curated Dataset Contract (aus der Ingestion)
- enthält u. a. dataset_id, dataset_version, run_id, provider, allowed_use, classification, retention_policy, openmetadata_entity_ref, dq_report_uri
OpenMetadata Entity zum Dataset (Table/Topic) und zur Pipeline (Lineage/Run‑Kontext)
Entitlement‑Referenz je Provider/Dataset (wo diese Referenz gepflegt wird, ist projektintern; Gate A prüft, dass sie existiert und konsistent ist)

Gate A: was wird geprüft?

1) Purpose / Use‑Case Check

Gate A stellt sicher, dass das Dataset für den Projekt‑Use‑Case korrekt gebunden ist:

allowed_use ist gesetzt und entspricht dem Projekt‑Vokabular
Purpose/Use‑Case ist in OpenMetadata nachvollziehbar hinterlegt (Beschreibung, Glossary Term oder Custom Property)
Das Dataset ist im Kontext “Stock‑Picking via Score” vorgesehen (Research/Modeling/Scoring als Decision‑Support)

2) License / Entitlement Check

Gate A stellt sicher, dass pro Dataset die Nutzungsrechte sauber referenziert sind:

provider ist eindeutig (z. B. fmp, fred, sec_edgar)
eine Entitlement/Lizenz‑Referenz ist vorhanden (als Feld/Tag/Property in OpenMetadata oder im Contract)
die Entitlement‑Referenz passt zur Nutzung (z. B. “internal research/modeling”)

Typische Provider im Projekt:

FMP API: Preise (EOD), Corporate Actions, Fundamentals, optional Filings‑Ergänzungen
FRED API: Makro‑Zeitreihen (Rates/Indikatoren)
SEC EDGAR: Filings (10‑K/10‑Q/8‑K)

3) Ownership & Governance Metadata Check

Gate A stellt sicher, dass Ownership- und Governance-Metadaten kompakt und vollständig dokumentiert sind:

owner ist gesetzt und Accountable klar definiert
steward, classification und retention_policy sind konsistent gepflegt
optionale Felder wie intended_audience oder sharing_scope sind nachvollziehbar dokumentiert

Pflichtmetadaten in OpenMetadata (Gate‑A‑relevant)

Gate A erwartet, dass das curated Dataset in OpenMetadata mindestens folgende Felder trägt:

Feld / Property	Beispiel	Warum Gate A es braucht
`owner`	`data-platform` / Person/Team	Verantwortlichkeit für Changes, Freigaben, Rückfragen
`steward` (oder equivalent)	`data-steward`	Operativer Ansprechpartner für Datenpflege
`description`	“EOD OHLCV … (Quelle: FMP)”	Mindestdokumentation
`allowed_use`	`research_and_modeling`	Zweckbindung für Downstream‑Nutzung
`classification`	`external` (Raw) / `internal` (Curated)	Sichtbarkeit & Governance-Kontext
`retention_policy`	`standard`	Lifecycle / Aufbewahrung im Projekt
`provider`	`fmp` / `fred` / `sec_edgar`	Entitlement‑Bindung
`entitlement_ref`	`entitlement:fmp:<id>` / `public`	Nachweis, dass Nutzung geregelt ist
`intended_audience` (optional)	`research_team` / `internal_analytics`	Dokumentiert den beabsichtigten Empfängerkreis ohne technisches Durchsetzungs-Enforcement
`dq_suite_version` (oder Link/Tag)	`dq:v1`	Hinweis, dass DQ‑Kontrollen für Schritt 4 vorhanden sind
`lineage` (mind. upstream link)	Pipeline → Dataset	Nachvollziehbarkeit der Herkunft

Hinweis: Welche Felder als “Tag”, “Custom Property” oder “Glossary Term” gepflegt werden, ist eine Modellierungsentscheidung. Gate A prüft die Existenz und Konsistenz, nicht das UI‑Format.

Artefakte / Outputs von Gate A

Gate A erzeugt zwei Arten von Outputs:

Gate‑A Ergebnis als Run‑Artefakt (für den Prefect‑Run)
- gate_a_status: PASS | FAIL
- run_id
- dataset_id
- checked_at
- missing_fields[] (nur bei FAIL)
Gate‑A Status am Dataset in OpenMetadata
- gate_a_status (PASS/FAIL)
- gate_a_last_checked_run_id
- (optional) kurzer Kommentar oder Link zum Run‑Artefakt / Evidence‑URI

Die in der Architektur erwarteten Gate‑A‑Nachweise lassen sich damit direkt abbilden:

Zweckbindung (Purpose/Allowed Use)
Entitlement‑Referenz (Lizenz/Nutzungsrechte)
Owner‑Zuordnung (Owner/Steward)

Umsetzung im Projekt (pragmatisches Muster)

Gate A als Schritt im Prefect‑Flow

Gate A ist im Hauptprozess eine Business‑Rule‑Prüfung. In der Umsetzung ist das am einfachsten als dedizierter Schritt (Task/Subflow), der:

den Output‑Contract einliest,
die Dataset‑Entity in OpenMetadata referenziert (z. B. über openmetadata_entity_ref),
die Pflichtfelder validiert,
das Ergebnis als Run‑Artefakt persistiert und
bei FAIL den Run sauber stoppt (damit Schritt 4 nicht weiterläuft).

Pseudocode (nur zur Orientierung):

# flows/gates.py

def purpose_entitlement_gate(contract: dict) -> dict:
    missing = []

    # 1) Contract checks
    for field in ["dataset_id", "provider", "allowed_use", "classification", "retention_policy", "openmetadata_entity_ref"]:
        if not contract.get(field):
            missing.append(field)

    # 2) OpenMetadata checks (owner/steward/entitlement_ref/classification/retention_policy)
    # entity = openmetadata.get_entity(contract["openmetadata_entity_ref"])
    # if not entity.owner: missing.append("owner")
    # if not entity.entitlement_ref: missing.append("entitlement_ref")
    # ...

    status = "PASS" if not missing else "FAIL"
    return {"gate_a_status": status, "missing_fields": missing}

Wo werden Purpose/Entitlements gepflegt?

Im Projekt wird die Zweckbindung und Entitlement‑Referenz in OpenMetadata am Dataset geführt (plus Referenz in den Contracts). Das hat zwei Vorteile:

Gate A kann automatisiert prüfen, ob die Dokumentation vollständig ist.
Downstream‑Teams sehen Purpose/Owner/Status direkt am Dataset.

Entscheidung und typische Follow‑ups

Ein Gate‑A‑Run gilt als PASS, wenn:

alle Pflichtfelder vorhanden sind,
allowed_use, classification, retention_policy konsistent sind,
entitlement_ref vorhanden ist,
und ein DQ‑Setup für das nachfolgende Gate referenzierbar ist (dq_suite_version/Link).

Ein Gate‑A‑Run ist FAIL, wenn z. B.:

Owner/Steward fehlen,
Purpose/Allowed Use fehlt,
Entitlement‑Referenz fehlt oder Provider nicht eindeutig ist,
Klassifikation/Retention nicht gesetzt sind.

Follow‑up bei FAIL:

Metadaten in OpenMetadata ergänzen (Owner/Purpose/Entitlement/Retention),
danach den Ingestion‑Run erneut starten (oder nur Gate A erneut ausführen, falls als separater Schritt verfügbar).

BPMN‑Detailansicht

Diagramm wird geladen …

⋮⋮⋮

Glossar‑Begriffe

Data Product – Dataset + Verantwortung + Nutzungszweck
OpenMetadata – Katalog für Owner/Purpose/Lineage/Status
DQ – Datenqualitätsmessung (Schritt 4)
Output Contract – Übergabe‑Artefakt aus der Ingestion

BPMN‑Kontext

Main BPMN (Gate): CallActivity_PurposeGate – „Purpose + Entitlement + Governance Check (Gate A)“
Upstream: CallActivity_DataPipeline – „Datapipeline (ELT + Validierung)“
Downstream: CallActivity_QualityGate – „Quality Gate (Regeln)“
Detail‑Tasks (Gate A): BusinessRuleTask_Purpose, BusinessRuleTask_Entitlement, BusinessRuleTask_Governance

Kurzzusammenfassung​

Ziel​

Scope & Abgrenzung​

Eingangssignale und Inputs​

Gate A: was wird geprüft?​

1) Purpose / Use‑Case Check​

2) License / Entitlement Check​

3) Ownership & Governance Metadata Check​

Pflichtmetadaten in OpenMetadata (Gate‑A‑relevant)​

Artefakte / Outputs von Gate A​

Umsetzung im Projekt (pragmatisches Muster)​

Gate A als Schritt im Prefect‑Flow​

Wo werden Purpose/Entitlements gepflegt?​

Entscheidung und typische Follow‑ups​

BPMN‑Detailansicht​

Glossar‑Begriffe​

BPMN‑Kontext​