reclaim/MACHBARKEITSSTUDIE.md

# 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**.