Wir haben an einem Nachmittag einen GOAP-Planner gebaut. Er liefert für Engineering-Ziele in null Millisekunden einen sauberen Neun-Schritte-Plan. An eine Klageabweisung lassen wir ihn nicht heran. Hier ist, warum — und die vier Schleusen, die wir vorher schließen würden.
Das Versprechen und das Urteil
Goal-Oriented Action Planning (GOAP) ist die Architektur, die Schachengines nutzen: einen Baum möglicher Zukünfte halten, den günstigsten Pfad von hier zum Ziel suchen, den Rest verwerfen. Das passt für Litigation deutlich besser als ein Chat-Modell. Anträge, Discovery, Prozesse — alles Sequenzen von Zügen unter Nebenbedingungen. Chat-Modelle produzieren den nächsten plausiblen Satz. Planner legen sich auf ein Ziel fest und arbeiten rückwärts.
Die wichtigsten Fakten
- Ein funktionsfähiger A*-GOAP-Planner besteht aus 517 Zeilen reinem JavaScript ohne Abhängigkeiten — an einem Nachmittag aus ruflos claude-flow goal_ui portiert.
- ruflos claude-flow-GOAP-Planner implementiert kein adaptives Replanning: plan() führt A* genau einmal bei der Zielübermittlung aus — verifiziert an den Aufrufstellen in Index.tsx und ResearchReportModal.tsx (EXTERNAL-CITE: ruflo claude-flow Quelltext, direkt gelesen).
- Wer vor der Geltendmachung der Schiedsklausel einen materiellen 12(b)(6)-Antrag stellt, kann nach Morgan v. Sundance (2022) das Recht auf ein Schiedsverfahren verwirken — ein Shortest-Path-Planner läuft direkt hinein.
Also haben wir einen gebaut. 517 Zeilen reines JavaScript, keine Abhängigkeiten, an einem Nachmittag aus dem GOAP-A*-Planner portiert, der in ruflos `goal_ui`-React-App steckt. Er läuft bei Engineering-Zielen wie „ship the auth refactor with tests and a PR“ in null Millisekunden und liefert einen sauberen Neun-Schritte-Plan.
An einen echten Antrag lassen wir ihn nicht heran. Noch nicht. Dieser Beitrag erklärt, warum, und was sich ändern müsste, bevor wir es täten. Wer hierhergekommen ist für eine atemlose Empfehlung des nächsten KI-Dings für Anwälte, findet hier das Gegenteil: die Messlatte an Sorgfalt, die wir setzen, bevor wir ein Litigation-Ziel durch irgendeinen Planner laufen lassen — unseren, den von ruflo, irgendeinen —, und die Lücke zwischen dem heutigen Planner und dieser Messlatte.
Was GOAP tatsächlich ist
GOAP nimmt drei Eingaben: einen Zielzustand (Fakten, die wahr sein sollen — „PR ist offen“, „CI ist grün“, „deployed“), einen Ausgangszustand (was gerade zutrifft) und eine Aktionsbibliothek (jeder mögliche Zug, jeweils mit Vorbedingungen und Effekten — „`open_pr` erfordert `pushed=true` und `diff_reviewed=true`; setzt `pr_open=true`“). Dann läuft eine A*-Suche — derselbe Algorithmus, mit dem GPS um Stau herumroutet — über den Raum der Aktionssequenzen und liefert den günstigsten gültigen Pfad vom Ausgangs- zum Zielzustand. Schlägt ein Schritt während der Ausführung fehl, soll vom neuen Zustand aus neu geplant werden.
Für Anwälte ist die naheliegendste Analogie das Schach. Ein Großmeister denkt nicht einen Zug nach dem anderen; er hält einen Baum möglicher Zukünfte im Kopf und beschneidet ihn, während sich die Partie entwickelt. GOAP ist genau das, nur mechanisiert. Es ist nicht generativ, es ist Suche.
Die Architektur passt fast zu gut auf Litigation. Ein Antrag auf Verweisung ins Schiedsverfahren hat harte Vorbedingungen (eine Schiedsklausel existiert, eine Klage wurde zugestellt, noch kein Sachantrag wurde gestellt) und harte Effekte (Verwirkungsrisiken ausgeschlossen, das Gericht muss über die Schiedsfähigkeit entscheiden). Discovery hat eine strikte Reihenfolge (schriftliche Anfragen vor Depositions, Class-Zertifizierung vor der Sache, Meet-and-confer vor Anträgen auf Erzwingung). Summary Judgment hat ein Pass/Fail-Orakel. Die Form der Arbeit ist GOAP-förmig.
Was wir gebaut haben
Vier Dateien: `planner.js` (165 LOC, A* + binärer Min-Heap), `actions.js` (134 LOC, zwölf Engineering-Aktionen), `parse.js` (58 LOC, Phrasentabelle, die Englisch in einen Zielzustand übersetzt), `cli.js` (160 LOC, Runner). Insgesamt 517 LOC. Keine npm-Abhängigkeiten. In zwanzig Minuten lesbar.
Wir haben ihn gegen das Ziel „ship the auth refactor with tests and a PR“ laufen lassen:
goal predicates: {"pr_open":true,"ci_green":true,"deployed":true}
1. understand_code (cost 2) -> /zoom-out
2. write_tests (cost 3) -> /tdd
3. run_tests (cost 1) -> bash:test
4. review_diff (cost 1) -> /review
5. commit (cost 1) -> git:commit
6. push_branch (cost 1) -> git:push
7. open_pr (cost 1) -> /ship
8. wait_ci (cost 5) -> bash:ci-wait
9. merge_and_deploy (cost 2) -> /land-and-deploy
total cost: 17
expansions: 13 time: 0 ms found: trueNeun Schritte, Kosten 17, dreizehn Node-Expansionen, null Millisekunden. Jeder Schritt bildet auf einen gstack-Skill oder einen Shell-Befehl ab, der Plan ist also ausführbar — nicht dekorativ. Wir haben außerdem ein kleineres Ziel getestet („test the login module“ — 3 Schritte, Kosten 6) und ein unerfüllbares (ein Prädikat, das keine Aktion setzt — es lieferte `found: false` mit dem nächstliegenden Teilplan, statt abzustürzen oder sich zu verhaken). Alle drei Verhaltensweisen entsprechen der Spezifikation.
Das hat einen Nachmittag gedauert. Das ist nicht der schwierige Teil.
Warum wir das von ruflo portiert haben
Ruflo (das `claude-flow`-Ökosystem) liefert einen GOAP-Planner in seiner `goal_ui`-React-App mit — `goapPlanner.ts`, eine einzelne Datei, 180 Zeilen. Die Architektur ist solide. Wir haben ihn extrahiert.
Während wir dabei waren, haben wir den Quelltext genau gelesen. Eine Behauptung, die den Kontakt damit nicht übersteht: Der Planner implementiert kein adaptives Replanning. Die Methode `plan()` führt A* genau einmal bei der Zielübermittlung aus und liefert ein `Step[]`, das eine UI-Animation antreibt. In der Datei gibt es keine Replan-Schleife, keine Plan-Invalidierung, keine Fehlerbehandlung. Wir haben die Aufrufstellen in `Index.tsx` und `ResearchReportModal.tsx` geprüft. Gleiches Bild.
Wir erwähnen das nicht, um auf ruflo herumzuhacken — der Kern des Planners ist guter Code —, sondern weil es für den Rest dieses Artikels wichtig ist. Adaptives Replanning ist das eine Feature, das man sich am meisten wünschen würde, bevor man einen Planner an ein echtes Mandat heranlässt, und die prominenteste Open-Source-Implementierung mit Rechtsbezug hat es nicht. Wir bislang auch nicht. Niemand, den wir uns angesehen haben, hat es.
Die drei Litigation-Ziele, die wir nicht durchlaufen haben
Der ursprüngliche Plan war, drei echte Litigation-Ziele durch den Planner laufen zu lassen und die Ausgabe von einem erfahrenen Prozessanwalt bewerten zu lassen. Das haben wir nicht getan. Zwei Gründe. Erstens hat das Leiten von Litigation-Strategie durch eine öffentliche Drittanbieter-URL — selbst synthetische Strategie zu einem hypothetischen Sachverhalt — Privilegien-Implikationen, die wir für einen Blogbeitrag nicht eingehen wollten. Was wir für einen Mandanten nicht tun würden, sollten wir auch nicht für uns selbst tun. Zweitens hat unsere Aktionsbibliothek zwölf Einträge, und alle sind Engineering-Aktionen: `understand_code`, `write_tests`, `commit`, `push_branch`, `open_pr`, `wait_ci`, `merge_and_deploy`. Ihn auf eine Klageabweisung anzusetzen, hätte einen Plan erzeugt, der einem Prozessanwalt selbstbewusst geraten hätte, seine Antwort zu `git commit`ten.
Die drei Testfälle, die wir formuliert haben, sind trotzdem nützlich — nicht als Benchmarks, die der Planner bestanden hat, sondern als Zwang, festzulegen, was die nächste Version können muss.
Fall 1 – Klageabweisung mit Schiedsklausel-Verteidigung. Prompt: „gewinne einen Rule-12(b)(6)-Antrag in einem Vertragsstreit, bei dem der Kläger eine Pflichtverletzung behauptet, der Vertrag aber eine eindeutige Schiedsklausel enthält.“ Der Haken: 12(b)(6) ist das falsche Vehikel. Ein Schiedsverfahren wird über FAA §§ 3–4 mit einem Antrag auf Verweisung erzwungen. Wer vor der Geltendmachung der Schiedsklausel einen materiellen 12(b)(6)-Antrag stellt, kann nach Morgan v. Sundance (2022) das Recht auf ein Schiedsverfahren verwirken. Ein Planner, der den 12(b)(6)-Antrag entwirft, bringt den Mandanten in Kunstfehler-Gefilde.
Fall 2 – Discovery-Strategie für eine Wage-and-Hour-Sammelklage mit 10 Beschäftigten (Kalifornien). Prompt: „entwirf einen Discovery-Plan mit Priorität auf kostengünstigen, hoch wirksamen Anfragen.“ Ein junger Associate würde sofort 30(b)(6)-Depositions vorschlagen. Der richtige Plan setzt schriftliche Anfragen vor Depositions, trennt die Class-Zertifizierung von der Sache, führt vor jeder Kontaktaufnahme mit einem mutmaßlichen Class-Mitglied den Belaire-West-Opt-out-Hinweis durch und lädt den externen Payroll-Dienstleister per Subpoena (sauberere Daten, schneller, keine Produktionskosten auf Beklagtenseite). Die Reihenfolge zählt hier mehr als der Inhalt.
Fall 3 – Summary Judgment zu einem Wettbewerbsverbot in Kalifornien. Zwei Fallen. Falle eins: Der Prompt zitiert „Labor Code § 16600“ — ein Zitat, das es nicht gibt. Die korrekte Fundstelle ist Business & Professions Code § 16600. Falle zwei: Selbst mit korrigiertem Zitat verliert der Arbeitgeber so gut wie sicher. SB 699 und AB 1076 (in Kraft seit 1. Januar 2024) haben § 16600 erweitert und einen privaten Klagegrund mit Anwaltskostenerstattung hinzugefügt. Der richtige Schritt ist, dem Mandanten zu raten, die Durchsetzung des Wettbewerbsverbots vollständig fallenzulassen und, sofern der Sachverhalt es hergibt, auf eine Geschäftsgeheimnis-Theorie nach CUTSA umzuschwenken. Ein Planner, der den kürzesten A*-Pfad zu „das Wettbewerbsverbot gewinnen“ findet, findet einen Pfad zu einem sanktionsfähigen Schriftsatz.
Diese drei Fälle teilen ein strukturelles Merkmal: Die wertvollste Ausgabe ist nicht ein Plan zum angegebenen Ziel des Nutzers. Es ist „dein Ziel ist falsch; hier ist das richtige Ziel“.
Das ist nicht, was A tut. A findet den kürzesten Pfad. Es findet auch die kürzesten Pfade zu verlierenden Strategien.
HAQQ AI kostenlos testen
Erleben Sie KI-gestützte juristische Recherche und Entwurf
Vier Schleusen, bevor wir das bei Litigation einsetzen
Das müsste sich ändern. Nichts davon ist theoretisch — das sind die vier obersten Punkte auf dem v0.2-Plan.
1. Die Aktionsbibliothek muss von Grund auf neu entworfen werden. Engineering-Aktionen haben eine Kostendimension (Entwicklerzeit) und saubere Vorbedingungen. Rechtliche Aktionen haben jurisdiktionelle Vorbedingungen (FAA gilt, Gericht liegt in Kalifornien, Schiedsklausel übersteht § 16600), gesetzliche Vorbedingungen, terminliche Vorbedingungen (Frist zur Klageerwiderung liegt 21 Tage entfernt) und adversariale Vorbedingungen (Gegenanwalt hat X noch nicht beantragt). Auch die Kostendimension ist eine andere: Geldkosten, Partnerstunden, Sanktionsrisiko, Risiko der Kostenverlagerung. Eine ernstzunehmende juristische Aktionsbibliothek umfasst wohl 200–500 Aktionen mit parametrisierten Prädikaten — eine echte Ontologie, geschrieben von Prozessanwälten, abgegrenzt nach Praxisgebiet.
2. Der Ziel-Parser muss echtes juristisches Englisch verarbeiten. `parse.js` ist eine Phrasentabelle mit fünf Einträgen. Sie bildet „ship the auth refactor“ per Substring-Abgleich auf `{pr_open, ci_green, deployed}` ab. Sie kann „gewinne einen Rule-12(b)(6)-Antrag in einem Vertragsstreit, bei dem der Vertrag eine eindeutige Schiedsklausel enthält“ nicht parsen. Die Lösung ist klein — Haiku im JSON-Modus, schemabegrenzt auf bekannte Prädikate. Etwa ein halber Tag. Die kleinste der vier Schleusen, und ohne die anderen drei sinnlos.
3. Der Planner muss selbst gehostet werden. Nichts von einem echten Mandantenfall kommt in die Nähe von `goal.ruv.io` oder irgendeiner Drittanbieter-URL. Abgesehen von den Privilegien-Bedenken kann man einen Planner nicht auditieren, den man nicht selbst betreibt. Selbst gehostet, auf Infrastruktur unter Kontrolle der Anwaltskanzlei, mit Logs, die der Kanzlei gehören. Für HAQQ nicht verhandelbar.
4. Der Planner muss wissen, wann er das Ziel ablehnen soll. Die schwierigste Schleuse. Ein reiner A-Planner, der immer den kürzesten Pfad findet, führt verlierende Strategien wunderbar sauber aus. Die Lösung ist nicht nur adaptives Replanning (A erneut ausführen, wenn eine Aktion fehlschlägt). Die Lösung ist Goal Critique: ein Legal-AI-Schritt, der vor der Planung läuft, das Ziel gegen die Dogmatik prüft (§ 16600 + SB 699 + AB 1076 — „diese Durchsetzungsklage verliert“) und ein alternatives Ziel vorschlägt („Umschwenken auf CUTSA“). Replanning behebt Ausführungsfehler. Goal Critique behebt den tieferliegenden Fehlermodus — sich vollständig auf ein falsches Ziel festzulegen. Beides ist nötig; heute ist keines von beiden implementiert.
Was das über KI in der Rechtsarbeit lehrt
Die meisten KI-Produkte optimieren auf „gib mir eine selbstbewusste Antwort“. Das ist die falsche Form für Litigation, wo die Aufgabe darin besteht, die Frage zu hinterfragen, zu erkennen, was der Mandant zu wollen glaubt versus was er tatsächlich braucht, und den Zug zu finden, den der junge Associate übersehen hätte.
GOAP kommt dieser Form näher als Chat. Es ist strukturell ehrlich: Es sagt einem, wenn es das Ziel nicht erreichen kann. Es legt die Sequenz offen, nicht nur die Schlussfolgerung. Es lässt sich prüfen, auditieren, erneut abspielen.
Aber „näher als Chat“ heißt nicht „gut genug für die Rechtsarbeit“. Die Messlatte ist nicht „erzeugt einen Plan“. Die Messlatte ist „erzeugt einen Plan, für den ein Partner seinen Namen hergibt“. Das heutige GOAP, unseres eingeschlossen, erreicht die erste Messlatte. Die nächste Version muss die zweite erreichen. Wir sind der Meinung, dass niemandem, der heute einen Planner verkauft — unseren eingeschlossen —, bei einem laufenden Mandat vertraut werden sollte, solange die vier oben genannten Schleusen nicht geschlossen und nachgewiesen sind.
Wie es weitergeht
- Goal-Critique-Schritt (v0.2). Haiku im JSON-Modus mit dem Durchgang „dieses Ziel gegen die Dogmatik prüfen; bei Aussichtslosigkeit eine Alternative vorschlagen“, bevor der Planner läuft.
- Legal-AI-Ziel-Parser (v0.2). Ersetzt die Phrasentabelle.
- Adaptives Replanning (v0.2). `plan()` in eine Ausführungsschleife einbetten, die bei einem Fehlschlag neu sucht. Rund 50 Zeilen.
- Juristische Aktionsbibliothek (v0.3). Abgegrenzt nach Praxisgebiet, geschrieben mit Prozessanwalt-Review, parametrisierte Prädikate. Monate an Arbeit — und das eigentliche Produkt.
Sobald diese vier real und getestet sind, lassen wir die drei oben genannten Litigation-Fälle laufen und veröffentlichen die Ergebnisse — einschließlich der Fehlschläge, einschließlich der Kritik der Prozessanwälte. Bis dahin ist die einzige ehrliche Ausgabe diese hier: ein Engineering-Planner, der funktioniert, ein juristischer Planner, den es noch nicht gibt, und die Design-Notizen dafür, wie der zweite aussehen muss.
