fai/reclaim
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
reclaim/MACHBARKEITSSTUDIE.md
flemming-it 90b7500aaf docs: drop 'vormals F∆I-Plattform' legacy clarification 
The Ch∆In rename is months old and the AG audience never knew
the previous name. Calling out 'vormals …' in three places —
the study header, the glossary, and the About page — added
noise without informing anyone. Ch∆In stands on its own.

Signed-off-by: flemming-it <sf@flemming.it>
2026-06-18 13:18:30 +02:00

50 KiB
Raw Blame History

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 — 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)

# 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 Vollzugsvorschriften, 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): 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.