Thema: Teil 6. Die Verfassung der Datenplattform einer Bank
Schwierigkeitsgrad: Fortgeschritten
Geschätzte Lernzeit: 3-4 Stunden (Theorie — 1,5 Std., Praxis — 1,5 Std., Fallanalyse — 1 Std.)
Voraussetzungen: Grundlegendes Verständnis der Data-Lakehouse-Architektur
Vertrautheit mit den Arbeitsprinzipien von dbt und DuckDB
Verständnis der Konzepte Grain, Freshness und Data Contracts
Erfahrung mit analytischen Marts (Datenschicht für Endnutzer)
Grundkenntnisse zu PII-Richtlinien und Schutz personenbezogener Daten
Lernziele: Die Mission der Datenplattform einer Bank so formulieren, dass sie dem Agenten hilft, konkrete Entscheidungen zu treffen
Unterscheiden, welche Regeln zur Verfassung gehören und welche zur Spezifikation eines bestimmten Modells
Einen Satz nicht verhandelbarer Regeln (5–10 Punkte) mit expliziter Angabe des Ortes ihrer Fixierung zusammenstellen
Die Reihenfolge der Maßnahmen des Agenten beim Entdecken eines Konflikts zwischen Mart-Komfort und langfristigen Prinzipien festlegen
Contract-Änderungen unter Berücksichtigung von Breaking Changes und Anforderungen an die menschliche Bestätigung überprüfen
Überblick: Die Verfassung der Datenplattform ist ein kurzer, aber überprüfbarer Satz von Prinzipien, der die Mission, den zulässigen Tech-Stack, die Roadmap der Artefakte und die Verhaltensregeln des Agenten fixiert. Im Gegensatz zu einem gewöhnlichen Tech-Stack beantwortet die Verfassung nicht nur die Frage "welche Werkzeuge verwenden wir", sondern auch die Frage "welche Entscheidungen der Agent nicht selbst trifft". Für die Bankanalyse ist dies von kritischer Bedeutung: Grain, PII-Richtlinie, SLA, Breaking Changes und Risikomethodik dürfen nicht als Nebenwirkung von SQL entstehen. In diesem Teil wird betrachtet, wie man die vier minimalen Dateien (mission.md, tech-stack.md, roadmap.md, AGENTS.md) zusammenstellt, welche Regeln nicht verhandelbar werden müssen, wie man den typischen Fehler der Vermischung von Verfassung und Mart-Spezifikation erkennt, und wie man die Verfassung als Vertrag mit dem zukünftigen Selbst behandelt.
Schlüsselkonzepte: Verfassung der Datenplattform: Ein kurzes und überprüfbares Dokument (ein Satz aus 4 Dateien), das die Mission, den Tech-Stack, die Roadmap und die Verhaltensregeln des Agenten fixiert. Beantwortet die Frage: welche Entscheidungen nicht in jedem Mart neu diskutiert werden müssen.
Mission.md: Eine Datei, die erklärt, warum die Plattform existiert. Eine gute Mission ist konkret und überprüfbar: "Jedes Datenprodukt muss einen Eigentümer, einen Konsumenten, ein Grain, eine PII-Richtlinie, ein Freshness-Versprechen, Prüffakten und einen Reviewer-Bericht haben". Eine schlechte klingt großspurig, hilft aber nicht bei der Entscheidungsfindung.
Tech-stack.md: Eine Datei, die den lokalen Tech-Stack und die Zuordnung zur Produktionsumgebung fixiert. Legt fest, welche Werkzeuge in der Lernumgebung zulässig sind (DuckDB, dbt) und wie sie sich zur produktiven Umgebung verhalten.
Roadmap.md: Eine Datei, die die Reihenfolge der Artefakte zeigt. Führt den Agenten und den Reviewer durch die Abfolge der Schritte: was wird zuerst erstellt, was später.
Agents.md: Eine Datei, die die Verhaltensregeln des Agenten festlegt. Enthält nicht verhandelbare Einschränkungen: Verbot der PII-Weitergabe, Anforderung der Bestätigung bei Änderung des Grains, Verbot der Bearbeitung von Dateien in der Review-Phase.
Nicht verhandelbare Regeln: Prinzipien, die innerhalb eines einzelnen Marts nicht ohne Aktualisierung der Verfassungsdatei geändert werden können. Beispiele: Marts legen keine direkten PII-Felder offen; Änderung des Grains erfordert Genehmigung; obligatorische Vertragsfelder können nicht ohne Notiz zu Breaking Changes gelöscht werden; dbt build --profiles-dir . ist eine obligatorische Prüfung; der Reviewer-Durchlauf darf keine Dateien bearbeiten.
Grain: Die Granularitätsebene einer Zeile im Mart (zum Beispiel eine Zeile pro Kunde). Eine Änderung des Grains ist eine Breaking Change, die menschliche Genehmigung erfordert.
Pii (personenbezogene identifizierbare Informationen): Personenbezogene identifizierbare Informationen. Die PII-Richtlinie wird in der Verfassung vor der Profilierung der Quellen fixiert, um eine zufällige Offenlegung zu vermeiden.
Breaking Change: Eine Änderung am Vertrag, die Konsumenten beschädigen kann: Löschen eines obligatorischen Felds, Änderung des Grains, Änderung des Datentyps. Erfordert eine separate Genehmigung und Notiz.
Data Contract (Datenvertrag): Spezifikation des Datenprodukts: Eigentümer, Konsumenten, Grain, Felder, PII-Richtlinie, SLA für Freshness, Prüffakten. Wird in YAML oder in der Modellspezifikation beschrieben.
Modellspezifikation: Ein Dokument, das einen konkreten Mart beschreibt (zum Beispiel mart_customer_360): SQL-Felder, Geschäftslogik, Tests. Es darf nicht erneut den Tech-Stack auswählen oder die Mission formulieren.
Prüffakten (check facts): Aussagen, die vor dem SQL geschrieben und danach überprüft werden. Ermöglichen es, das erwartete Verhalten eines Modells vor seiner Implementierung festzuhalten.
Vertrag mit dem zukünftigen Selbst: Eine Metapher, die die Rolle der Verfassung beschreibt: Zu Beginn eines Projekts ist alles offensichtlich, aber nach zehn Änderungen verschwindet die Offensichtlichkeit. Die Verfassung bewahrt die ursprünglichen Entscheidungen an einem Ort, an dem sie der nächste Agenten- und Reviewer-Durchlauf sehen wird.
Wichtige Zeitpunkte: Vor Beginn der Quellprofilierung: Die PII-Richtlinie in mission.md oder AGENTS.md fixieren, um eine zufällige Offenlegung beim ersten Datenscan zu vermeiden.
Vor dem Schreiben von SQL: Prüffakten (check facts) für jedes Modell aufschreiben. Diese Regel wird als nicht verhandelbar in die Verfassung aufgenommen.
Vor der Änderung des Grains oder dem Löschen eines obligatorischen Vertragsfelds: Anhalten, die Verfassungsdatei aktualisieren, menschliche Bestätigung einholen und erst danach das SQL ändern.
Beim ersten Auftreten einer neuen Regel während der Implementierung: Anhalten und die Verfassungsdatei aktualisieren, bevor mit dem SQL fortgefahren wird. Die Regel nicht als Kommentar im Code hinterlassen.
Übungsaufgaben: Titel: Zusammenstellung von fünf nicht verhandelbaren Regeln
Aufgabe: Stellen Sie fünf nicht verhandelbare Regeln für Ihre Lern-Datenplattform einer Bank zusammen. Geben Sie für jede Regel an, wo sie lebt: AGENTS.md, mission.md, tech-stack.md, Contract-YAML oder Modellspezifikation. Die Regeln müssen überprüfbar sein, keine Schlagworte.
Lösung: Schritt 1. Identifizieren Sie fünf Risiken, die bei der Arbeit mit Bank-Marts am häufigsten auftreten: PII-Leak, Grain-Drift, Löschen obligatorischer Felder, Überspringen der dbt-build-Prüfung, Bearbeitung von Dateien in der Review-Phase. Schritt 2. Formulieren Sie jede Regel als Aussage, die im Review überprüft werden kann. Schritt 3. Bestimmen Sie den Fixierungsort:
- Regel 1 "Marts legen keine direkten PII-Felder offen (Name, Telefon, E-Mail im Klartext)" → AGENTS.md
- Regel 2 "Änderung des Grains erfordert Genehmigung des Produkteigentümers und Notiz in roadmap.md" → AGENTS.md + roadmap.md
- Regel 3 "Obligatorische Vertragsfelder (owner, consumer, grain, sla) dürfen nicht ohne Eintrag zu einer Breaking Change gelöscht werden" → Contract-YAML + AGENTS.md
- Regel 4 "Vor dem Merge wird
dbt build --profiles-dir .ausgeführt; der Build muss fehlerfrei durchlaufen" → tech-stack.md + AGENTS.md - Regel 5 "Der Reviewer bearbeitet keine Dateien, sondern hinterlässt Anmerkungen; Korrekturen nimmt der Autor vor" → AGENTS.md
Schritt 4. Überprüfen Sie jede Regel: Kann sie so verletzt werden, dass dies im Diff oder im dbt-Log sichtbar wird? Falls nein — umformulieren.
Schwierigkeit: fortgeschritten
Titel: Unterscheidung zwischen Verfassung und Modellspezifikation
Aufgabe: Gegeben ist ein Fragment eines Dokuments, das den Mart mart_customer_360 beschreibt. Bestimmen Sie, welche Zeilen zur Verfassung der Datenplattform gehören und welche zur Spezifikation eines bestimmten Modells. Erklären Sie, warum die Vermischung dieser Ebenen ein typischer Fehler ist.
Lösung: Schritt 1. Lesen Sie das Fragment und schreiben Sie alle Aussagen auf. Schritt 2. Klassifizieren Sie jede Aussage:
- "Die Plattform verwendet dbt 1.8 und DuckDB 1.1 im lokalen Kreis, im produktiven — Snowflake" → Verfassung (tech-stack.md), weil es um den Tech-Stack insgesamt geht.
- "mart_customer_360 enthält die Felder customer_id, full_name, birth_date, segment_code" → Modellspezifikation, weil es um einen konkreten Mart geht.
- "Marts legen keine direkten PII-Felder offen; full_name wird als Ivanov I.I. maskiert" → Verfassung (AGENTS.md) + Spezifikation (Maskierungsregel genau für diesen Mart).
- "Grain — eine Zeile pro Kunde; Änderung des Grains erfordert Genehmigung" → Der Teil über "Genehmigung" ist Verfassung, der Teil über "eine Zeile pro Kunde" ist Spezifikation.
Schritt 3. Formulieren Sie eine Schlussfolgerung: Die Verfassung beschreibt allgemeine Prinzipien und Grenzen, die Spezifikation die konkrete Implementierung. Die Vermischung führt dazu, dass beim Erscheinen eines neuen Marts erneut entschieden werden muss, welcher Tech-Stack verwendet wird, und jede Entscheidung ad hoc getroffen wird.
Schwierigkeit: fortgeschritten
Titel: Überprüfbarkeit von mission.md-Formulierungen
Aufgabe: Vor Ihnen liegen zwei Formulierungen von mission.md. Bestimmen Sie, welche besser ist, und formulieren Sie die schlechte so um, dass sie im Review überprüfbar wird.
Lösung: Schritt 1. Lesen Sie die Formulierungen: A) "Eine moderne Bank-Datenplattform schaffen". B) "Die Plattform baut reproduzierbare analytische Marts für die Lernbank. Jedes Datenprodukt muss einen Eigentümer, einen Konsumenten, ein Grain, eine PII-Richtlinie, ein Freshness-Versprechen, Prüffakten und einen Reviewer-Bericht haben". Schritt 2. Vergleichen Sie: Formulierung A liefert dem Agenten kein Kriterium für die Entscheidungsfindung. Formulierung B zählt die obligatorischen Attribute jedes Datenprodukts auf — sie können anhand des Contract-YAML überprüft werden. Schritt 3. Formulieren Sie A in eine überprüfbare Form um: "Die Plattform stellt reproduzierbare Marts auf dbt + DuckDB bereit; jeder Mart wird zusammen mit einem Contract-YAML veröffentlicht, das owner, consumer, grain, pii_policy, freshness_sla, check_facts und review_report enthält. Das Fehlen eines der sieben Attribute ist eine blockierende Anmerkung des Reviewers". Schritt 4. Formulieren Sie die Regel: Eine gute Mission zählt obligatorische Attribute oder Aktionen auf, eine schlechte operiert mit abstrakten Werten.
Schwierigkeit: Anfänger
Titel: Reaktion des Agenten auf einen Konflikt
Aufgabe: Der Agent hat bei der Implementierung des Marts mart_transactions_daily festgestellt, dass für die Bequemlichkeit des Analysten die Spalte card_pan_hash hinzugefügt werden muss, die ein direktes PII-Feld ist. Beschreiben Sie die korrekte Abfolge der Aktionen des Agenten gemäß der Verfassung.
Lösung: Schritt 1. Der Agent muss anhalten und das Feld nicht hinzufügen, bevor die Situation geklärt ist. Schritt 2. Der Agent prüft AGENTS.md: "Marts legen keine direkten PII-Felder offen". Das Feld card_pan_hash gehört zu PII. Schritt 3. Der Agent prüft, ob es in mission.md oder AGENTS.md eine Ausnahme für Hash-Werte gibt. Wenn es keine Ausnahme gibt — kann das Feld nicht zum Mart hinzugefügt werden. Schritt 4. Der Agent formuliert eine Anfrage: entweder die PII-Richtlinie in der Verfassung ändern (mit menschlicher Bestätigung) oder dem Analysten eine Alternative vorschlagen (zum Beispiel die aggregierte Metrik count_distinct_pan). Schritt 5. Erst nach menschlicher Genehmigung und Aktualisierung der Verfassungsdatei setzt der Agent die Arbeit mit SQL fort. Schritt 6. Wenn es im Projekt keine Verfassung gibt, muss der Agent anhalten und darum bitten, sie zu erstellen, anstatt die Entscheidung selbst zu treffen.
Schwierigkeit: fortgeschritten
Titel: Erstellung einer Qwen-Anfrage zur Erstellung der Verfassung
Aufgabe: Erstellen Sie eine Anfrage an den Agenten (nach dem Vorbild aus dem Kapitel), die hilft, die Verfassung der Lern-Datenplattform einer Bank zusammenzustellen. Die Anfrage muss in sich geschlossen sein und das vorzeitige Schreiben von SQL explizit verbieten.
Lösung: Schritt 1. Bestimmen Sie das Ziel der Anfrage: die vier Verfassungsdateien (mission.md, tech-stack.md, roadmap.md, AGENTS.md) zusammenzustellen. Schritt 2. Listen Sie die obligatorischen Frageblöcke auf, zu denen der Agent vor dem Schreiben Antworten erhalten muss: Mission, Tech-Stack, PII-Richtlinie, Vertragsdrift, menschliche Bestätigungen. Schritt 3. Fügen Sie ein explizites Verbot hinzu: "Schreibe kein SQL". Schritt 4. Die resultierende Anfrage: "Hilf mir, die Verfassung der Lern-Datenplattform einer Bank zusammenzustellen. Stelle vor dem Schreiben der Dateien Fragen zur Mission, zum Tech-Stack, zur PII-Richtlinie, zur Vertragsdrift und zu menschlichen Bestätigungen. Schreibe kein SQL". Schritt 5. Überprüfen Sie: Die Anfrage beginnt mit dem Ziel, listet die obligatorischen Klärungen auf, endet mit einem Verbot. Eine solche Anfrage verhindert die Situation, dass der Agent sofort SQL ohne Verfassung schreibt.
Schwierigkeit: Anfänger
Fallstudien: Titel: Grain-Drift im Mart für Kundensegmente: eine Lehre für die Verfassung
Szenario: In der Lernbank wurde der Mart mart_customer_segment mit dem Grain "eine Zeile pro Kunde pro Monat" bereitgestellt. Nach sechs Iterationen bat der Analyst darum, eine Detaillierung nach Produkten hinzuzufügen: "eine Zeile pro Kunde und Produkt pro Monat". Der Agent änderte, ohne anzuhalten, das SQL und aktualisierte das Modell. Der Konsument — das Segmentierungs-Dashboard — funktionierte nicht mehr, weil es eine Zeile pro Kunde erwartete.
Herausforderung: Der Agent traf die Entscheidung über die Änderung des Grains selbstständig, ohne Genehmigung des Produkteigentümers. Im Projekt gab es keine Verfassungsdatei, die die Regel fixierte: "Änderung des Grains erfordert Genehmigung". Jede Änderung des Grains musste neu diskutiert werden, und fast immer wurde die Variante "wie gerade bequem" gewählt.
Lösung: Das Team stoppte die Arbeit an den Marts und stellte eine Verfassung aus vier Dateien zusammen. In AGENTS.md erschien die Regel: "Änderung des Grains erfordert Genehmigung des Eigentümers des Datenprodukts und einen Eintrag in roadmap.md. Der Agent ändert das Grain nicht selbstständig". In mission.md wurde eine Liste der obligatorischen Attribute jedes Datenprodukts hinzugefügt, einschließlich Grain. Im Contract-YAML von mart_customer_segment wurde das Grain fixiert und als obligatorisches Feld markiert, das nicht ohne Breaking Change gelöscht werden darf.
Ergebnis: Zwei Wochen nach Einführung der Verfassung ging eine neue Anfrage zur Änderung des Grains in mart_risk_flags ein. Der Agent hielt an, formulierte die Genehmigungsanfrage, aktualisierte roadmap.md und änderte erst nach Zustimmung des Eigentümers das SQL. Die Dashboards funktionierten weiterhin. Die Reviewzeit für Grain-Änderungen verkürzte sich, weil die Regel überprüfbar wurde: Der Reviewer sieht den Grain-Diff im Contract-YAML.
Gelernte Lektionen: Die Regel "Änderung des Grains erfordert Genehmigung" muss in AGENTS.md leben, nicht in einem SQL-Kommentar.
Grain ist ein obligatorisches Feld des Contract-YAML; sein Löschen oder Ändern ist eine blockierende Anmerkung des Reviewers.
Ohne Verfassung wird jede Änderung des Grains neu diskutiert und fast immer gewinnt die nächste Aufgabe.
Verwandte Konzepte: Grain
Nicht verhandelbare Regeln
AGENTS.md
Vertrag mit dem zukünftigen Selbst
Titel: PII-Leak über eine bequeme Spalte: wie die Verfassung die Regression stoppte
Szenario: Im Mart mart_transactions_weekly bat der Analyst darum, die Spalte counterparty_name hinzuzufügen, um die Namen der Gegenparteien zu sehen. Der Agent fügte das Feld hinzu, ohne die PII-Richtlinie zu prüfen. Nach einem Monat stellte sich heraus, dass die Spalte in Berichten für externe Partner verwendet wurde und ein Teil der Namen die Bank-Peripherie verließ.
Herausforderung: Die PII-Richtlinie existierte in Form einer allgemeinen Phrase in der README des Projekts: "Beachten Sie die Anforderungen zum Schutz personenbezogener Daten". Die Formulierung war nicht überprüfbar, und der Reviewer konnte die Änderung nicht nach einem formalen Merkmal blockieren. Außerdem wurde die Richtlinie zu spät fixiert — erst nach der Profilierung der Quellen, als die Namen der Gegenparteien bereits in den Samples sichtbar waren.
Lösung: Das Team überarbeitete die Verfassung. In AGENTS.md erschien eine konkrete Regel: "Marts legen keine direkten PII-Felder offen: Name, Telefon, E-Mail, Name der Gegenpartei im Klartext. Zulässig ist eine maskierte Darstellung (zum Beispiel 'Ivanov I.I.') oder Aggregate (count, sum ohne Identifikatoren)". Die Richtlinie wurde vor der Quellprofilierung im nächsten Sprint fixiert. Im Contract-YAML jedes Marts erschien das obligatorische Feld pii_policy, das vom Autor ausgefüllt und vom Reviewer geprüft wird.
Ergebnis: Drei Sprints später ging eine ähnliche Anfrage ein: das Feld counterparty_inn (Steuernummer der Gegenpartei) hinzuzufügen. Der Agent hielt an, prüfte AGENTS.md und stellte fest, dass die Steuernummer nicht in der Liste der direkten PII enthalten ist, aber zu den sensiblen kommerziellen Informationen gehört. Der Agent formulierte eine Anfrage zur Klärung der Richtlinie, der Produkteigentümer bestätigte, dass die Steuernummer nur in maskierter Form zulässig ist, und die Policy wurde in AGENTS.md aktualisiert. Der Leak stoppte, der Reviewer blockiert jetzt PRs ohne ausgefüllte pii_policy.
Gelernte Lektionen: Die PII-Richtlinie muss konkret und überprüfbar sein: Felder aufzählen, nicht auf allgemeine Prinzipien verweisen.
Die PII-Richtlinie muss vor der Quellprofilierung fixiert werden, sonst erzeugen die ersten Samples die Illusion von Sicherheit.
Das obligatorische Feld pii_policy im Contract-YAML verwandelt die Richtlinie von einem Schlagwort in eine blockierende Anmerkung des Reviewers.
Verwandte Konzepte: PII (Personally Identifiable Information)
Nicht verhandelbare Regeln
mission.md
Data Contract (Datenvertrag)
Titel: Der Reviewer bearbeitet SQL und bricht die Reproduzierbarkeit: eine Lehre über die Grenzen der Rollen
Szenario: Im Team war folgender Prozess etabliert: Der Reviewer öffnet den PR, nimmt Korrekturen am SQL direkt vor und merged. Nach einem halben Jahr stellte sich heraus, dass ein Teil der Modelle im main-Branch lokal nicht reproduzierbar ist: dbt build schlägt mit einem Fehler fehl, weil der Reviewer eine Funktion verwendet hat, die nicht im fixierten Stack vorhanden ist.
Herausforderung: Im Projekt gab es keine Regel "der Reviewer bearbeitet keine Dateien". Die Rolle des Reviewers war verschwommen: Er hat gleichzeitig geprüft und korrigiert. Die Überprüfbarkeit der Verfassungsregeln sank, weil der Reviewer jede Einschränkung "unbemerkt" umgehen konnte, indem er einfach den Code korrigierte.
Lösung: In AGENTS.md wurde die Regel hinzugefügt: "Der Reviewer-Durchlauf darf keine Dateien bearbeiten. Der Reviewer hinterlässt Anmerkungen in Kommentaren und setzt den Status-Check; Korrekturen nimmt der Autor im nächsten Commit vor". In tech-stack.md wurde die Mindestversion von dbt und DuckDB fixiert, und in roadmap.md wurde der Schritt hinzugefügt: "Vor dem Merge wird dbt build --profiles-dir . ausgeführt; ein grüner Build ist eine obligatorische Bedingung".
Ergebnis: Im Laufe des nächsten Monats wurden drei PRs nach formalen Kriterien abgelehnt: Der Reviewer hinterließ eine Anmerkung, der Autor nahm die Korrektur vor, der erneute Lauf von dbt build war erfolgreich. Die Reproduzierbarkeit des lokalen Kreises wurde wiederhergestellt. Das Team legte auch fest, dass neue Abhängigkeiten zuerst in tech-stack.md und erst danach in den Code eingeführt werden.
Gelernte Lektionen: Die Rolle des Reviewers ist zu prüfen, nicht zu korrigieren. Die Vermischung der Rollen verwässert die Verfassung.
dbt build --profiles-dir . ist eine obligatorische Prüfung, sie muss in tech-stack.md und roadmap.md fixiert sein.
Werkzeugversionen sind Teil des Stacks, kein Implementierungsdetail; ihre Änderung erfordert eine Aktualisierung von tech-stack.md.
Verwandte Konzepte: Nicht verhandelbare Regeln
tech-stack.md
roadmap.md
AGENTS.md
Lerntipps: Halten Sie die Verfassung kurz: Vier Dateien zu je 1–2 Seiten sind besser als ein Dokument auf zwanzig Seiten. Lange Dokumente lesen weder Agenten noch Reviewer.
Stellen Sie sich vor dem Schreiben von mission.md die Frage: "Kann der Agent anhand dieser Mission in einer strittigen Situation eine konkrete Entscheidung treffen?" Wenn die Antwort "nein" lautet — formulieren Sie um.
Formulieren Sie jede nicht verhandelbare Regel so, dass sie im Diff oder im Build-Log überprüft werden kann. Der Satz "halten Sie Qualität ein" ist ein Schlagwort. Der Satz "Marts legen das Feld full_name nicht offen" ist eine Regel.
Fixieren Sie die PII-Richtlinie vor der Quellprofilierung. Nach dem ersten Sample haben Sie bereits die Illusion, dass "alles nicht so schlimm ist", und die Richtlinie wird aufgeschoben.
Beim ersten Auftreten einer neuen Regel während der Implementierung — anhalten und die Verfassungsdatei aktualisieren. Hinterlassen Sie die Regel nicht als Kommentar im SQL: Der nächste Agent wird sie nicht sehen.
Trennen Sie mission.md (warum), tech-stack.md (womit), roadmap.md (in welcher Reihenfolge), AGENTS.md (was nicht erlaubt ist) und die Modellspezifikation (was genau gebaut wird). Die Vermischung dieser Ebenen ist die Hauptfehlerquelle.
Behandeln Sie die Verfassung als Vertrag mit dem zukünftigen Selbst. Was heute offensichtlich ist, wird nach zehn Änderungen nicht mehr offensichtlich sein.
Verwenden Sie die Anfrage "Hilf mir, die Verfassung zusammenzustellen… Schreibe kein SQL" als Vorlage: Ziel, obligatorische Klärungen, Verbot vorzeitiger Aktionen.
Prüfen Sie beim Review zuerst die Verfassungsregeln (PII, Grain, obligatorische Felder), dann das SQL. Dies beschleunigt das Review und macht Anmerkungen nach formalen Kriterien blockierend.
Zusätzliche Ressourcen: Basisband des Kurses (Anwendungsverfassung): Beschreibt Mission, Stack und Roadmap der Anwendung insgesamt; Teil 6 erweitert diese Idee auf Data Lakehouse.
dbt-Dokumentation zu Data Contracts: https://docs.getdbt.com — Abschnitt über Datenverträge und Modellschemata.
DuckDB-Dokumentation: https://duckdb.org/docs — Beschreibung der lokalen analytischen Engine, die im Lernkreis verwendet wird.
Framework "Data Mesh" (Zhamak Dehghani): Konzept von Domain Ownership und Data Contracts, das der Idee der Constitution-Datei zugrunde liegt.
DSGVO und bankaufsichtsrechtliche Anforderungen: Überblick über die Anforderungen zum Schutz personenbezogener Daten im Finanzsektor (als Kontext für die PII-Richtlinie).
Artikel "The Ten Fallacies of Data Science": Über häufige Fehler beim Aufbau analytischer Plattformen, einschließlich des Fehlens einer expliziten Richtlinie.
Zusammenfassung: Die Verfassung der Datenplattform einer Bank besteht aus vier kurzen Dateien (mission.md, tech-stack.md, roadmap.md, AGENTS.md), die die Mission, den zulässigen Tech-Stack, die Roadmap der Artefakte und die nicht verhandelbaren Verhaltensregeln des Agenten fixieren. Der Hauptwert der Verfassung liegt in ihrer Überprüfbarkeit: Jede Regel muss so formuliert sein, dass sie im Review angewendet werden kann. Eine schlechte Verfassung sagt "halten Sie Qualität und Sicherheit ein", eine gute sagt "Marts legen keine direkten PII offen", "Änderung des Grains erfordert Bestätigung", "Prüffakten werden vor dem SQL geschrieben". Die Verfassung muss vor der Quellprofilierung zusammengestellt, beim Auftreten einer neuen Regel aktualisiert und als Vertrag mit dem zukünftigen Selbst behandelt werden: Was heute offensichtlich ist, wird nach zehn Änderungen nicht mehr offensichtlich sein. Ein typischer Fehler ist die Vermischung der Verfassung und der Spezifikation eines konkreten Marts; dies sollte vermieden werden, indem allgemeine Prinzipien und Implementierung auf verschiedene Dokumentationsebenen verteilt werden.