Zielbild: Language Brain — Lenny deutet und formuliert selbst¶

Stand 2026-08-10. Design-Grundlage (kein Code), Schritt-für-Schritt umsetzbar. Anlass: Lenny hat heute kein echtes Satzverständnis — er erkennt den Satztyp (Frage/Aussage) über Wortstellung, aber die Bedeutung nicht; „Intent" entsteht aus Stichwort-Regexen (der \bfalsch\b-Fehlfeuer-Fall). Frage von Marco: statt zu patchen ein durchdachtes Ziel ansteuern, bei dem Lenny das künftig selbst kann — und das Language Brain schon jetzt lernen lassen, wie die LLM formuliert.

1. Das Ziel in einem Satz¶

Lenny soll Äußerungen verstehen und Antworten formulieren ohne Laufzeit-LLM — erlernt, verifiziert, doktrin-treu — und die Interim-LLM Schritt für Schritt ablösen, ohne je ihre Halluzination zu erben.

Zwei getrennte Fähigkeiten: - Interpretation (Eingang): Äußerung → Bedeutung/Intent/Struktur. - Formulierung (Ausgang): verifizierte Fakten → flüssiger deutscher Satz.

2. Der eine Wächter, der über alles entscheidet: Form, nicht Fakt¶

Die LLM ist Flüssigkeits-/Struktur-Lehrer, niemals Wahrheits-Lehrer.

Von der LLM gelernt wird das Wie: Grammatik, Satzbau, Formulierung, das Parsen von Absichten.
Niemals das Was: Inhalt/Fakten kommen ausschließlich aus dem verifizierten Graphen. „Lernen wie die LLM antwortet" = rohes Imitieren wäre der Doktrin-Bruch schlechthin (Halluzination würde in Lenny destilliert).

Konkret heißt das: jeder Sprach-Lernschritt läuft durch eine Verifikation vor dem Schreiben, schreibt nur in den lang-Namespace, nie in Knowledge/FactGraph, und bleibt Kandidat, bis er sich über Wiederholung/Prüfung bewährt.

3. Loop A — Formulierung (Fakt → flüssiger Satz)¶

Existiert bereits als Shadow-Pipeline (Phase 5B), ist nur abgeschaltet.

Datenfluss (im Code vorhanden):

run_language_shadow()
  → verify_text_template()            # reine Verifikation, Tor
  → run_language_learning()  (wenn passed)
     → language_candidate_bus  (tmp_language_learning_candidates)
     → language_store          (lang-Namespace, raw)
     → lifecycle               (raw → promoted bei Support-Schwelle)

Harte Invarianten (stehen wörtlich im Code, core/language_learning.py): - Läuft im Schatten, parallel, berührt ask_lenny nicht. - Kein Schreiben ohne bestandene Verifikation. - Kein Write in Knowledge Store / FactGraph / Brain; strikter lang-Namespace; keine Cross-Promotion zu Wissen. - Flags Default AUS: LENNY_SHADOW_LANGUAGE_LEARNING_ENABLED, LENNY_LANGUAGE_CANDIDATE_BUS_ENABLED, LENNY_LANGUAGE_STORE_ENABLED, LENNY_LANGUAGE_LIFECYCLE_ENABLED.

Teacher-Signal heute: im Interim formuliert die LLM (LENNY_OUTPUT_MODE=llm_assistant) die Ausgabe. Genau diese verifizierten Formulierungen wären der Trainingsstoff für Loop A — Marcos „schon jetzt lernen, wie die LLM antwortet", doktrin-sicher.

Reifepfad: 1. Shadow scharf (null Produktionsrisiko) → verifizierte Sprachmuster sammeln. 2. Messen: entstehen brauchbare, wiederverwendbare Muster (slot_pattern) mit Support? (Kennzahl analog zum Relations-Vielfalt-KPI.) 3. Deterministischer Renderer (fragment_bound_surface_generation.py, seit 2026-08-10 mit Groß-/Kleinschreibung + Genus/Artikel) zieht die gelernten Muster heran → wird schrittweise besser als die Interim-LLM. 4. Wenn der Renderer eine Antwortklasse verifiziert-gut abdeckt → LLM für diese Klasse abschalten. LLM-frei erreicht man klassenweise, nicht per Big-Bang.

4. Loop B — Interpretation (Äußerung → Bedeutung/Intent)¶

Noch nicht gebaut. Symmetrisch zu Loop A zu konstruieren.

