WFGY: ein Protokoll-Ökosystem im gestaffelten Rollout

Ein Ökosystem statt eines Pakets

WFGY tritt nicht als einzelne Bibliothek auf, sondern als Sammlung mehrerer Schichten. Die README beschreibt die aktuelle Führungsebene als WFGY 5.0 Polaris Protocol, darunter liegen WFGY 4.0 als Governance-Engine, WFGY 3.0 als Reasoning- und Verifikationsschicht sowie Problem Map 3.0 als Einstieg für defekte Workflows. Dazu kommen Nebenschauplätze wie das Cite First Verification Easter Egg und der Polaris Goal Compiler. Das Repository ist in Jupyter Notebook als Hauptsprache angelegt, was auf experimentelle Arbeit hindeutet: Notebooks als Träger von Protokollen und Auswertungen, nicht als klassischer Anwendungscode. Wer hier eine importierbare Python-Bibliothek sucht, sucht am falschen Ort. Die README selbst formuliert die Abgrenzung scharf: WFGY 5.0 sei kein AI-Writing-Preset, kein statisches Persona-Spielzeug und kein als Produkt verkleidetes Prompt-Paket. Stattdessen nennt sie sechs Punkte, darunter eine governed protocol layer, eine topology-first experiment route und eine reusable verification surface. Das ist eine Selbstbeschreibung, keine überprüfbare Funktionsgarantie.

Problem Map 3.0 als praktischer Einstieg

Der konkreteste Teil des Repositories ist die Problem Map. Die README verlinkt sie unter dem Pfad ProblemMap/wfgy-ai-problem-map-troubleshooting-atlas.md und beschreibt sie als schnellsten praktischen Einstieg, wenn ein System bereits kaputt ist. Dazu gehören laut Routing-Abschnitt der Atlas Router TXT, eine Global Debug Card und eine Global Fix Map. Das Muster ist eine Fehlerlandkarte: Symptome werden klassifiziert, einer Route zugeordnet und mit Fixes verknüpft. Der Vorteil gegenüber freiem Debugging liegt in der Struktur. Wer eine RAG-Pipeline betreibt und nicht weiß, ob das Retrieval, das Reranking oder der Prompt die falschen Antworten erzeugt, bekommt eine vorgegebene Klassifikation statt einer offenen Fehlersuche. Der Nachteil: Die Problem Map ist ein Dokument, kein Instrument. Sie führt keinen Code aus, misst keine Latenz und vergleicht keine Embeddings. Sie liefert Vokabular und Reihenfolge. Ob die vorgeschlagenen Fixes zu deinem Stack passen, entscheidet die Karte nicht.

Der gestaffelte Rollout von WFGY 5.0

Die README erklärt, dass WFGY 5.0 nicht mehr als Einzeltermin veröffentlicht wird. Stattdessen läuft ein staged functional rollout, bei dem nützliche Teile in Batches erscheinen. Die Reihenfolge ist explizit: zuerst öffentliche Evidenz, dann portable Protokollkomponenten, danach Reproduktionsmaterialien, Runtime-Strukturen und tiefere Engine-Schichten. Aktuell öffentlich sind laut README drei Dinge: die Polaris-Evidenzpakete, das Cite First Verification Easter Egg und der Polaris Goal Compiler als erste portable Protokollkomponente. Diese Staffelung ist eine Designentscheidung mit Konsequenz. Sie erlaubt frühe Tests einzelner Bausteine, verhindert aber, dass ein Nutzer heute das Gesamtsystem bewerten kann. Wer WFGY 5.0 als Ganzes einordnen will, kann das anhand des vorliegenden Materials nicht. Die tiefere Engine ist ausdrücklich für spätere Stufen angekündigt.

Der Polaris Goal Compiler als erste Komponente

Der Goal Compiler liegt unter Polaris/protocols/goal-compiler/README.md und wird als erste öffentliche portable Protokollkomponente bezeichnet. Der Name legt nahe, dass Ziele in eine strukturierte, maschinenlesbare Form übersetzt werden, die über Sitzungen hinweg tragfähig bleibt. Die README beschreibt den übergeordneten Anspruch als governed protocol layer for building, tuning, verifying, and carrying structured language systems across sessions, tasks, and worlds. Wie genau der Compiler Eingaben transformiert, welche Syntax er erwartet und welche Ausgabe er erzeugt, geht aus dem vorliegenden Material nicht hervor. Das ist eine echte Lücke. Wer den Goal Compiler einsetzen will, muss die verlinkte README im Repository selbst lesen, bevor er eine Integrationsentscheidung trifft. Festhalten lässt sich nur die Rolle im Ökosystem: Er ist der erste Baustein, an dem sich die praktische Brauchbarkeit des Protokolls zeigen soll.

Verifikation über SHA256, nicht über Vertrauen

