Lektion 10. Das Gesetz der Daten — Agent Operable Data

Praxistipps — Das reicht zum Loslegen

Code strukturiert (Lektion 8), System strukturiert (Lektion 9). Uebrig: Daten. Daten sind am gefaehrlichsten. Falscher Code → Tests fangen ihn. Falsches System → /health faengt es. Falsche Daten → niemand merkt es. Entdeckung 3 Monate spaeter im Quartalsbericht.

An den Agenten: “Erstelle das Schema mit expliziten Spalten und Constraints statt JSONB. amount muss groesser 0 sein, status nur erlaubte Werte.”

JSONB akzeptiert alles — nach 6 Monaten 100 verschiedene Formate durcheinander. Explizite Spalten und Constraints sind das Gesetz der Daten.

An den Agenten: “Importiere diese Excel in die DB. DDL-Constraints einhalten. Abgelehnte Zeilen in separate Datei mit Bericht.”

An den Agenten: “DDL aendern und yongol validate bestehen. Migrationsdatei erstellen, bei Fehler Rollback.”

Du musst keine DB kennen. Deine Aufgabe: “Was soll gespeichert werden” entscheiden. “Telefonnummer beginnt mit 010”, “E-Mail muss eindeutig sein” — diese Entscheidungen in natuerlicher Sprache, der Agent setzt sie als DDL um.

Warum man so anweisen muss

Daten verfaulen vor Code

Code falsch → Test faengt es in 1 Sekunde. System falsch → /health meldet sofort. Daten falsch → niemand merkt es. Entdeckung 3 Monate spaeter: “Warum ist der Umsatz negativ?”

3 Typen der Datenverfaulung

1. Fehlendes Schema — JSONB akzeptiert alles → 100 Formate nach 6 Monaten
2. Migrations-Fehler — Neue Nutzer haben E-Mail, alte 100.000 nicht → 500-Fehler
3. Geschaeftsregelverstoss — Ohne CHECK-Constraint → 200% Rabatt moeglich

4 Bedingungen fuer Agent Operable Data

1. Schema deklariert (DDL) — Typen, Constraints, Beziehungen explizit. Der Agent liest die DDL und versteht die Datenstruktur vollstaendig.

2. Transformationen verifizierbar — Regeln in Deklarationsdatei, Vor-/Nach-Invarianten pruefen.

3. Herkunft und Zeitpunkt nachverfolgbar — source, created_at, created_by in der DB.

4. Ratchet fuer Datenaenderungen — DDL aendern → validate → Migration (up+down) → Staging → Bestanden → Production (Genehmigung) → Fehler → Rollback.

Schema ist das Gesetz, das ich erlasse

Rechtsstaatlichkeit auf Daten angewendet:

Recht ist nicht Gerechtigkeit (justice), sondern Definition.

Schema ohne Daten ist eine gesetzlose Gesellschaft. Schema mit Daten ist ein Rechtsstaat.

3-Stufen-Verteidigung

1. Stufe: DB-Constraints — NOT NULL, UNIQUE, CHECK, FOREIGN KEY. Nicht umgehbar. Wichtigste Regeln hier.

2. Stufe: Rego-Regeln — Was DB-Constraints nicht ausdruecken koennen. “Rabatt ueber 30% braucht Manager-Genehmigung.”

3. Stufe: Migrations-Ratchet — DDL aendern → validate → Migration → Staging → Bestanden → Production.

10 Lektionen: Eine Vision

Lektion 1: "Erstelle eine To-Do-App" → Code kommt. 3 Features funktionieren.

Lektion 10: "Erstelle ein Bestellmanagement-SaaS"
  → Schema definieren, Features deklarieren, Regeln deklarieren
  → Code: yongol generiert aus SSOT
  → System: CI/CD automatisiert Build-Deploy-Monitoring
  → Daten: DDL erzwingt Schema, Rego verifiziert Regeln
  → Mensch: Nur "Genehmigt" druecken
  → Bei 200 Endpunkten kein Zusammenbruch

Code → System → Daten. Drei Domaenen, ein Prinzip.

Deklarieren, verifizieren, sperren, persistieren. Entscheidungen: Mensch. Implementierung und Verifikation: Maschine. Nicht Personenherrschaft, sondern Rechtsstaatlichkeit.

Per Sprache anweisen, und es wird gebaut. Nicht nur Code — auch System und Daten. Dafuer braucht es Zuegel, Schienen und Gesetze. Diese Zuegel, Schienen und Gesetze zu entwerfen — das ist Reins Engineering.

Reins Engineering Gesamtkurs

Quellenangaben

• E.F. Codd, “A Relational Model of Data for Large Shared Data Banks” (1970)
• OPA / Rego — Deklarative Policy-Sprache fuer Geschaeftsregelvalidierung
• yongol DDL → sqlc Chaining — Unterbrechungsfreie Kreuzvalidierung vom Schema zum typsicheren Code
• Rechtsstaatlichkeit (Rule of Law) — Verifizierbarkeit, Verstoss-Definition, Durchsetzbarkeit gelten fuer Code, System und Daten gleichermassen