Der Screenshot-Fall zeigt die Lücke: „Was machen wir falsch?" wird zur Korrektur umgedeutet. Bausteine, die es schon gibt: - utterance_type_classifier — Satztyp über Wortstellung (Frage/Aussage/Aufgabe). Funktioniert: erkennt den Satz korrekt als Frage. = deterministisches, doktrin-treues Struktur-Signal. - utterance_tagger — flache Stichwort-Regexe (der ratende, fehlfeuernde Layer). - claim_extractor (claim_layer) — Regex-SVO für einfache Sätze. - Kein echter Parser (kein spaCy/Dependency); lemma_normalizer ist bewusst nur Heuristik.

Design des Loops:

Äußerung
  → deterministisches Struktur-Signal (Typ-Klassifikator, SVO)   # Wahrheits-Lehrer
  → LLM-Deutung (Intent/Parse)                                    # Flüssigkeits-Lehrer
  → Abgleich: LLM-Deutung nur als Kandidat, VERIFIZIERT gegen das Struktur-Signal
  → Language/Intent-Store (Kandidat, lang-Namespace, Support-Schwelle)
  → später: Lenny deutet deterministisch, LLM nur noch als Fallback, dann gar nicht

Schlüssel-Einsicht: die deterministischen Guards sind das Ground-Truth-Signal dieses Loops, kein Wegwerf-Patch. Der Frage-Schutz („eine Frage ist keine Korrektur") und die Anbindung des Typ-Klassifikators an den Korrektur-Pfad sind gleichzeitig (a) der Sofort-Fix und (b) das Trainingssignal, gegen das die LLM-Deutung geprüft wird. Bauen wir sie, wächst der Loop von selbst mit.

Doktrin für Intent (die eigentliche Lehre aus der \bfalsch\b-Frage): „Alles ist Kandidat" gilt auch für die Absicht. Eindeutige Deutung (starke Evidenz) → handeln. Schwache/mehrdeutige (Stichwort in einer Frage) → nicht selbstsicher handeln, sondern verhalten wie der Verweigerungspfad bei Fakten (unsicher rückfragen / als das behandeln, was es strukturell ist).

5. Gemeinsame Doktrin-Invarianten (für beide Loops verbindlich)¶

Form von der LLM, Fakt nur aus dem Graphen. Nie rohes Imitieren.
Verifikation vor jedem Schreiben. Kein ungeprüfter Kandidat wird Muster.
Alles ist Kandidat — Formulierung UND Deutung; Bewährung über Wiederholung/Prüfung, kein Auto-Promote in Wissen.
Schatten zuerst. Lernen läuft parallel, beeinflusst den Produktivpfad erst, wenn ein Muster verifiziert-reif ist.
Namespace-Isolation. lang bleibt strikt getrennt von truth/creative; keine Cross-Promotion.
Proof = Gewicht, nicht Veto (Signal-Architektur): ein gelerntes Sprachmuster verstärkt/formt, es blockiert keine belegte Antwort.
LLM-frei klassenweise, nie per Big-Bang; jede abgeschaltete Klasse ist vorher deterministisch verifiziert-gut.

6. Komponenten-Landkarte (Ist → Ziel)¶

Komponente	heute	Rolle im Zielbild
`language_store.py`	vorhanden, Muster+slot_pattern	Loop A Speicher
`language_candidate_bus.py`	vorhanden	Loop A Kandidaten-Bus
`language_learning.py` / `language_shadow`	vorhanden, AUS	Loop A Runner
`verify_text_template()`	vorhanden	Loop A Wahrheits-Tor
`fragment_bound_surface_generation.py`	Renderer + Tier1/2-Grammatik	Loop A Nutznießer/Ablöser der LLM
`utterance_type_classifier.py`	funktioniert (Wortstellung)	Loop B Wahrheits-Signal
`utterance_tagger.py`	ratender Cue-Layer	Loop B: unter Kandidaten-Disziplin ziehen
`claim_extractor.py`	Regex-SVO	Loop B Struktur-Signal (einfach)
Interim-LLM (`llm_assistant`)	formuliert Ausgabe	Lehrer beider Loops, wird abgelöst

7. Offene Entscheidungen (für Marco)¶

Reihenfolge: erst Loop A scharf (Formulierung sammeln, messbar, risikolos) oder erst Loop B (Interpretation, behebt sichtbare Fehler wie den Screenshot)?
Messung zuerst: einen KPI/Report für Loop A bauen (wie Relations-Vielfalt), bevor irgendwas scharf geht — ja/nein?
Interim-LLM als Lehrer festschreiben: dürfen wir die LLM-Formulierungen (nur verifiziert) als Trainingsstoff dauerhaft mitschneiden (append-only, lang-Kandidaten), auch bevor Loop A/B produktiv sind?
Frage-Schutz jetzt (Sofort-Fix + erstes Loop-B-Ground-Truth) oder mit Chris' QA bündeln?

Nichts davon wird ohne dein Go umgesetzt. Dieses Doc ist die Grundlage; die WAITING.md verweist darauf.