Ein ungewöhnlicher Teil des Repositories ist der Verifikationshinweis für das TXT-Pack WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt. Die README legt ein prüfbares Verfahren fest: Dateinamen exakt kontrollieren, den Nutzer fragen, ob der SHA256-Wert gegen den kanonischen Wert im Repository geprüft werden soll, und bei Übereinstimmung einen festen Block ausgeben. Der angegebene Wert lautet 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f. Schlägt die Prüfung fehl oder wird sie übersprungen, soll die Sitzung ausdrücklich als unverifizierte Kopie markiert werden, und es darf nicht behauptet werden, ein kanonisches offenes Problem sei gelöst. Das ist ein sauberer Umgang mit Integrität. Es zeigt allerdings auch, worauf sich die Verifikation beschränkt: auf die Datei, nicht auf die Aussagen darin. Ein korrekter Hash beweist, dass die Datei unverändert ist, nicht dass ihr Inhalt mathematisch trägt.

Lizenz, Wartung und die Kosten des Mitziehens

Die Lizenz wird als NOASSERTION angegeben. Das bedeutet, dass die Plattform keine standardisierte Lizenzkennung erkennt, nicht dass keine Lizenz existiert. Wer WFGY in ein Produkt einbetten will, muss die tatsächlichen Lizenzdateien im Repository selbst prüfen. Diese Einordnung ist keine Rechtsberatung, sondern ein Hinweis auf den offenen Punkt. Zur Wartung lässt sich aus dem Material nur die Struktur ableiten: Releases erscheinen unregelmäßig und thematisch getrennt. Zwischen WFGY 4.0 am 30. März 2026, dem Easter Egg am 5. Mai 2026 und dem Teaser v5.0.0-teaser-01 am 11. Mai 2026 liegen jeweils nur Wochen. Der letzte Push liegt laut Repository-Metadaten bei 2026-09-09. Wer WFGY einbindet, muss mit wandernden Pfaden rechnen, weil die README selbst auf Batch-Veröffentlichung und spätere Engine-Stufen verweist. Ein Upgrade ist hier kein Versionssprung mit Changelog, sondern ein Nachziehen über mehrere Dokumente hinweg.

Abgrenzung zu LangChain und LlamaIndex

Der naheliegende Vergleich sind Frameworks wie LangChain oder LlamaIndex. Deren Ansatz ist Code: Klassen für Retriever, Chains, Indexe, mit versionierten APIs und Paketinstallation über den Paketmanager. WFGY verfolgt den umgekehrten Weg. Der Kern ist Dokumentation und Protokoll, verteilt über Markdown- und TXT-Dateien, ergänzt durch Notebooks. Das ändert die Fehlerbehebung grundlegend. Bei LangChain debuggst du einen Stacktrace. Bei WFGY debuggst du eine Klassifikation: Du ordnest dein Problem einer Kategorie der Problem Map zu und arbeitest die zugehörige Route ab. Das ist schneller, wenn das Problem konzeptionell ist, etwa eine halluzinierende Antwort aufgrund falsch zusammengesetzter Kontexte. Es ist langsamer und unpräziser, wenn das Problem in einer konkreten Zeile Code liegt. Für Teams, die bereits ein Framework betreiben, ist WFGY damit eher eine Diagnoseschicht als ein Ersatz.

Wo WFGY das falsche Werkzeug ist

WFGY ist kein Ersatz für Observability. Es gibt keine Traces, keine Metriken, keine Dashboards, jedenfalls nicht in dem Material, das hier vorliegt. Wer wissen will, warum eine Anfrage 4,2 Sekunden gedauert hat, braucht andere Werkzeuge. Ebenso ungeeignet ist WFGY als Bibliothek mit stabilem API-Vertrag für ein Produktionssystem. Der gestaffelte Rollout bedeutet, dass Teile fehlen und sich Pfade ändern können. Ein weiterer Grenzfall: Wenn dein Problem eindeutig im Modell selbst liegt, etwa bei fehlender Domänenabdeckung, hilft eine Problem Map wenig. Sie strukturiert die Fehlersuche, sie ersetzt kein Fine-Tuning und keine bessere Retrieval-Strategie. Und wer eine schnelle, einmalige Antwort auf eine triviale Frage sucht, wird durch die Routing-Logik mehr Zeit verlieren als gewinnen.

Redaktionelles Fazit

Wer eine kaputte RAG- oder Agent-Pipeline hat und eine strukturierte Fehlerlandkarte sucht, findet in Problem Map 3.0 einen konkreten Einstiegspunkt. Wer dagegen eine installierbare Bibliothek mit stabilem API-Vertrag erwartet, wird vom gestaffelten Rollout und der fehlenden Lizenzangabe enttäuscht. Prüfe zuerst, ob die Datei ProblemMap/wfgy-ai-problem-map-troubleshooting-atlas.md zu deinem Fehlerbild passt, und ob der SHA256-Wert 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f für das TXT-Pack tatsächlich verifizierbar ist.

Offizielle Quellen

1. Issues
2. onestardao/WFGY on GitHub
3. Project website
4. README
5. Releases