Teil 6. Verfassung der Datenplattform der Bank

Die Verfassung der Datenplattform beantwortet die Frage: Welche Entscheidungen nicht in jeder Mart neu diskutiert werden müssen. Im Grundband hat die Verfassung die Mission, den Stack und die Roadmap der Anwendung fixiert. Hier fixiert sie die Mission des DataLakeHouse, den lokalen Stack, die Grenzen der Abbildung auf die produktive Umgebung, die PII-Richtlinie und die Regeln für Vertragsänderungen.

Minimale Dateien

specs/mission.md
specs/tech-stack.md
specs/roadmap.md
AGENTS.md

mission.md erklärt, warum die Plattform existiert. tech-stack.md sagt, welche Werkzeuge erlaubt sind. roadmap.md zeigt die Reihenfolge der Artefakte. AGENTS.md legt die Verhaltensregeln des Agenten fest.

Was in der Mission stehen muss

Eine gute Mission für eine Lehrbank:

Die Plattform baut reproduzierbare analytische Marts für die Lehrbank.
Jedes Datenprodukt muss einen Eigentümer, einen Konsumenten, einen Grain,
eine PII-Richtlinie, ein Freshness-Versprechen, Prüftatsachen und einen
Reviewer-Bericht haben.

Eine schlechte Mission:

Eine moderne Bank-Datenplattform bauen.

Sie klingt großspurig, hilft dem Agenten aber nicht bei einer Entscheidung.

Nicht verhandelbare Regeln

Halten Sie Regeln fest, die innerhalb einer einzelnen Mart nicht geändert werden dürfen:

• Marts geben keine direkten PII-Felder preis;
• eine Änderung des Grains erfordert eine Genehmigung;
• obligatorische Vertragsfelder dürfen nicht ohne Notiz über eine Breaking

Change entfernt werden;

• dbt build --profiles-dir . ist eine obligatorische Prüfung, falls dbt

verfügbar ist;

• ein Reviewer-Durchlauf darf keine Dateien bearbeiten.

Wenn eine solche Regel zum ersten Mal während der Implementierung auftaucht, halten Sie an und aktualisieren Sie die Verfassungsdatei, bevor Sie mit SQL fortfahren.

Analyse für den Leser

Die Verfassung der Datenplattform wirkt hochtrabend, bis der erste Konflikt auftaucht. Der Agent möchte eine bequeme Spalte hinzufügen. Der Analytiker wünscht mehr Detaillierung. Die Mart beginnt, ein Feld offenzulegen, das zuvor als technisch galt. Wenn es im Projekt keinen kurzen Satz von Prinzipien gibt, wird jede solche Entscheidung neu getroffen, oft zugunsten der nächsten Aufgabe. Die Verfassung wird gebraucht, damit die nächste Aufgabe die langfristige Bedeutung der Daten nicht zerstört.

Im Gegensatz zu einem gewöhnlichen Technologie-Stack sagt die Verfassung nicht nur „welche Werkzeuge wir nutzen", sondern auch „welche Entscheidungen der Agent nicht eigenständig trifft". Für Bankdaten ist das besonders wichtig. Grain, PII-Richtlinie, SLA, Breaking Changes und Risikomethodik dürfen nicht als Nebeneffekt von SQL entstehen.

Wenn der Agent vorschlägt, einen dieser Punkte zu ändern, muss er anhalten und um Bestätigung bitten, anstatt die Änderung im Nachhinein zu erklären.

Eine gute Verfassung ist kurz, aber überprüfbar. Eine schlechte sagt: „halte Qualität und Sicherheit ein". Eine gute sagt: „Marts geben keine direkten PII preis", „eine Änderung des Grains erfordert eine menschliche Bestätigung", „Prüftatsachen werden vor dem SQL geschrieben". Solche Regeln lassen sich im Review anwenden. Wenn eine Regel nicht überprüft werden kann, bleibt sie ein Slogan und hilft dem Agenten nicht.

Für den Leser ist es nützlich, die Verfassung als Vertrag mit dem eigenen zukünftigen Ich zu betrachten. Zu Projektbeginn scheint alles offensichtlich: Customer 360 ist eine Zeile pro Kunde, Einwilligungen werden separat gezählt, der Risikoflag ist lehrbuchhaft. Nach zehn Änderungen verschwindet die Offensichtlichkeit. Die Verfassung bewahrt die ursprünglichen Entscheidungen an einem Ort, an dem sie der nächste Agentendurchlauf und der nächste Reviewer sehen werden.

Übung

Formulieren Sie fünf nicht verhandelbare Regeln für Ihre Datenplattform. Geben Sie für jede Regel an, wo sie lebt: AGENTS.md, mission.md, tech-stack.md, Vertrags-YAML oder Modellspezifikation.

Qwen-Anfrage

Hilf beim Aufbau einer Verfassung für die Lehrdatenplattform einer Bank.

Stelle vor dem Schreiben der Dateien Fragen zu Mission, Stack, PII-Richtlinie,
Vertragsdrift und menschlichen Bestätigungen.
Schreibe kein SQL.

Minimale Ausgabe

Nach dem Kapitel:

• specs/mission.md beschreibt den Zweck der Plattform;
• specs/tech-stack.md fixiert den lokalen Stack und die Abbildung auf die

produktive Umgebung;

• specs/roadmap.md führt durch die Artefakte;
• AGENTS.md verbietet PII-Leaks und nicht genehmigte Vertragsdrift.

Typischer Fehler

Verfassung und Spezifikation einer konkreten Mart vermischen. mission.md sollte keine SQL-Felder von mart_customer_360 auflisten; die Modellspezifikation sollte nicht erneut DuckDB oder dbt auswählen.

Kontrollfragen

1. Welche Entscheidungen gehören in die Verfassung und welche in die

Modellspezifikation?

1. Warum sollte die PII-Richtlinie vor dem Profilen der Quellen fixiert werden?
2. Wann erfordert eine Änderung eines Vertragsfelds eine eigene Genehmigung?