# Recl∆Im (F∆I) — Machbarkeitsstudie & Umsetzungsplan > Arbeitstitel des Systems: **„Gesetzes-Heatmap" / „Regulierungs-Wirkungsanalyse auf Ch∆In-Basis"** > Auftraggeber-Kontext: MIT AG Digitalisierung & KI-Strategien (Vorsitz Dr. S. Flemming), > Zielabnehmer der Vorschläge: MIT AG Entbürokratisierung > Frontend-Ziel: Integration in cdu-copilot (Flutter, ggf. via Ch∆In Studio), eigenständige Web-Sicht zusätzlich > Plattformbasis: **Ch∆In** — Hub/Module/Flow, WASM-Sandbox, tamper-evidentes Audit-Log. Vendor: **F∆I = Flemming.AI** > Status: Entwurf v0.3 — Diskussionsgrundlage AG-intern, noch nicht öffentlich (Plattform-Rename eingearbeitet 2026-06-17) --- ## 1 Executive Summary (1 Seite) Wir wollen eine **methodisch belastbare, quellenverifizierbare Software** bauen, die für einen abgegrenzten Rechtskorpus (Pilot: **Mittelstand-relevante Gesetze in Berlin und Bund**) folgendes leistet: 1. **Aktuell-Halten** des Normbestands (Gesetze, Verordnungen, einschlägige Verwaltungsvorschriften, EU-Vorgaben) mit klarem „Stand X"-Stempel. 2. **Strukturieren & Verknüpfen** des Korpus (Normgraph: Welche Norm verweist auf welche? Welche EU-RL liegt einer DE-Umsetzung zugrunde? Welche Berliner Norm setzt Bundesrecht aus?). 3. **Bewerten** auf zwei orthogonalen Achsen: - **Schadens-Index** (Bürokratiekosten in €, Zeitaufwand in Stunden, qualitativer Frust-Indikator, Komplexitäts-Score) — **methodisch angelehnt an das Standardkostenmodell (SKM)** des Nationalen Normenkontrollrats. - **Nutzen-Index** (Schutzwirkung, Marktordnung, EU-Harmonisierung, Rechtssicherheit) — qualitativ über strukturiertes Scoring. 4. **Gewichten nach Betroffenheit** (Adressatenzahl × Frequenz der Pflicht × Einschlägigkeit für KMU). 5. **Heatmap + Reform-Vorschlagsliste** ausspielen — sowohl als API für cdu-copilot als auch als PDF/DOCX-Export für AG-Sitzungen. **Was es ausdrücklich nicht ist:** - Kein Ersatz für juristische Beratung - Keine Rechtsentscheidung, keine automatisierte Verwaltungsentscheidung → **kein „Hochrisiko-KI-System" i.S.d. EU AI Act**, sondern ein Recherche-, Visualisierungs- und Vorschlagswerkzeug mit Transparenz-Pflichten nach Art. 50 - Keine politische Bewertung „aus dem Bauch" — jede Punktzahl ist mit Quelle hinterlegt **Warum Ch∆In als Basis trägt:** Deterministische YAML-Flows, WASM-Sandbox, tamper-evidentes Audit-Log (Hash-Kette `CHAIN-EVENT-V3`) und der `system.approval@^0`-Schritt für Human-in-the-Loop sind genau die Eigenschaften, die wir für eine nachprüfbare Bewertung von Rechtsnormen brauchen. Stand v0.16.0: discover → install → compose → run → audit läuft end-to-end, CRA-ready (CycloneDX-SBOM + sigstore ab Tag 1), Apache 2.0. Die Plattform liefert „Nachvollziehbarkeit by construction". --- ## 2 Vision & Scope (was bauen wir — und was bewusst nicht) ### 2.1 Pilot-Korpus (Phase 1) | Kategorie | Beispiele | Quelle | |---|---|---| | Bundesgesetze (KMU-einschlägig) | GewO, HGB-Teile, ArbZG, MiLoG, GeschGehG, BImSchG-Teile | gesetze-im-internet.de | | Bundesverordnungen | KassenSichV, GoBD-relevante VO, DSGVO-Durchführungs-VO | gesetze-im-internet.de | | EU-Rechtsgrundlagen | DSGVO, CSRD, NIS2, CRA, EU AI Act, EnergyEfficiencyDirective | EUR-Lex | | Berliner Landesrecht | BerlVwVfG, Berliner BauO, GewStG-Berlin-Anwendung, BetrKV-Berlin | landesrecht-berlin.de | | Bezirkssatzungen | exemplarisch 1–2 Berliner Bezirke (z.B. Mitte, Charlottenburg-Wlmd.) | Bezirksamt-Veröffentlichungen | **Bewusst draußen (Phase 1):** Tarifrecht, Sozialversicherungs-Detailrecht, spezifisches Steuerrecht jenseits typischer KMU-Berührungspunkte, Verwaltungsvorschriften ohne Drittwirkung (Innenrecht). ### 2.2 Was das System NICHT tut - Keine Erzeugung „neuer" Rechtsnormen - Keine Vertretung gegenüber Behörden (kein Legal-Tech-Mandant) - Keine personenbezogene Datenanalyse (Crowd-Beschwerden nur pseudonym) - Keine Echtzeit-Auskunft an Bürger („wie betrifft mich §X?") — Phase 1 bewusst nur Korpus-Analyse, kein Bürger-Service - Keine automatisierten Veröffentlichungen — jeder externe Output durchläuft einen `system.approval@^0`-Schritt durch einen Volljuristen im Team --- ## 3 Methodische Grundlagen (das, woran sich das Projekt politisch beweisen muss) **Wichtigster Satz dieses Dokuments:** Wenn die Methodik nicht sauber, anerkannt und peer-reviewed ist, ist jedes Ergebnis politisch angreifbar und wertlos. Code zweitrangig. ### 3.1 Etablierte Verfahren, auf denen wir aufbauen 1. **Standardkostenmodell (SKM)** der Bundesregierung, betreut vom Nationalen Normenkontrollrat: `Bürokratiekosten = Fallzahl (P) × Frequenz (F) × Tarif (T) × Zeitaufwand (h)` 2. **Bürokratiekostenindex (BKI)** des Statistischen Bundesamts als Referenz 3. **OECD Better Regulation Toolkit** (Regulatory Impact Assessment, REFIT) 4. **EU Better Regulation Guidelines + Toolbox** (relevant, da viel DE-Recht EU-determiniert ist) 5. **"One in, one out"-Regel** als politischer Maßstab für Vorschlagsformulierung ### 3.2 Erweiterungen, die wir wissenschaftlich begründen müssen - **Frust-Indikator**: nicht durch LLM „erfühlt", sondern operationalisiert als Komposit aus: - Lesbarkeit (Flesch-Reading-Ease, deutsch-adaptiert) - Verweistiefe (wie viele Normen muss man lesen, um §X zu verstehen?) - Behörden-Pluralität (wie viele Stellen sind im Vollzug involviert?) - Frequenz der Änderungen (Norm-Volatilität) - **Nutzen-Score**: 0–5 in den Dimensionen Sicherheit/Gesundheit, Umweltschutz, Verbraucherschutz, Marktordnung, Rechtssicherheit, EU-Binnenmarkt, Einnahmen — jede Dimension mit expliziter Quellen-Begründung - **Betroffenheits-Gewichtung**: Daten aus IHK, Handwerkskammer Berlin, DESTATIS Unternehmensregister; nicht aus dem LLM, sondern aus öffentlichen Statistik-Datensätzen ### 3.3 Was wir NICHT machen (methodische Selbstbeschränkung) - **Keine pauschalen Verdikte** „Gesetz X ist schädlich" - **Kein Single-Score-Ranking** als alleinige Output-Form — immer zweidimensional (Nutzen × Schaden) + Streuung - **Keine LLM-Endbewertung ohne menschlichen Review** — der LLM schlägt vor, ein Volljurist + Ökonom validieren - **Keine ungestützten Schadensschätzungen** — jede €/h-Zahl muss entweder aus offiziellen Quellen (Normenkontrollrat, DESTATIS, Branchenverbände) oder aus methodisch transparenten SKM-Rechnungen stammen, mit Unsicherheitsangabe --- ## 4 Datenquellen & Aktualität ### 4.1 Primärquellen | Quelle | URL | Format | Lizenz / §5 UrhG | Update-Frequenz | |---|---|---|---|---| | gesetze-im-internet.de | BMJ | XML (teilweise), HTML | amtliches Werk (frei), juris-Datenbestand prüfen | täglich/Bedarf | | Bundesgesetzblatt | bgbl.de | PDF (XML in Migration) | frei | wöchentlich | | EUR-Lex | eur-lex.europa.eu | FORMEX-XML, ELI-URIs | frei | täglich | | landesrecht-berlin.de | Berlin | HTML/PDF | frei | sporadisch | | Amtsblatt Berlin | Senat | PDF | frei | wöchentlich | | DIP (Bundestag) | bundestag.de/dip | XML/Atom | frei | täglich (Plenartage) | | DESTATIS GENESIS-Online | destatis.de | CSV/JSON-API | frei | je nach Tabelle | ### 4.2 Mechanik der Aktualität - **ELI-/CELEX-Identifier als kanonische ID** (nicht die URL!) - **„Stand"-Stempel auf jede Norm-Version**, signiert mit dem Hash der Quelldatei → landet im Ch∆In-Audit-Log - **Diff-Erkennung** bei Re-Pull (Modul `law.fetch` mit Caching + ETag) - **Manuelle Validierung** vor Bewertung: Wenn Norm seit Bewertung geändert, automatisches Re-Triggern des Bewertungs-Flows - **„Veraltete Bewertung"-Banner** im Frontend, wenn die Bewertung älter als die zugrunde liegende Fassung ist ### 4.3 Was wir NICHT als Primärquelle nehmen - Wikipedia, Anwaltsblogs, Kommentare: ggf. als sekundäre Hinweise auf Streitfragen, **nie** als Bewertungsgrundlage - Geschlossene juris-/beck-online-Bestände: nur, wenn lizenziert und zitierbar — sonst raus - Generierter LLM-Output: niemals als Quelle, immer nur als Vorschlag --- ## 5 Systemarchitektur auf Ch∆In ### 5.1 Mapping auf Hub / Module / Flow ``` ┌──────────────────────────────────────────────────────────────────┐ │ Ch∆In HUB (Rust, gRPC) │ │ Audit-Log (SQLite, tamper-evident) · Approval-Queue · Store │ └──────────────────────────────────────────────────────────────────┘ │ │ ▼ ▼ ┌──────────────────────────────┐ ┌──────────────────────────┐ │ Neue Module (8) │ │ Bestandsmodule (Ch∆In) │ │ nach Reuse-Lens sortiert, │ │ ab v0.16.0 verfügbar │ │ ABI chain:platform │ │ │ ├──────────────────────────────┼─────────┼──────────────────────────┤ │ chain-modules/ (generisch): │ │ http.request │ │ text.akoma-normalize │ │ text.extract (PDF/DOCX) │ │ text.deontic-extract │ │ text.anonymize (DSGVO) │ │ graph.citation-extract │ │ text.translate (DE↔EN) │ │ text.readability-score │ │ text.summarize │ │ stats.cohort-size │ │ llm.chat (Ollama-kompat.)│ │ graph.shapley-attribution │ │ system.approval@^0 │ │ │ │ debug.echo (Referenz) │ │ chain-modules-econ/: │ │ │ │ econ.skm-score │ │ │ │ │ │ │ │ chain-modules-law/ (domain): │ │ │ │ law.benefit-score │ │ │ └──────────────────────────────┘ └──────────────────────────┘ Heatmap rendert der **Client** (Flutter, CustomPainter) — kein serverseitiges viz-Modul. Server liefert JSON, Client pixelt. PDF/DOCX-Export (Phase 2+) via text.summarize + Client-Screenshot. ``` **Begründung — Reuse-Lens:** Module-Naming reflektiert Wiederverwend­ barkeit. Was kein juristisches Domänen-Wissen braucht, geht in `chain-modules/` (generisches Org) und ist damit auch in anderen F∆I-Projekten und für externe Nutzer wertvoll: `text.akoma-normalize` ist relevant für jeden, der Rechtsdokumente parst (EU-Parlament, Italien, Brasilien); `text.deontic-extract` für Verträge, ISO-Normen, Policies; `graph.citation-extract` für wiss. Paper, Patente, Spezi­ fikationen. Damit ist `chain-modules-law/` am Ende sehr klein — nur `law.benefit-score`, weil die 7 Bewertungs-Dimensionen (Schutz/Markt/Rechtssicherheit/EU-Binnenmarkt/…) genuin juristisch- politisch konventioniert sind. **`text.akoma-normalize` ist der Pflicht-Eingang**: heterogene Quellen (gesetze-im-internet XML, landesrecht-berlin HTML, EUR-Lex FORMEX) werden in Akoma-Ntoso-XML normalisiert — ab da nur noch ein Datenformat. Alles Generische (HTTP-Pull, PDF→Text, Anonymisierung, LLM-Call, Übersetzung, Approval, Audit) ist bereits in Ch∆In v0.16.0 vorhanden und wird nicht dupliziert. Module Apache 2.0, cosign-signiert. ### 5.2 Beispiel-Flow (YAML, vereinfacht) ```yaml # flows/bewerten-eine-norm.yaml inputs: norm_eli: { type: string, required: true } bezugsraum: { type: string, default: "berlin-kmu" } steps: - id: pull use: http.request@^0 with: url: ${{ inputs.norm_eli | eli_to_url }} method: GET etag_cache: true - id: normalize use: text.akoma-normalize@^0 # XML | HTML | FORMEX → Akoma Ntoso with: { content: ${{ pull.body }}, mime: ${{ pull.content_type }} } - id: graph use: graph.citation-extract@^0 with: { norm: ${{ normalize.norm }} } - id: duties use: text.deontic-extract@^0 with: { norm: ${{ normalize.norm }} } - id: skm use: econ.skm-score@^0 with: duties: ${{ duties.list }} population_table: "destatis://unternehmensregister/berlin-kmu" - id: nutzen use: law.benefit-score@^0 with: { norm: ${{ normalize.norm }}, duties: ${{ duties.list }} } - id: frust use: text.readability-score@^0 with: { norm: ${{ normalize.norm }}, graph: ${{ graph.edges }} } - id: review use: system.approval@^0 with: title: "Juristen-Review zur SKM/Nutzen-Bewertung" payload: skm: ${{ skm.report }} nutzen: ${{ nutzen.report }} frust: ${{ frust.report }} - id: vorschlag use: law.reform_proposal@^0 if: ${{ review.decision == 'approve' }} with: { full_assessment: ${{ review.payload }} } outputs: assessment: ${{ review.payload }} proposal: ${{ vorschlag.markdown }} ``` **Wichtig:** Der `review`-Schritt ist **nicht optional**. Kein Output verlässt das System ohne menschliche Freigabe. Damit erfüllen wir unsere methodische Selbstverpflichtung aus §3.3. ### 5.3 Datenmodell (Skizze) - `norm`: ELI-ID, Titel, Fassung-vom, Quelldatei-SHA-256, Volltext-Hash - `norm_version`: Diff zu Vorversion, Inkrafttreten, Außerkrafttreten - `bezug`: (norm_a, norm_b, art) — art ∈ {verweist_auf, ändert, ersetzt, beruht_auf_eu_richtlinie, …} - `pflicht`: (norm, paragraf, adressat, frequenz, geschätzter_aufwand_h, geschätzte_kosten_eur, quelle_der_schätzung) - `bewertung`: (norm, skm_score, nutzen_score, frust_score, stand, prüfer_juristisch, prüfer_oekonomisch, audit_event_id) - `vorschlag`: (norm, art ∈ {streichen, befristen, vereinfachen, konsolidieren}, begründung, beweis-quellen[]) ### 5.4 Frontend-Integration cdu-copilot - **Read-Only-API** via Ch∆In gRPC-Web (existiert bereits) - **Endpunkte** (vereinfacht): - `GET /norm/{eli}/assessment` → aktuelle Bewertung mit Quellen - `GET /heatmap?bezugsraum=berlin-kmu` → Heatmap-Daten (JSON) - `GET /vorschlaege?status=published` → freigegebene Reform-Vorschläge - **Flutter-Widgets**: Heatmap-Grid (Nutzen × Schaden, Größe = Betroffenheit), Norm-Detailansicht mit Quellen-Sidebar, Vorschlag-Karten - **Auth**: cdu-copilot fragt mit Service-Token; pro Mitglied authentifizierter Zugriff erst in Phase 2 --- ## 6 Bewertungs-System — Graph-basiert, auf der Ebene von *Pflichten* ### 6.0 Zentrale Erkenntnis (warum die ursprüngliche Skizze nicht reichte) **Wir bewerten nicht „Gesetze". Wir bewerten *Pflichten* (Duties / Restrictions), eingebettet in einen typisierten Norm-Graph.** „Bewerte das BImSchG" ist eine unbeantwortbare Frage. „Bewerte die Pflicht aus §4 BImSchG, eine Genehmigung einzuholen, die §10 i.V.m. der 4. BImSchV präzisiert wird, die ihrerseits Anhang I der EU-IED 2010/75 umsetzt" — *das* ist eine beantwortbare Frage, weil die Pflicht atomar ist und ihre Herkunft im Graph sichtbar bleibt. Daraus folgt: ein 6-Schichten-System, nicht ein „Bewertungs-Modul". ``` S6 Heatmap + Reform-Vorschläge (per Pflicht, nicht per Gesetz) S5 Roll-up & Attribution (Graph-Centrality, Shapley-Splitting) S4 Bewertung pro Pflicht (SKM €/h + Nutzen-Vektor + Frust) S3 Pflicht-Extraktion (deontische Modalitäten, LLM-Vorschlag + Review) S2 Norm-Graph (typed edges) S1 Korpus (versionierte Norm-Texte in Akoma-Ntoso XML) ``` ### 6.1 S1 — Korpus - **Format intern: Akoma Ntoso** (OASIS-Standard, vom EU-Parlament seit 2016 verwendet). Heterogene Quellen werden via `law.akoma_convert` normalisiert. - **Kanonische IDs**: ELI (europäisch), CELEX (EU), eigener URI-Schema für Berlin und Bezirke. - **Versionierung**: jede Fassung mit Inkrafttreten/Außerkrafttreten, Quell-URL, SHA-256 der Quelldatei, SHA-256 des normalisierten Akoma-Ntoso-Dokuments. Beides landet im Ch∆In-Audit-Log. - **Re-Pull-Mechanik**: ETag/Last-Modified-Tracking, täglicher Cronjob für `gesetze-im-internet` + EUR-Lex, wöchentlich für landesrecht-berlin (das ist erfahrungsgemäß träger). ### 6.2 S2 — Norm-Graph (das Herzstück) **Knoten:** Norm-Versionen — Gesetz, Verordnung, Paragraf, Artikel, Anhang, EU-Richtlinie, EU-Verordnung, Verwaltungsvorschrift, Allgemeinverfügung. **Kanten (typisiert):** | Kanten-Typ | Bedeutung | Beispiel | |---|---|---| | `transposes` | DE-Recht setzt EU-Recht um | BDSG → DSGVO | | `implements_via_vo` | Verordnungsermächtigung | §10 BImSchG → 4. BImSchV | | `concretizes` | Verwaltungsvorschrift konkretisiert Gesetz | AVV → BImSchG | | `amends` | Änderungsgesetz | „Gesetz zur Änderung des …" | | `cites` | Norm A verweist auf Norm B | „§ X i.V.m. § Y" | | `delegates_to_land` | Bund verweist Vollzug an Land | viele Bauthemen | | `delegates_to_kommune` | Land verweist an Kommune | Berliner BezVG | | `superseded_by` | Alte Fassung → neue Fassung | Historischer Lauf | | `cross_refers` | Norm enthält Definition, die anderswo verwendet wird | §15 AO „Geschäftsleitung" | **Aufbau:** `law.graph_build` arbeitet hybrid: 1. **Regelbasiert**: reguläre Ausdrücke für deutsche Zitations-Muster („§ 5 Abs. 2 Satz 1 BGB", „Artikel 6 Absatz 1 lit. f DSGVO"). Hier gibt es bereits Open-Source-Parser (z.B. *de-jure-regex*-Bibliotheken) und veröffentlichte Citation-Pattern aus Coupette et al. 2021. 2. **LLM-assistiert** nur für Kanten, die regelbasiert nicht greifbar sind (z.B. inhaltliche Konkretisierungs-Beziehungen). Jede LLM-extrahierte Kante wird mit `confidence < 1.0` markiert und bei `S4` zur juristischen Validierung vorgelegt. **Speicherform:** Property-Graph in SQLite (FTS5 + Recursive CTEs); für Phase-2-Skalierung Optionsraum Neo4j oder DuckDB-mit-GraphQL. Phase 1 reicht SQLite — das spart einen Dienst und passt zum Ch∆In-Audit-Log-Speicher. **Was der Graph für uns löst:** - Ich kann fragen: „welche EU-RL liegt dieser Pflicht zugrunde?" → Pfadsuche bis `transposes`-Kante. - Ich kann fragen: „welche Berliner Norm hängt an §X HGB?" → ausgehende `concretizes`/`delegates_to_land`-Kanten. - Ich kann „Reform-Vorschlag streiche Berliner §Y" automatisch prüfen: existiert eingehende `transposes`-Kette? → Vorschlag als „bei EU-Quelle ansetzen" umetikettieren. ### 6.3 S3 — Pflicht-Extraktion (Duty Extraction) Inspiriert von **Mercatus QuantGov** (RegData) und **LegalRuleML**. Eine Pflicht ist ein Tupel: ``` duty = ( modality, // OBLIGATION | PROHIBITION | PERMISSION | REQUIREMENT_TO_REPORT addressee, // wer? (KMU | Bürger | Behörde | spezifische Branche) trigger, // wann/woraus? (Bedingung) action, // was tun? frequency, // wie oft? (anlassbezogen | jährlich | quartalsweise | ad hoc) authority, // gegenüber welcher Stelle? consequence, // Sanktion bei Nichterfüllung source_norm, // welche Norm-Stelle? derived_from[] // Graph-Pfad zur Ursprungs-Norm (EU? Bund?) ) ``` **Extraktions-Pipeline:** 1. **Regelbasiert** (deterministisch): Modalverben + juristische Standardphrasen. Patterns wie „hat zu", „ist verpflichtet", „darf nicht", „muss", „kann verlangt werden", „bei der zuständigen Behörde anzuzeigen". Trefferquote ~60–70% nach QuantGov-Erfahrung. 2. **LLM-gestützt** (für die fehlenden ~30%): strukturierter JSON-Output mit verpflichtetem Quellen-Zitat (Satz/Absatz/Nummer). Ohne Zitat → verworfen. 3. **Juristen-Review im Pilot**: alle Pflichten der ersten 5 Normen werden manuell validiert. Aus dieser Validierung entsteht ein **Gold-Standard-Set**, das als Regressions-Test (`law.regression_test`) für jede Modell-/Prompt-Änderung dient. **Inter-Rater-Reliability messen** (Cohen's κ) — bei < 0.7 wird die Extraktion methodisch nicht freigegeben. Das ist die schmerzhafte, aber notwendige Wahrheit der quantitativen Rechtsanalyse. ### 6.4 S4 — Bewertung pro Pflicht Pro Pflicht drei orthogonale Scores, jeder mit Quellenangabe: #### 6.4.1 Schaden — Standardkostenmodell (€ + h) ``` B(duty) = P × F × ( T_sach + h × Tarif_h ) ``` - `P` = Adressatenzahl im Bezugsraum (Quelle: DESTATIS Unternehmens- register / IHK Berlin, je nach WZ-Code) - `F` = Frequenz pro Jahr - `T_sach` = direkte Sachkosten (Gebühren, Software-Lizenzen) - `h` = Zeitaufwand pro Fall - `Tarif_h` = NKR-Standardtarife (Statistisches Bundesamt veröffentlicht Lohnkostentafeln nach Qualifikation) **Konfidenzintervall ist Pflichtfeld.** Schätzungen ohne Quelle sind nicht zulässig — entweder NKR-Daten, eigene Branchen-Befragung oder explizit „expert estimate ±X %". #### 6.4.2 Schaden — Qualitativ (deterministisch, kein LLM) Pro Pflicht aus dem Graph berechnet: - **Verweistiefe** = mittlere Pfadlänge von der Pflicht zu ihren Definitions-/Konkretisierungs-Knoten - **Behörden-Pluralität** = `|distinct(authority) in zusammenhängenden duties|` - **Norm-Volatilität** = Anzahl `amends`-Kanten in den letzten 5 Jahren - **Lesbarkeit** = deutsche Variante des Flesch-Reading-Ease (Amstad-Formel) auf den Norm-Text der Pflicht Aggregat = `frust_score` ∈ [0,10], rein algorithmisch. #### 6.4.3 Nutzen — 7-dimensional, LLM-Vorschlag + Juristen-Approval Dimensionen (jede 0–5, dokumentierte Anker-Beispiele): 1. Schutz Leben/Gesundheit 2. Schutz der Umwelt 3. Verbraucherschutz / Schutz Schwächerer 4. Marktordnung / fairer Wettbewerb 5. Rechtssicherheit / Erwartbarkeit 6. EU-Binnenmarkt-Funktion 7. Fiskalische Funktion **LLM-Vorschlag**: RAG-pflichtig (Zitat aus Norm + Begründung), strukturierter Output, niedrige Temperature (≤0.1) für Reproduzierbarkeit; Modell-Digest landet im Audit-Log. **Juristen-Approval** via `system.approval@^0`. Ohne Approval kein Score → kein Output. #### 6.4.4 Betroffenheit (separat) ``` Betroffenheit(duty) = P(duty) × F(duty) × KMU-Anteil(duty) ``` **Bewusst nicht in Schaden-Score eingebaut** — sie ist eine **Hebel-Dimension**, nicht eine Schaden-Dimension. Eine teure, aber selten relevante Pflicht (z.B. Stilllegungsverfahren AKW) ist nicht der politisch sinnvolle Reform-Hebel. ### 6.5 S5 — Roll-up & Attribution (Abhängigkeiten + Ketten sauber lösen) Das ist der Teil, der dein eigentliches Problem löst. Drei Algorithmen kombiniert: #### 6.5.1 Attribution entlang `transposes`/`implements_via_vo`/`concretizes` Wenn die DSGVO eine Pflicht erzeugt, BDSG-§30 sie umsetzt und eine Berliner Vollzugsanweisung sie konkretisiert, wird der Schaden-Score **nicht** dreifach gezählt. Stattdessen: - **Originär-Beitrag** = Anteil, der erst auf dieser Ebene neu hinzukommt - **Pflicht-Last** = Summe der Originär-Beiträge auf dem Pfad Pragmatisches Verfahren: **Shapley-artiges Splitting** — jede Ebene, die zur Pflicht beiträgt (Zusatz-Doku, neue Frist, zusätzliche Behörde), bekommt einen anteiligen Schaden zugeordnet. Wer keinen Eigenbeitrag leistet (reine Wiederholung der EU-Vorgabe), bekommt 0. **Politisch wichtig**: das System sagt automatisch „Vorschlag zur Streichung des Berliner §X ist hohl, weil 100% der Pflicht aus DSGVO kommt" — und erspart der MIT AG, einen Vorschlag zu publizieren, der EU-rechtlich überhaupt nicht durchsetzbar ist. #### 6.5.2 Graph-Centrality — wo entstehen Pflicht-Ketten? - **PageRank über `cites`-Kanten**: welche Norm wird am meisten referenziert? (das sind die „Anker-Normen", deren Reform Wirkung entfaltet) - **Betweenness-Centrality** im Pflicht-Subgraph: welche Norm-Knoten liegen auf den meisten Pflicht-Pfaden? (das sind die „Engstellen"-Kandidaten) - **Cluster-Detection** (Louvain o.ä.): welche thematischen Gesetzes-Cluster bilden sich? (das hilft bei Konsolidierungs-Vorschlägen — „lege diese 5 Verordnungen zusammen") #### 6.5.3 Counterfactual-Simulation („was, wenn wir streichen?") Sehr eingeschränkt — nicht „echte" Kausal-Inferenz, sondern Graph-Surgery: - Markiere Pflicht X als gestrichen - Welche eingehenden Kanten verlieren ihren Bezug? - Welche EU-Mindest-Anforderungen werden dann verletzt? - Welche Verwaltungsvorschriften werden bedeutungslos? Output: eine Liste „Folge-Streichungen, die mitgemacht werden müssten". Das ist nicht *kausale* Wirkungsanalyse, aber es macht die *juristische Folgenkette* einer Reform sichtbar — was die AG für Begründungen braucht. ### 6.6 S6 — Output: Heatmap + Vorschläge #### 6.6.1 Die Heatmap (überarbeitet) - **Granularität: pro Pflicht**, nicht pro Gesetz. Eine Norm kann mehrere Pflichten enthalten, die unterschiedlich bewertet sind — und Reform setzt typischerweise an einzelnen Pflichten an. - **Achsen**: Schaden (X) × Nutzen (Y) - **Marker-Größe**: Betroffenheit - **Marker-Farbe**: Herkunfts-Ebene aus dem Graph (EU / Bund / Land / Kommune / Vollzug) — sofort sichtbar, wo Reform überhaupt möglich ist - **Marker-Form**: Reform-Empfehlung (streichen / vereinfachen / konsolidieren / befristen / belassen) - **Filter**: Branche (WZ-Code), Rechts-Ebene, Gesetzes-Cluster, Stand #### 6.6.2 Reform-Vorschlag (strukturiert) Jeder Vorschlag enthält: 1. **Ziel-Pflicht** (eindeutige ID) 2. **Reform-Typ** (streichen / vereinfachen / konsolidieren / befristen) 3. **Adressat-Ebene** (Bundestag / Landesparlament / EU-Kommission / Verwaltung) 4. **Quantitative Wirkung** (eingesparte €/h, Adressatenzahl) 5. **Begründung** mit Quellen-Zitaten 6. **Folge-Streichungen** aus Counterfactual-Simulation 7. **EU-/Verfassungs-Risiko-Hinweise** (z.B. „mind. Verbleib der DSGVO-Mindest-Anforderung erforderlich") 8. **Methodik-Hash** (welche Bewertungsregeln galten) Format: Markdown + maschinenlesbares JSON-Pendant — beides aus demselben `law.reform_proposal`-Modul, beides versioniert. ### 6.7 Evidenz-Layer — Woher kommen die Zahlen wirklich? **Eiserne Regel:** LLMs sind **keine Datenquelle**. Sie würden raten, und damit wäre das Projekt politisch wertlos. Jede €/h-Zahl, jede Adressatenzahl, jede Nutzen-Bewertung muss aus einer zitierbaren Quelle stammen und wird mit einem **Evidenz-Tier** markiert. #### 6.7.1 Vier-Tier-Modell | Tier | Quelle | Konfidenz | Politische Belastbarkeit | |---|---|---|---| | **T1** Amtlich / peer-reviewed | NKR-Stellungnahmen, DESTATIS BKI, ifo/ZEW/IW-Studien, EU-RIA, Gebührenordnungen | ±20 % | unbestreitbar | | **T2** Verbands- / Branchen-Erhebung | DIHK-Bürokratie-Reports, BDI/ZDH/ZGV-Studien, IHK-Berlin-Umfragen | ±30–50 % | belastbar mit Quellenangabe | | **T3** Eigene strukturierte Erhebung | KMU-Formular pro Pflicht, pseudonym, WZ-Code-stratifiziert | hängt von n ab | belastbar bei publizierter Methode + n ≥ 30 | | **T4** Qualitatives Signal | Petitionsausschuss, openPetition, mein.berlin.de, Foren-Sentiment | nicht quantifizierbar | nur als Pain-Point-Indikator, nie als Zahl | **Regel der niedrigsten Stufe**: Jede Pflicht-Bewertung trägt den Tier ihres *schwächsten* Bestandteils. Wenn `h` aus T1 kommt aber `P` aus T4, ist die Pflicht-Bewertung „T4". So bleibt die Wahrheits-Qualität immer ehrlich sichtbar. #### 6.7.2 Pro SKM-Variable | Variable | Beste Quelle | Tier | Aufwand | |---|---|---|---| | `P` Adressatenzahl | DESTATIS GENESIS-API, WZ-Code-stratifiziert | T1 | gering | | `F` Frequenz | Normtext + Verwaltungsvorschriften | T1 | mittel | | `T_sach` Sachkosten | Gebührenordnungen, Software-Preislisten | T1–T2 | gering–mittel | | `h` Zeit pro Fall | **Bottleneck**: NKR (nur neuere Gesetze), Verbandsdaten, eigene Erhebung | T1–T3 | hoch | | `Tarif_h` Stundensatz | DESTATIS Lohnkostentafeln | T1 | gering | | Nutzen-Dimensionen | Wirkungsstudien, Behördenstatistiken, juristische Bewertung | T1–T2 + Expertise | mittel | **`h` ist der Engpass.** Für etablierte Gesetze gibt es ihn oft nicht öffentlich. Eigene Erhebung in Phase 2/3 ist Pflicht. #### 6.7.3 Wo LLMs *doch* eine Rolle haben (Mörtel, nicht Stein) - **Extraktion** von SKM-Zahlen aus NKR-PDF-Stellungnahmen - **Klassifikation** von Petitionen/Beschwerden zu konkreten Pflichten - **Konsolidierung** mehrerer Verbandsstudien (Synthese-Tabelle) - **Übersetzung** von EU-RIA-Reports - **Inkonsistenz-Detektion** zwischen Quellen („NKR schätzt 4h, DIHK schätzt 12h" → flag für Juristen-Review) Jeder LLM-Output ist **Vorschlag**, nie **Quelle**. RAG-Pflicht, Zitat-Pflicht, Approval-Pflicht. #### 6.7.4 Quellen-Strategie für T4 (Signal, nicht Magnitude) In absteigender Sauberkeit: 1. **Petitionsausschuss des Bundestags** — öffentliche Datenbank, rechtlich unproblematisch, kategorisiert 2. **openPetition.de, change.org** — öffentlich, Beschwerdegegenstand erkennbar 3. **mein.berlin.de** — Berliner Bürgerbeteiligungs-Plattform, genau unser Bezugsraum 4. **IHK Berlin / DIHK Bürokratiebarometer** — strukturiert, einholbar per Kooperation statt Scraping 5. **Bundesnetzagentur Beschwerdestatistiken** — bereichsspezifisch, öffentlich 6. **Foren-Scraping** (Heise, themenspezifische Subreddits) — **rechtlich heikel** (ToS, UrhG, DSGVO). Nur Sentiment-Aggregate, keine Einzelzitate, niemals als Magnitude-Quelle #### 6.7.5 Eigene KMU-Befragung — der Skalierungs-Motor Ab Phase 2 die einzige saubere Quelle für `h`: ``` Pflicht: DSGVO Art. 30 — Verarbeitungsverzeichnis Diese Pflicht betrifft mich: [ja/nein] Stunden pro Jahr: ___ Externe Kosten pro Jahr (€): ___ Frust 1–5: ___ Branche (WZ-Code): [Dropdown] Größenklasse: [<10 / 10–49 / 50–249 / >249 MA] Kommentar: ___ Pseudonymes Token. Kein Personenbezug. AVV mit Hosting. ``` **Politische Voraussetzung**: Kooperationspartner für die Befragung **vor** Phase 2 akquirieren — MIT-Mitglieder allein liefern keine statistisch nutzbaren Samples. Mit IHK Berlin (~280.000 Mitgliedsunternehmen) + ZDH + BDI-Mittelstand wird es belastbar. #### 6.7.6 Datenmodell-Erweiterung Jede `bewertung` enthält jetzt eine `evidence`-Liste: ``` evidence_item: ( tier, // 1 | 2 | 3 | 4 source_type, // nkr | destatis | ifo | dihk | ihk_umfrage | // eigene_befragung | petitionsausschuss | ... source_url, source_hash, // SHA-256 der Quelldatei (Reproduzierbarkeit) claim, // { metric, value, ci_low, ci_high, unit } sample_size, retrieved_at, notes ) ``` Aggregation: pro Variable Bayesian Pooling oder gewichteter Mittelwert über Tier-Konfidenzen. Bei T1-Quelle: T1 gewinnt. Bei nur T3/T4-Quellen: mit Disclaimer publizieren oder gar nicht. ### 6.8 Reproduzierbarkeit & Halluzinations-Schutz Querschnitts-Anforderungen, die in jeder Schicht greifen: | Mechanik | Wirkung | |---|---| | **RAG-Pflicht** + Zitat-Pflicht im LLM-Output | keine Aussage ohne Norm-Stelle | | **Modell-Digest im Audit-Log** (Ch∆In-Bordmittel) | Reproduzierbarkeit über Modell-Versionen | | **Temperature ≤ 0.1, fester Seed** | deterministische Re-Runs | | **Regressions-Test-Suite** (`law.regression_test`) | Gold-Standard-Pflichten, pass-rate pro Modell-Update | | **Inter-Rater-Reliability** (Cohen's κ) | Methodik-Freigabe-Schwelle | | **`system.approval@^0`** vor jedem Output | menschliche Letztverantwortung | | **Tamper-evidentes Audit-Log** (Ch∆In-Bordmittel) | jede Bewertung rückwirkend prüfbar | | **Methodik-Versionierung** | Altbewertungen markieren „re-bewerten" bei Methode-Änderung | --- ## 7 Was du in deiner Skizze noch NICHT adressiert hast (kritischer Teil) ### 7.1 Konzeptionell | Lücke | Warum es weh tut | Vorschlag | |---|---|---| | **Bürokratie ≠ Gesetz** | Sehr viel Frust kommt aus *Vollzugs*vorschriften, internen Verwaltungsanweisungen und IT-Lücken, nicht aus dem Gesetzestext | Vollzugsdimension von Anfang an mitdenken; Phase 2-Modul `vollzug.audit` | | **Schutzgesetze nicht „schädlich" werten** | ArbZG, ArbSchG, BImSchG haben Bürokratie *als Funktion* — politisch fatal, das als „Schaden" zu reporten | Methodischer Eintrag: hoher Nutzen-Score schlägt hohen Schaden bei Schutznormen | | **Föderalismus-Vorrang** | Berlin kann Bundesrecht nicht einfach „abschaffen" | Vorschläge müssen Adressat-Ebene markieren: Bund / Land / EU / Bezirk | | **EU-Determinierung** | ~50–70% des Wirtschaftsrechts ist EU-induziert | EU-RL-Bezug im Datenmodell verpflichtend; Vorschläge sonst hohl | | **Counterfactual** | „Was wäre ohne diese Norm?" ist die eigentliche Frage — schwer messbar | Pragma: zumindest qualitatives Counterfactual-Feld; Phase 3 RCT-artige Studien | | **KMU ist nicht homogen** | Bäcker ≠ SaaS-Startup ≠ Handwerksbetrieb ≠ Anwaltskanzlei | Branchen-Filter (WZ-Codes) ab Phase 1 | | **Subjektive vs. objektive Belastung** | „Gefühlte" Bürokratie ist politisch hochrelevant, aber metrisch schwach | Separater Frust-Score (qualitativ) klar getrennt vom SKM-€-Score | | **Sunset-Clauses als Reform-Instrument** | Befristung > Abschaffung, weil weniger Widerstand | Reform-Vorschlagstyp „befristen mit Evaluationsklausel" als eigene Kategorie | | **Datenbasis für Adressatenzahl** | Ohne DESTATIS-/IHK-Anbindung sind alle Zahlen geraten | DESTATIS GENESIS-API-Modul vor Phase-1-Bewertung | ### 7.2 Recht & Compliance des Tools selbst | Punkt | Was zu tun ist | |---|---| | **EU AI Act** (Art. 50 Transparenz, Art. 6 Hochrisiko-Liste prüfen) | Risikoanalyse als eigenes Dokument; wir argumentieren „kein Hochrisiko, weil informativ + Human-in-the-Loop" | | **DSGVO** für Crowd-Input | Wenn KMU Belastungen melden: pseudonym, Datenminimierung, AVV mit Hosting | | **Urheberrecht** | §5 UrhG für amtliche Werke prüfen; juris-Daten nicht ungeprüft übernehmen | | **Politische Neutralität** | Methodik-Beirat mit nicht-parteilich-zuordenbaren Stimmen (Wissenschaft, Normenkontrollrat-Ehemalige) | | **Veröffentlichungsrecht** | Wer haftet für Bewertungen? → Disclaimer + redaktionelle Verantwortlichkeit klären | | **Lizenz des Tools** | Ch∆In ist Apache-2.0 — passt; eigene Module ebenfalls Apache-2.0 vorschlagen, damit andere validieren können (Glaubwürdigkeit!) | | **BSI-Grundschutz / ISO 27001** | Phase 2, nicht jetzt; aber Hosting-Konzept jetzt schon so wählen, dass nachrüstbar | ### 7.3 Methodisch / wissenschaftlich | Punkt | Was zu tun ist | |---|---| | **Inter-Rater-Reliability** | Mehrere Juristen müssen die Nutzen-Scores unabhängig vergeben → Cohen's Kappa messen | | **Reproduzierbarkeit bei LLM** | Temperature=0, gleiches Modell, gleicher Prompt-Hash; Modell-Digest landet im Audit-Log (das macht Ch∆In schon) | | **Halluzinations-Test-Suite** | Vor jedem Modell-Update: feste Test-Normen mit erwarteten Antworten; pass-rate dokumentiert | | **Quellen-Pflicht im LLM-Output** | RAG-Pflicht: Jede Aussage zitiert eine Norm-Stelle; ohne Zitat → Aussage verworfen | | **Peer-Review-Pfad** | Vor Veröffentlichung Methodik-Papier an Lehrstühle (Speyer, HU Berlin Verwaltungsrecht, ifo, ZEW) — ein „Kritisches Gutachten" einholen ist *Stärke*, nicht Schwäche | ### 7.4 Organisatorisch / politisch | Punkt | Was zu tun ist | |---|---| | **Methodik-Beirat** | 5–7 Personen, gemischt: Wirtschaft (BDI/ZDH), Verwaltungsrecht (Lehrstuhl), Normenkontrollrat-Background, IT-Recht, KMU-Vertreter, Verbraucherschutz | | **AG-Sitzungs-Kadenz** | Vorschläge in Schüben (z.B. 5 Normen pro Quartal), nicht „Sturzflut" | | **Versionierung des Methodik-Papiers** | wenn die Methode sich ändert, müssen alle Altbewertungen markiert „re-bewerten" werden | | **Konfliktbewältigung** | Was, wenn das System ein „CDU-Gesetz" als schädlich klassifiziert? Vorab-Vereinbarung: Methode > Politik. Sonst verbrennt das Projekt sich. | | **Skalierungs-Geschichte** | Pilot Berlin-KMU → Skalierung andere Bundesländer / Bundestags-AGs → ggf. Übergabe an Normenkontrollrat. Exit-Strategie jetzt schon mitdenken. | ### 7.5 Technisch / DevOps | Punkt | Was zu tun ist | |---|---| | **Hosting-Topologie** | `chain serve` läuft lokal/server (offline-first); für die AG: 1 zentraler Hub auf gehärtetem VPS, EU-Hosting (Hetzner Falkenstein o.ä.), kein US-Cloud | | **Datenpersistenz** | SQLite reicht für Phase 1 (das Audit-Log ist auf SQLite ausgelegt); Postgres-Migration als Phase-2-Option | | **Backup & Recovery** | täglich automatisiert; off-site verschlüsselt | | **Monitoring** | Ch∆In-eigene Events ins Grafana; Alarme bei fehlgeschlagenen Re-Pulls (= veraltete Daten!) | | **Secret-Management** | API-Tokens (z.B. juris-PAT) niemals im Repo; sops/age oder Vault | | **CI/CD** | Ch∆In-Konvention übernehmen: DCO-Sign-off, Conventional Commits, SBOM (CycloneDX), sigstore-Signatur (CRA-ready) | | **Module-Signierung** | Ch∆In refusiert unsignierte Module im Enterprise-Mode — nutzen, damit niemand „inoffizielle" Bewertungs-Module einschleust | | **Disaster-Doku** | klassisches Runbook (wer ist On-Call, wie restored man Audit-Log) | --- ## 8 Roadmap (Phasen, realistisch für ein Teilzeit-Team) > Annahme: ein Solo-Entwickler (S. Flemming) auf Ch∆In-Seite + 1–2 ehrenamtliche > Juristen/Ökonomen im MIT-Umfeld + 1 Methodik-Beirat. Vollzeit-Äquivalent > ca. 0,5–1,0 FTE Tech, 0,2 FTE Recht. ### Phase 0 — Methodik & Korpus-Definition (4–6 Wochen) - [ ] **Methodik-Papier v0.1** (genau diese Studie schärfen, peer-feedback) - [ ] **Korpus-Liste** „die ersten 50 Normen" (Bund + Berlin), schriftlich - [ ] **Methodik-Beirat** akquirieren (mind. 3 Zusagen) - [ ] **Rechtliche Stellungnahme** zu EU AI Act, DSGVO, Urheberrecht (z.B. via studentische Hilfskraft an einem Lehrstuhl) - [ ] **Go/No-Go-Entscheidung** der MIT AG, ob das Projekt weiter geht ### Phase 1 — Vertikaler Durchstich (3–4 Monate) Ziel: **eine Norm** end-to-end durchs System gespielt, mit Juristen-Approval und PDF-Ausgabe. - [ ] Module `law.fetch`, `law.parse_xml`, `law.parse_html` - [ ] Modul `law.graph_extract` (Verweisextraktion, sehr eingeschränkt: „§X i.V.m. §Y", „Artikel Z DSGVO" usw.) - [ ] Modul `law.skm_score` mit *manuell* gepflegten Aufwand-Schätzungen - [ ] Modul `law.benefit-score` mit RAG + Approval - [ ] Modul `law.frust_score` (deterministisch, kein LLM) - [ ] Flow `bewerten-eine-norm.yaml` - [ ] PDF-Export-Modul (für AG-Sitzungen) - [ ] **Pilot:** 5 Normen bewerten, Beirat reviewt ### Phase 2 — Korpus-Aufbau & Heatmap (3–4 Monate) - [ ] DESTATIS-/IHK-Anbindung (Adressatenzahlen) - [ ] Heatmap-Renderer (`law.heatmap_render`) - [ ] gRPC-Web-API für cdu-copilot - [ ] Flutter-Widgets in cdu-copilot - [ ] 50 Normen vollständig bewertet - [ ] Erste Vorschlagspaket an AG Entbürokratisierung - [ ] **Pilot:** 1 echter Vorschlag landet in einer AG-Diskussion ### Phase 3 — Skalierung & Öffentlichkeit (6+ Monate) - [ ] Crowd-Input von KMU (DSGVO-konform, pseudonym) - [ ] Branchen-Filter (WZ-Codes) - [ ] Ausweitung auf weitere Bundesländer - [ ] Methodik-Papier v1.0 veröffentlichen - [ ] Open-Source-Release der Bewertungs-Module (politisch + technisch Glaubwürdigkeit) ### Phase 4 (Vision) - [ ] Übergabe / Andocken an Normenkontrollrat oder ähnliche Institution - [ ] Replikation auf EU-Ebene (REFIT-Beitrag) --- ## 9 Risiken & Mitigation (Risikomatrix) | Risiko | Eintritt | Wirkung | Mitigation | |---|---|---|---| | Methodik wird als parteiisch zerrissen | mittel | sehr hoch | Beirat, Peer-Review, Open Source, Apache-2.0 | | LLM halluziniert Paragrafen → falsche Vorschläge | hoch (default) | sehr hoch | Strikte RAG-Pflicht, Juristen-Approval, Zitations-Pflicht | | Daten veralten unbemerkt | mittel | hoch | Re-Pull mit ETag, „Stand"-Banner, automatische Re-Bewertung | | EU AI Act stuft uns hoch-risiko ein | niedrig | hoch | Frühe Rechts-Stellungnahme; klare „Informationswerkzeug + HiL"-Positionierung | | Volljuristen-Kapazität reicht nicht | hoch | mittel | Kleines Pilot-Korpus, externe studentische HK an Lehrstühlen | | Politische Konflikte (CDU vs. Bewertung) | mittel | hoch | Vorab-Vereinbarung Methode>Politik, keine Sonderbehandlung von Normen | | Tool wird „CDU-Tool" wahrgenommen, nicht akzeptiert | mittel | hoch | Methodik-Beirat überparteilich, Open Source, Veröffentlichung in wiss. Outlet | | Ch∆In noch nicht 1.0 (Stand v0.16.0, Phase-0.5-Closure) | mittel | mittel | Discover/Install/Run/Audit-Zyklus läuft bereits; keine Phase-1+-Features voraussetzen (Streaming-Invoke, Polyglot-Module, Replay, OCI-Registry — Anhang D von Ch∆In-Docs prüfen) | | Hosting-Kosten explodieren | niedrig | niedrig | Lokal-first (Ch∆In-Eigenschaft, offline-first by design), nur Hub gehostet, LLM lokal über Ollama möglich | | Crowd-Daten-Manipulation | mittel | mittel | Phase-3-Thema, Pseudonymität + Plausibilitätsprüfung | --- ## 10 Wirtschaftlichkeit — was kostet das, was bringt es? ### 10.1 Kosten Phase 1 (grobe Schätzung) | Posten | Wert | |---|---| | Tech-Arbeit (S. Flemming, vorhanden) | „interne Arbeit" | | Methodik-Beirat (Aufwandsentschädigung) | 0–3 k€ | | Rechtsgutachten EU AI Act / DSGVO | 0 k€ (studentische HK) bis 5 k€ | | Hosting (Hetzner VPS, Falkenstein) | ~20 €/Monat | | Domain + TLS | < 100 €/Jahr | | **Summe Phase 1** | **~3–8 k€**, dominiert von Beirat/Gutachten | ### 10.2 Nutzen (politischer ROI) Schon ein einziger angenommener Vorschlag, der z.B. 1 Stunde Aufwand pro Jahr pro Berliner KMU einspart, entspricht bei ~180.000 KMU in Berlin und ~50 €/h einem volkswirtschaftlichen Effekt von **~9 Mio. €/Jahr**. Selbst um Faktor 10 zu hoch geschätzt ist das Verhältnis von Aufwand zu Wirkung sehr günstig. ### 10.3 Was passiert, wenn wir es nicht bauen Andere bauen es, vermutlich mit weniger sauberer Methodik. Die Argumentations-Lufthoheit in der Entbürokratisierungs-Debatte liegt dann woanders. --- ## 11 Sofortige nächste Schritte (das, was nach diesem Dokument passiert) 1. **Dieses Papier intern in der AG kommentieren lassen** (1–2 Wochen). 2. **Methodik-Beirat-Liste** entwerfen (Vorschlag: 7 Personen, Bezugsraum Berlin + Bund; explizit nicht nur CDU-nah). 3. **Korpus-Liste „erste 5 Normen"** für den vertikalen Durchstich beschließen — Vorschlag: GewO §14 (Anzeigepflicht), KassenSichV, DSGVO Art. 30 (Verarbeitungsverzeichnis), Berliner BauO §60 ff (Bauantrag), MiLoG §17 (Dokumentationspflicht). 4. **Rechtliche Kurz-Stellungnahme** anstoßen (EU AI Act, DSGVO, §5 UrhG, juris-Lizenz). Möglichst kostenneutral über Lehrstuhl-Kooperation. 5. **Repo `fai/reclaim` initialisieren** (Forgejo unter `git.flemming.ai`, Vendor-Namespace `fai/`), Lizenz Apache 2.0, DCO an, CI-Pipeline analog `fai/chain` (DCO-Sign-off, Conventional Commits, SBOM, sigstore). `law.*`-Module später in `chain-modules-law/` als product-scoped Org. 6. **Modul-Stub `text.akoma-normalize`** in `chain-modules/text-akoma-normalize/` als ersten Code-Commit (vertikaler Durchstich beginnt mit dem Pflicht-Eingang; HTTP-Pull macht `http.request` aus Bestand). Parallel **Flutter-App-Skelett** in `fai_reclaim/app/` (Theme nach fai_web-Palette, Hub-Connect-Seite). 7. **Methodik-Papier v0.1 als eigenes PDF** aus diesem Markdown destillieren — für den Beirat und die AG. --- ## Anhang A — Glossar (kurz) - **SKM**: Standardkostenmodell, offizielle Methode zur Messung von Bürokratiekosten - **Normenkontrollrat**: unabhängiges Beratungsgremium der Bundesregierung - **ELI**: European Legislation Identifier (eli.dlri.de / EUR-Lex) - **CELEX**: EU-Dokumenten-ID-System - **REFIT**: EU-Programm zur Regulatorischen Eignungsprüfung - **Ch∆In** (CLI: `chain`): Orchestrierungs-Plattform (eigenes Repo `fai_chain`), auf der Recl∆Im als Domänen-App aufsetzt. Vendor: **F∆I = Flemming.AI**. - **Hub / Module / Flow**: Ch∆In-Server (`chain serve`), WASM-Komponente (ABI `chain:platform`), YAML-Workflow - **RAG**: Retrieval Augmented Generation — LLM mit verpflichteter Quelleneinbindung - **Hochrisiko-KI (EU AI Act)**: KI-System, das Rechtsfolgen für Personen auslöst — wollen wir explizit *nicht* sein ## Anhang B — offene Fragen für die AG 1. Wer ist der **redaktionell verantwortliche Volljurist** im Pilot? 2. Welche **5 Normen** für den vertikalen Durchstich? 3. **Open Source ab welchem Zeitpunkt?** (Empfehlung: spätestens mit Phase-2-Release des Heatmap-MVP — aus Glaubwürdigkeitsgründen) 4. **Branding**: „CDU-/MIT-Tool" vs. „neutrales Werkzeug, von MIT initiiert"? Stark unterschiedliche Außenwirkung. 5. **Hosting-Träger**: MIT-Verein? Stiftung? Privatperson? hat Haftungs- und Datenschutzfolgen. ## Anhang C — Vorbilder weltweit (auf wessen Schultern wir stehen) ### C.1 Akademisch / methodisch (direkt verwendbare Verfahren) | Quelle | Was sie liefern | Wie wir es nutzen | |---|---|---| | **Coupette, Beckedorf, Hartung, Bommarito, Katz** — *„Measuring Law Over Time"*, Frontiers in Physics 2021 | Netzwerk-Analyse des **gesamten deutschen Bundesrechts** über 20 Jahre; Knoten-/Kanten-Schema, Komplexitäts-Metriken | **Methodisches Fundament für S2 (Norm-Graph)** — wir kopieren das Schema, nicht den Code | | **Bommarito & Katz** — *„A Mathematical Approach to the Study of the United States Code"* (2010) | Gründungstext quantitativer Rechtsnetz-Analyse; Graph-Bau, Tiefen-/Verweis-Metriken | Konzeptuelle Inspiration; Graph-Theorie-Grundlagen | | **Katz et al.** — diverse Arbeiten (Illinois Tech / Bucerius) | Computational Legal Analytics als Disziplin | Peer-Reviewer und potenzielle Kooperationspartner | | **Mercatus Center / QuantGov** (George Mason) — RegData, US/StateRegData | **NLP-basiertes Zählen von „regulatory restrictions"** (must/shall/may not/prohibited/required) im gesamten US-Bundesrecht und je Bundesstaat. **Open Source.** | **Direktes Vorbild für S3 (Pflicht-Extraktion)** — Pattern-Listen, Konfidenz-Metriken | | **Daniel Martin Katz, Jens Frankenreiter, Holger Spamann** | Computational Law-Community, mehrere relevante Konferenz-Papiere | Peer-Review-Netzwerk | ### C.2 Institutionell / politisch (Methodik-Anerkennung) | Institution | Was sie liefern | Wie wir andocken | |---|---|---| | **Nationaler Normenkontrollrat (DE)** | Standardkostenmodell (SKM), Erfüllungsaufwand-Konzept, „One in, one out", veröffentlichte Stellungnahmen zu ~allen neuen Gesetzen | **Methodisches Fundament für S4 (SKM-Score)**; Stellungnahmen als RAG-Quelle; Ehemalige als Beiratsmitglieder | | **EU REFIT + Regulatory Scrutiny Board** | „Fitness Checks" bestehender Gesetzgebung (Lebensmittel, Chemikalien, Verkehr); veröffentlichte Methodik (*Better Regulation Toolbox*) | Vorbild für die *politische* Prozessform eines „ex-post Audit" | | **EU Better Regulation Guidelines + Toolbox** | Offizielle EU-Methodik für RIA, MCDA, Cost-Benefit | Direkt zitierbare Methodik-Referenz im Methodik-Papier | | **UK Better Regulation Executive + Regulatory Policy Committee (RPC)** | Unabhängige Bewertungsstelle wie NKR; veröffentlichte „Opinion"-Datenbank | Vorbild für unabhängige Letzt-Validierung | | **UK „Red Tape Challenge" 2011–2014** | ~21.000 UK-Regulierungen wurden öffentlich-crowd-gereviewt | **Vorbild für Phase-3-Crowd-Input** + *Lessons Learned* zur Vermeidung des UK-Endergebnis-Problems (politisch verwertbare Bilanz unklar) | | **Niederlande — ATR (ehem. Actal)** | Erfinder des SKM in den 1990ern; >25 Jahre Praxiserfahrung | Methodik-Tiefenreferenz; ggf. Beirats-Stimme | | **Australien — Productivity Commission** | Regelmäßige Regulierungs-Audits, Bench-Studien | Vorbild für Output-Form („Inquiry Report") | | **Canada — Red Tape Reduction Act 2015** | Gesetzlich verankertes „One-for-one"-Prinzip | Politisches Vorbild für Reform-Vorschlagstyp | | **OECD iREG-Indikatoren** | Internationale Vergleichsmetriken für regulatorische Qualität | Benchmarking-Daten für Validierung unserer Scores | ### C.3 Standards & Datenstrukturen (Pflicht, nicht neu erfinden) | Standard | Zweck | Verwendung | |---|---|---| | **Akoma Ntoso** (OASIS, vom EU-Parlament seit 2016 verwendet) | XML-Format für Gesetzestexte | **Internes Korpus-Format** (S1) | | **ELI — European Legislation Identifier** | Kanonische URIs für Gesetze | **ID-System** für Norm-Knoten | | **CELEX** | EU-Dokument-IDs | EU-Knoten-IDs | | **LegalRuleML** (OASIS-Arbeitsgruppe) | RuleML-Erweiterung für deontische Logik (Pflicht/Erlaubnis/Verbot) | **Datenmodell für S3 (Pflicht-Tupel)** | | **Hohfeldian Analysis + Deontische Logik** | Seit ~100 Jahren juristisch-formaler Apparat für „wer schuldet wem was" | Konzeptuelle Grundlage Pflicht-Typologie | | **ECLI** | Case-Law-IDs (für spätere Rechtsprechungs-Anbindung) | Phase 3+ | ### C.4 Wirtschafts-/Statistik-Datenquellen (Adressatenzahlen, Tarife) | Quelle | Was sie liefern | |---|---| | **DESTATIS GENESIS-Online** | Unternehmensregister nach WZ-Code, Bundesländer-Ebene | | **DESTATIS Bürokratiekostenindex (BKI)** | Quartalsweise Benchmark seit 2012 | | **IHK Berlin** | Berlin-spezifische Mittelstandszahlen | | **Handwerkskammer Berlin** | Handwerks-spezifische Datenbasis | | **ifo Institut, ZEW, IW Köln** | Veröffentlichte Erfüllungsaufwands-/Standortkosten-Studien | | **DIHK Bürokratie-Reports** | Branchen-Umfragen | | **BDI / ZDH Stellungnahmen** | Qualitative Belastungs-Schilderungen (RAG-Quelle für S4 Frust-Score) | ### C.5 Was es noch *nicht* gibt — unsere Nische - Keine **per-Pflicht**-Bewertung auf typisiertem Norm-Graph für deutsches Recht - Kein **Mittelstands-fokussierter** Heatmap-Output mit Branchen-Differenzierung (WZ-Codes) - Kein **ex-post Fitness-Check-Tooling** auf Berliner Landesebene - Kein **deterministisches, audit-fähiges** Bewertungs-System (alles bisher entweder kommerziell-closed oder akademisch-einmalig) Genau diese vier Lücken füllen wir — keine davon ist trivial, aber jede ist klar abgegrenzt und für sich messbar. ### C.6 Konkrete „erst lesen, dann coden"-Liste Bevor `law.graph_build` oder `law.duty_extract` programmiert wird: 1. Coupette et al. 2021 vollständig lesen (ca. 1 Nachmittag) — Graph-Schema verstehen 2. Mercatus QuantGov *RegData*-Methodik-Paper lesen — Pattern-Listen verstehen 3. NKR-Methodenleitfaden „Erfüllungsaufwand" lesen — SKM in der DE-Anwendung verstehen 4. Akoma-Ntoso-Spezifikation überfliegen (nicht voll lesen) — Datenmodell verstehen 5. EU Better Regulation Toolbox überfliegen — politische Vokabel verstehen Das ist **eine Woche Vorarbeit, die ein halbes Jahr Code-Umbau spart**.