feat: initial F∆I Law-Heatmap Phase 0 scaffold

First end-to-end-buildable cut of the pflicht-/graph-basierte
Wirkungsanalyse von Rechtsnormen, running on Ch∆In. Demo runs
without external dependencies and without a hub connection so
the methodology + UI stack can be reviewed before any Verbands-
Kooperation or Beirats-Validierung kicks in.

Tree layout

  MACHBARKEITSSTUDIE.md       v0.3 — pflicht-basierte Methodik,
                              4-Tier-Evidenz, 8 law*-Module
                              auf Ch∆In statt der alten F∆I-
                              Plattform.
  RUN.md                      one-page how-to-run.
  flows/durchstich-gewo-14.yaml
                              vertical Phase-0 flow: pull →
                              normalize → duties → citations →
                              cohort → skm → frust → benefit →
                              attribution → system.approval.
  app/                        Flutter macOS client, design
                              language pulled from fai_web
                              (ink #08090A, paper #F4F3EF,
                              petrol signal #2E8F9E). Mock
                              repository ships five fixture
                              norms with real source URLs and a
                              permanent T4 demo-banner so no
                              figure can be mistaken for a
                              validated one.

Module repos (separate, see chain-modules*/):

  text-akoma-normalize, text-deontic-extract, graph-citation-
  extract, text-readability-score, stats-cohort-size, graph-
  shapley-attribution, econ-skm-score, law-benefit-score.

What runs today

  - flutter analyze: 0 issues
  - flutter test: 2/2 (landing + nav-to-shell smoke)
  - flutter build macos (via app/build-macos.sh) and ad-hoc
    codesign, app launches and the Dart VM service comes up
  - native cargo test green on every module
  - cargo build --release --target wasm32-wasip2 produces a
    130 KiB artefact for text-akoma-normalize

What is deliberately mock / stub

  - gRPC wire from the client to a chain serve hub (Repository
    abstraction is in place; live impl is the next step)
  - NKR Bürokratiekosten-Datenbank ingestion (for the canonical
    h-Werte that close out the Engpass per Studie §6.7)
  - DESTATIS GENESIS-API adapter for stats.cohort_size

License: Apache-2.0. Author/contact in MACHBARKEITSSTUDIE.md.
Signed-off-by: flemming-it <sf@flemming.it>

MACHBARKEITSSTUDIE.md

@@ -0,0 +1,979 @@
+# F∆I Law-Heatmap — 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** (vormals „F∆I-Plattform" / `fai_platform`) — Hub/Module/Flow, WASM-Sandbox, tamper-evidentes Audit-Log; Vendor weiterhin **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/lawheatmap` 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_lawheatmap/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`, vormals F∆I-Plattform): Orchestrierungs-Plattform unter `fai_lawheatmap`. 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**.