Rule Engine — Zielsetzung

Status: Entwurf · Quelle: projektmike/output/gettingtoyes/technik.md, input/input_entscheidungen_2026_04_15.md

Warum eine Regelengine?

Bestehende Geschäftslogik liegt in Excel-Regelwerken verteilt über die Töchter. Diese sind:

nicht versioniert
nicht testbar
nicht systematisch validierbar
schwer wartbar
nicht mehrfach nutzbar

Ziel: Überführung in deklarative, versionierte, testbare Regeln, die Modelle und Validierungen treiben.

Anforderungen

Anforderung	Begründung
Deklarativ	Fachexperten lesen und schreiben Regeln, ohne Programmiersprache.
Versioniert	Regelstand zum Zeitpunkt einer Case-Freigabe ist später nachvollziehbar.
Testbar	Pro Regel mindestens ein Testfall mit Ein-/Ausgabe (Golden Data).
Erklärbar	Bei Validierungsfehler sichtbar, welche Regel zugeschlagen hat.
Komponierbar	Regeln modular kombinierbar; eine „Mieterstrom-Regel” referenziert „PV-Auslegungs-Regel”.
Performant	Regeln laufen auf großen Stammdatenbeständen ohne Sekunden-Latenz.
Sicherheit	Regeln sind kein Codeausführungs-Pfad — keine `eval()`-artige Mechanik.

Kandidaten für die Regelsprache

(Endgültige Entscheidung offen — siehe docs/spec/90-governance/03-open-questions.md OP-14, OP-47.)

JsonLogic

Pro: einfach, JSON-basiert, viele Bindings
Pro: serialisierbar
Contra: kein Typsystem, schwierig bei komplexen Berechnungen

CEL (Common Expression Language)

Pro: Google-Standard, typisiert, gut lesbar
Pro: Java/Go/JS-Implementierungen
Contra: in Node-Welt weniger verbreitet

TypeScript-Regel-Kern

Pro: volle Typsicherheit
Contra: Regeln sind Code, nicht Daten — Versionierung schwieriger

Eigenes DSL

Pro: optimal auf die Domäne zugeschnitten
Contra: Bau- und Wartungsaufwand

Aktuelle Tendenz: JSON-basiert (JsonLogic oder Variante) für einfache Validierungen, CEL für komplexere; Hard-Cases als TypeScript-Funktionen, die aus den Regeln aufgerufen werden.

Drei Regel-Typen

Typ	Zweck	Beispiel
Validierungsregel	Strukturelle Korrektheit	„Mieterstrom-Vertrag erfordert installierte PV-Anlage am gleichen Gebäude.”
Berechnungsregel	Kennzahlen aus Stammdaten	„Eigenverbrauchsquote = Direktverbrauch / PV-Erzeugung.”
Constraint-Regel	Optimierungs-Constraints für Solver	„Provider-Mix für Gewerk Y darf max. 3 Anbieter umfassen.”

Harte vs. weiche Constraints

In Anlehnung an klassische Stundenplan-/Schedulingprobleme wird zwischen zwei Constraint-Klassen unterschieden, die der Solver getrennt behandelt:

Klasse	Bedeutung	Beispiel
Hart	muss zwingend erfüllt sein	Cross-Tenant-Verträge sind nicht zulässig · ein aktiver Mietvertrag pro Wohneinheit · gesetzliche Eichfrist nicht überschritten · Holding-Cashflow ≥ 0 (Mandats-Annahmebedingung)
Weich	wünschenswert, optimierbar — Verletzungen werden mit einer Strafe gewichtet	Marge je Tochter („grün”) · Vorzugs-Provider-Mix · ausgeglichene Mitarbeiterauslastung · Mindestgröße Speicher relativ zur PV-Leistung

Das globale Optimierungsziel (Holding-Cashflow positiv) ist hart, lokale Profitabilität je Tochter ist weich. Mandate werden also auch dann angenommen, wenn einzelne Module negativ rechnen, solange der Verbund profitabel bleibt.

KI-Solver-Architektur

Constraint-Solving (NP-schwer) löst die KI nicht selbst, sondern unterstützt im Modellierungs-Pfad:

KI übersetzt die fachlichen Annahmen, Regeln und Constraints in ein mathematisches Modell.
Ein dedizierter Constraint-Solver (z. B. CP-SAT, OR-Tools, Pyomo/HiGHS) löst das Modell heuristisch — gute, nicht zwingend optimale Lösung.
KI rückübersetzt das Solver-Ergebnis in fachlich verständliche Empfehlungen.
Die Regelengine validiert die Empfehlung gegen die hart-Constraints, bevor sie als „Prompt Proposal” an einen menschlichen Prüfer geht.

Detail siehe 02-calculation-overview.md (Solver-Kopplung, V2).

Verbindung zu `validation_rule` der Spec

Spec-Modell hat in entity_type_attribute.validation_rule jsonb einen Slot — Inhalt offen (docs/spec/90-governance/03-open-questions.md OP-14). Die hier diskutierte Engine füllt diesen Slot.

Verbindung zur KI-Schicht

Agent macht Vorschläge — Regelengine validiert. KI darf vorschlagen, die Regelengine validiert. (Quelle: projektmike/output/gettingtoyes/story.md.) Damit:

KI-Output ist nie unmittelbar wirksam
Regelengine ist Gatekeeper
Erklärbarkeit bleibt erhalten