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