Wie eine Synopse entsteht

Anhand der Drucksache BT-Drs. 21/6003 (Änderung kindergeldrechtlicher Regelungen) — Schritt für Schritt durch die KI-Pipeline.

Diese Seite erklärt, was zwischen „Drucksache liegt im Bundestag” und „Synopse ist auf lagedergesetze.org/synopsen” eigentlich passiert. Keine Marketing-Sicht — die echte Mechanik.

In Kürze

• Sechs spezialisierte KI-Agenten arbeiten zusammen — alle Claude-Sessions, jede gezielt anders instruiert.

• Jede Synopse durchläuft sechs Stationen (Dirigent, Synopsen-Bearbeitung, zwei Gutachten zur Synopse, Klartext-Bearbeitung, Klartext-Gutachten). Bei Beanstandungen kommt eine Korrekturrunde dazu.

• Ziel ist, künftig Modelle mehrerer Anbieter unabhängig voneinander prüfen zu lassen (Claude, GPT, Gemini) — aktuell laufen alle Rollen auf Claude Sonnet 4.5/4.6.

• Alle Befunde sind im Audit-Trail jeder Synopse sichtbar. Nichts wird versteckt; auch fehlerhafte Drucksachen werden 1:1 übernommen und transparent markiert.

Die Rollen

Jede Rolle hat einen kurzen Anweisungstext (einen sogenannten Skill) — ein paar Bildschirmseiten, die die Rolle, das erwartete Format, die Korrektheits-Disziplin und typische Fehler beschreiben. Die Vollversion liegt im Repo.

Schritt 1 — Drucksache holen

Der Dirigent fragt täglich die DIP-API des Bundestages nach neuen Gesetzentwürfen. Für 21/6003 lädt er die PDF von dserver.bundestag.de, konvertiert sie mit pdftotext in Plaintext und legt sie unter Originalquellen/BT-21/2106003.txt ab.

Parallel sorgt eine deterministische Hilfsschicht dafür, dass die im Gesetzentwurf geänderten Gesetze in einer aktuellen Markdown-Fassung vorliegen — für 21/6003 also Einkommensteuergesetz § 66 und Bundeskindergeldgesetz § 6, jeweils direkt aus dem amtlichen XML von gesetze-im-internet.de.

Schritt 2 — Der Synopsen-Bearbeiter erzeugt den Diff

Der Bearbeiter wird mit drei Pfaden gestartet:

• Pfad zum Drucksachen-Plaintext

• Pfad zur lokalen Gesetzes-Datenbank

• Pfad, an den die fertige JSON-Datei geschrieben werden soll

Skill-Auszug (gekürzt; volle Fassung im Repo):

Du bist Synopsen-Bearbeiter für eine Drucksache. Du liest sie, du liest die betroffenen Gesetze, du schreibst eine strukturierte Synopse als JSON. Du machst nichts anderes.

Pro Änderungsbefehl der Drucksache schreibst du einen Block:

• vorher = der vollständige Norm-Block VOR der Änderung — wortgenau aus dem Gesetz.

• nachher = derselbe Block mit angewendeter Änderung.

• konfidenz ehrlich: hoch wenn eindeutig, unbestimmt wenn du es nicht belastbar lösen konntest.

Niemals halluzinieren. Findest du vorher nicht 1:1 im Gesetz, ist der Block unbestimmt und unsicherheiten muss begründen.

Was 21/6003 ergibt: Zwei Änderungs-Blöcke — jeweils eine Einfügung in einen bestehenden Paragraphen:

Konfidenz bedeutet hier: Wie sicher ist die Pipeline, dass sie den Änderungsbefehl korrekt angewendet hat? Hier ist sie nur mittel — und dafür gibt es einen Grund.

Was 21/6003 lehrreich macht — drei Auffälligkeiten im Drucksachentext

Beim Lesen der Drucksache stieß der Bearbeiter auf:

1. Selbstreferenz im normativen Text: Der eingefügte Absatz 4 enthält den Satz „Satz 2 ist nicht anzuwenden …” — und ist selbst „Satz 2” im neuen Absatz. Der Verweis zeigt damit offenbar auf den gerade eingefügten Satz selbst, was die Anwendung unklar macht. Gemeint war fast sicher „Satz 1”.

2. Widerspruch zwischen Norm und Begründung: Die Begründung der Drucksache spricht von „Satz 3 stellt sicher, dass …” — der normative Text hat aber nur zwei Sätze.

3. Grammatikfehler: „werden die folgende Sätze eingefügt” — fehlendes End-n.

Der Bearbeiter glättet das nicht. Er übernimmt den Drucksachen-Wortlaut 1:1 (inklusive Fehler) und dokumentiert die Beobachtungen im unsicherheiten[]-Feld jedes betroffenen Blocks. Konfidenz fällt deshalb auf „mittel”. So bleibt für jede:n Lesende:n transparent, dass die Auffälligkeit aus dem Drucksachentext stammt, nicht aus der Bearbeitung.

Schritt 3 — Synopsen-Gutachter und Stand-Gutachter prüfen parallel

Sobald die JSON da ist, startet der Dirigent zwei Gutachter — beide laufen gleichzeitig, unabhängig voneinander, ohne den Befund des anderen zu sehen.

Synopsen-Gutachter

Lade die Synopse + die Originalquellen. Prüfe Block für Block:

• Steht befehl_original wortgenau in der Drucksache?

• Steht vorher wortgenau im geltenden Norm-Markdown?

• Wende den Befehl gedanklich auf vorher an — kommt nachher heraus? Wurde nichts ergänzt, nichts still weggelassen?

Stille Auslassungen sind ein kritischer Fehler — wenn vorher ein ganzer Absatz ist und nachher plötzlich nur ein einzelner Satz, ohne dass die Drucksache eine Löschung verlangt: Befund „abgelehnt”, Synopse zurück an Bearbeiter.

Befund für 21/6003: „konsistent” — beide Blöcke wortgenau, kein still weggelassener Text, Adressierung stimmt.

Stand-Gutachter

Beantworte eine einzige Frage: Bezieht sich die Drucksache auf die Gesetzes-Fassung, die wir im Repo haben?

Wenn die Drucksache von einem Stand spricht, der bei uns schon weiter ist (Änderung bereits eingearbeitet) oder noch nicht da ist (Paragraph existiert nicht), kann keine sinnvolle Synopse entstehen.

Befund für 21/6003: „stand passt” — die Drucksache nennt EStG i.d.F. v. 4.2.2026, und unser lokales EStG hat exakt dieses Datum als letzter_stand_builddate.

Schritt 4 — Klartext-Bearbeiter erzeugt die laienverständlichen Erklärungen

Erst wenn die fachliche Synopse durch ist, schreibt der Klartext-Bearbeiter die Übersetzung in Alltagssprache:

Pro Block: ein bis drei Sätze in sachlicher dritter Person.

Keine Wertung. Keine Wirkungs-Adjektive („drastisch”, „massiv”). Konkret bleiben — Beträge, Daten, Behörden mit Namen, sofern die Synopse sie nennt.

Klartext darf nichts hinzufügen, was nicht in der Synopse steht. Externes Hintergrundwissen (Urteile, Begründungs-Zahlen, Gesetzgebungsgeschichte) ist verboten — das wäre Quellen-Recherche, eine andere Rolle. Kontext aus anderen Blöcken derselben Synopse ist erlaubt.

Schritt 5 — Klartext-Gutachter prüft die Erklärungen

Prüfe die Klartext-Felder auf sachliche Richtigkeit und Lesbarkeit. Keine Wertung, keine Wirkungs-Adjektive, keine Hinzufügung aus externem Hintergrundwissen.

Erster Befund für 21/6003: „unsicher”. Der Klartext beider Blöcke hatte das juristisch saubere „nicht nach § 1 Absatz 1 oder 2 unbeschränkt einkommensteuerpflichtig” zu „Wohnsitz nicht in Deutschland” verkürzt. Klingt ähnlich — ist aber juristisch ein anderes Kriterium (beschränkt steuerpflichtige Personen ohne deutschen Wohnsitz fallen anders darunter). Eine verfälschende Vereinfachung.

Schritt 6 — Bei Beanstandung: Korrekturrunde

Der „unsicher”-Befund läuft zurück zum Klartext-Bearbeiter. Der korrigiert gezielt: das juristische Tatbestandsmerkmal wird ausgeschrieben, die voreilige „Wohnsitz”-Vereinfachung entfernt, die unklare Ausnahme (wegen der Drucksachen-Selbstreferenz) ehrlich als „nicht eindeutig bestimmbar” markiert.

Anschließend prüft der Klartext-Gutachter erneut. Befund: „konsistent”. Die Korrektur ist sauber, keine neuen Fehler eingeführt.

Schritt 7 — Freigabe & Veröffentlichung

Mit drei positiven Gutachten ergibt sich automatisch Befund „geprüft”. Der Dirigent:

1. Befüllt den audit-Block der Synopse (alle drei Gutachten + Freigabe-Zeitstempel).

2. Lässt die Render-Schicht aus der JSON eine Markdown-Seite mit Vorher/Nachher-Diff + Audit-Trail erzeugen.

3. Bereitet die Webseite für die Veröffentlichung vor und spielt sie nach Freigabe auf Cloudflare Pages aus.

4. Synct die Synopse-JSON auf den API-Server, sodass die iOS-App sie sofort sieht.

Hätte einer der Gutachter „mit vorbehalt” gemeldet (etwa weil ein Block konfidenz: niedrig hat), würde die Synopse trotzdem veröffentlicht — aber mit gelbem „MIT VORBEHALT”-Badge in der Übersicht und allen Details im Audit-Trail.

Typische Fehler-Muster

Transparenz

Jede Synopse trägt ihren Befund offen oben auf der Synopsen-Karte: GEPRÜFT, MIT VORBEHALT oder PRÜFUNG NÖTIG. Auf der Detail-Seite zeigt die Audit-Trail-Sektion alle Stufen mit ihren Modellen, Befunden und (bei den Gutachtern) den jeweiligen Beobachtungen.

Die Synopse-Daten selbst sind unter CC0 / Public Domain frei nutzbar — alles ist über die API abrufbar. Der Quellcode der Pipeline soll Open Source werden, sobald die Architektur stabil ist.