Vom LLM-Wiki zum operativen Knowledge Layer

Nachdem der erste Teil dieser Beitragsreihe das LLM-Wiki als strukturierte, auf dem Schema (Ingest, Query, Lint) basierende Wissensschicht definierte (Hermanns, 2026a) und der zweite Teil dies auf softwaretechnische Artefakte ausweitete (Hermanns, 2026b), vollzieht dieser dritte Artikel einen bewussten Perspektivwechsel. Statt der theoretischen Sinnhaftigkeit widmet er sich vollkommen der praktischen Anwendung und operativen Funktionsweise in einem realen Umfeld.

Als empirische Grundlage dient das bereits vorgestellte Projekt Lutions, welches sich zu einer umfassenden Testumgebung für Agentic AI entwickelt hat. Die Herausforderung in diesem Projekt lag nicht an fehlenden Informationen, sondern an deren starker Fragmentierung über Quellcode, Konfigurationen, Testfälle, Richtlinien und Tickets hinweg. Das Ziel bestand daher nicht im Aufbau einer neuen Dokumentationsablage, sondern in der Schaffung einer überprüfbaren Orientierungsebene für menschliche Entwickler und KI-Agenten gleichermaßen, ohne die primären Wissensquellen zu verdrängen.

Die Untersuchung basiert auf einer klar definierten Datenbasis mit dem Stand vom 25. Juli 2026 (interne Wiki-Seiten, Skripte und Repository-Quellen). Als qualitative Analyse der Umsetzung beansprucht dieser Artikel weder den Charakter einer quantitativen ROI-Studie noch einer universellen Produktdokumentation; die Erkenntnisse sind somit primär projektintern verifizierbar.

Der Text ist in vier Kernbereiche gegliedert: Auf die Darstellung der technischen Grundlagen und Repository-Artefakte folgt eine Analyse des exakten Aufbaus des Knowledge Layers. Anschließend wird der operative Prozess (inklusive Wiki-first Intake, Freshness-Prüfung und Release-Governance) beleuchtet, bevor potenzielle Nutzenaspekte, Limitationen und Transfermöglichkeiten diskutiert werden.

Projektinterne Begriffe

Mehrere Begriffe in diesem Artikel sind keine extern standardisierten Fachbegriffe, sondern Lutions-spezifische Arbeitsbegriffe. Sie werden beim ersten Auftreten fett eingeführt und danach normal verwendet.

• Knowledge Layer bezeichnet in diesem Artikel die konkrete Lutions-Umsetzung des LLM-Wiki-Patterns als code-nahe Orientierungsschicht.
• Wiki-first Requirement Intake ist die Lutions-Arbeitsregel, bei nichttrivialen Anforderungen zuerst den Knowledge Layer als Einstieg zu nutzen.
• Knowledge Operations ist die projektinterne Bezeichnung für den Pflegeprozess, der Ingest, Query, Lint, Freshness-Prüfung und Follow-up-Entscheidungen verbindet.
• Knowledge Impact Check bezeichnet den Prüfschritt im Lutions-Workflow, der klärt, ob eine Änderung Wissen, Hilfetexte, Supportpfade oder Agentenantworten betrifft.
• Knowledge Status ist das Abschlussformat, mit dem im Ticket dokumentiert wird, ob Wissen betroffen war, welche Quellen relevant sind und welche Lücken bleiben.
• Wiki Freshness Radar bezeichnet den Report, der source_of_truth, last_verified und Git-Änderungen miteinander vergleicht.
• Knowledge Refresh Report bündelt Freshness-, Candidate- und Query-Smoke-Signale zu einer Entscheidungsliste.
• Knowledge Refresh Befund bezeichnet den zusammenfassenden Entscheidungsabschnitt, in dem Refresh-Signale im Ticket- oder Release-Kontext bewertet werden.
• SemanticReviewRisk ist ein technisches Feld im Freshness-Report. Es priorisiert heuristisch, ob eine fachliche Prüfung eher high, medium, low oder none ist.

Grundlagen der Umsetzung

In diesem Abschnitt wird dargelegt, welche Leitgedanken aus dem LLM-Wiki-Pattern integriert wurden, welches Basismodell der Implementierung zugrunde liegt und welche Artefakte im Repository entstanden sind.

LLM-Wiki-Pattern: Prinzipien der Quellenführung

Drei fundamentale Leitgedanken wurden aus dem LLM-Wiki-Pattern von Karpathy in das System integriert: Der Erhalt sämtlicher Rohquellen, die Etablierung des Wikis als dauerhafte Syntheseschicht sowie eine tief im System verankerte Governance, die keine bloße nachträgliche Dekoration darstellt.

Diese Struktur bedingt für Lutions eine eindeutige Zuweisung der Artefakte. Als primär führende Elemente agieren hierbei Code, Tests, Konfigurationsdaten, Datenmodelle, Routen, Policies sowie das tatsächliche Laufzeitverhalten. Ergänzenden Kontext steuern wiederum Tickets, Reviews, Prozessdokumente und Supportfälle bei. Das Wiki aggregiert und verdichtet diese verstreuten Ursprünge zu einem code-nahen Knowledge Layer: Er legt transparent dar, wie das Projekt zum aktuellen Zeitpunkt verstanden wird, auf welche Belege sich diese Sichtweise stützt, wo definierte Grenzen verlaufen und an welchen Stellen nachfolgende Überprüfungen anzusetzen haben.

Um die Gefahr einer trügerischen Gewissheit durch verdichtete Synthesen zu minimieren, ist die dauerhafte Rückführbarkeit auf Primärquellen unverzichtbar. Ohne eine derart konsequente Quellenführung ließe der Knowledge Layer lediglich eine leichter zugängliche Form von Unsicherheit entstehen, anstatt belastbare Orientierung zu bieten.

Vier Ebenen des Lutions Knowledge Layers

Die praktische Umsetzung folgt einem einfachen Modell, das im Knowledge-Operations-Workflow dokumentiert ist: Reality, Knowledge Sources, Knowledge Layer und Knowledge Consumers.

• Reality bezeichnet die technische und fachliche Realität des Systems: Code, Tests, Konfiguration, Produktverhalten, Releases und Betriebszustand.
• Knowledge Sources sind die Quellen, aus denen Verständnis entsteht: Routen, Models, Policies, Migrationen, UI-Code, ADRs, Tickets, Review-Kommentare, Supportfälle, Runbooks und vorhandene Dokumentation.
• Knowledge Layer ist die kuratierte Schicht, die diese Quellen in lesbare Zusammenhänge bringt. In Lutions besteht sie aus Wiki-Seiten, Rollenpfaden, Modul- und API-Indizes, Security- und Support-Matrizen, Knowledge Objects, Governance-Seiten und einem chronologischen Wiki-Log.
• Knowledge Consumers sind die späteren Nutzer dieser Schicht: Entwickler, Architekten, Tester, Support, Administratoren, Product Owner und KI-Assistenten. Der Assistant ist dabei ausdrücklich ein Consumer. Er ist nicht die Quelle des Wissens.

Die Skizze macht diese Rollenverteilung sichtbar: Unten liegt die technische Realität mit Code, Tests, Konfiguration und Produktverhalten als führender Wahrheitsebene. Darüber sammeln Knowledge Sources den fachlichen und operativen Kontext. Erst daraus entsteht der Knowledge Layer unter `wiki/**`, der Zusammenhänge verdichtet, aber keine Quellen ersetzt. Die Consumers, also Menschen und KI-Agenten, nutzen diese Schicht als Orientierung und prüfen bei Bedarf gegen die darunterliegenden Primärquellen zurück.

Ein LLM-Wiki ist nicht einfach eine bessere Suche und auch nicht automatisch ein Knowledge Graph. Es ist eine vermittelnde Schicht. Sie soll zeigen, welche Quellen für eine Frage relevant sind, wie sie zusammenhängen und wo die belastbare Prüfung stattfinden muss.

Was im Repository konkret entstanden ist

Die Umsetzung besteht nicht aus einem einzelnen Wiki-Ordner, sondern aus mehreren zusammenwirkenden Artefakten. Die folgende Tabelle zeigt die technische Struktur, auf die sich dieser Artikel stützt.

Wichtig ist die Grenze: Alles unter wiki/** gehört zum eigentlichen LLM-Wiki beziehungsweise Knowledge Layer. Die übrigen Artefakte liegen ebenfalls im Repository, sind aber nicht selbst Wiki-Inhalt. Sie beschreiben, prüfen oder operationalisieren das Wiki: Prozessdokumente unter docs/aidev/**, Reports unter scripts/wiki/** sowie Agentenregeln in AGENTS.md und den Skills.

Artefakt	Aufgabe im Knowledge Layer
wiki/README.md	kanonischer Root-Einstieg mit Scope, Grenzen, Einstiegspfaden und aktuellem Wissensstand
wiki/knowledge-layer-closure-index.md	rollen- und frageorientierter Navigationsindex für Menschen und Assistant
wiki/governance/**	Pflegeprinzipien, Knowledge-Operations-Regeln, Metadatenmodell, Drift-Regeln und OKF-Kompatibilitätsprofil
wiki/knowledge-objects/**	code-nahe Register für wiederkehrende Kernobjekte wie Permissions, API-Token-Scopes, Gruppen- und UI-Sichtbarkeitsregeln
wiki/api/**, wiki/security/**, wiki/support/**, wiki/operations/**	fachliche Views auf Routen, Policies, Supportfragen, Runbooks und Betriebsgrenzen
wiki/log.md	chronologische Evolutionsspur für Ingests, Queries, Lint-Läufe, Governance-Änderungen und Provenienzentscheidungen
docs/aidev/knowledge-operating-system/**	Prozessdokumentation für Wiki-first Intake, Knowledge Impact, Query-Smokes, Freshness, Candidate Detection und Follow-up-Slicing
scripts/wiki/**	reportendes Tooling für Freshness, Knowledge Candidates, Query-Smoke-Vorschläge, Refresh-Reports und Follow-up-Slices
AGENTS.md und .codex/skills/**	Agentenregeln, Pflichtpfade, Completion-Formate und spezialisierte Workflows

Diese Artefakte haben unterschiedliche Rollen. wiki/** ist die lesbare Wissensschicht. docs/aidev/knowledge-operating-system/** beschreibt, wie diese Schicht gepflegt und geprüft wird. scripts/wiki/** erzeugt Hinweise und Entscheidungsvorlagen. AGENTS.md und Skills sorgen dafür, dass der Agent diese Hinweise nicht zufällig nutzt, sondern im normalen Entwicklungsablauf berücksichtigen muss.

Aufbau des Knowledge Layers

In diesem Abschnitt wird der präzise innere Aufbau des Wikis dargelegt: Einstiegspunkte, Navigation sowie maschinenlesbare Metadaten.

Navigation über Root-Einstieg und Closure Index

Der primäre Zugang zur Wissensbasis von Lutions wird über die Datei wiki/README.md bereitgestellt. Dieses Dokument umreißt den genauen Umfang des Knowledge Layers, grenzt nicht relevante Themen ab und zeigt transparent auf, welche Abschnitte bereits verlässlich ausgearbeitet oder noch lückenhaft sind.

Als strukturierter Wegweiser fungiert parallel dazu der wiki/knowledge-layer-closure-index.md, welcher sich an konkreten Fragen und Benutzerrollen orientiert. Der Name Closure Index ist projektintern gemeint: Er bezeichnet keine zusätzliche Wissensquelle, sondern einen Index, der zeigen soll, welche Wiki-Seiten eine Arbeitsfrage ausreichend schließen können und wo Grenzen oder Lücken bleiben. Diese Übersicht vermittelt kein zusätzliches Fachwissen, sondern ordnet die vorhandenen Wissensbausteine. Dadurch können sowohl menschliche Anwender als auch KI-Assistenten präzise nachvollziehen, welche Dokumente für welche Rolle Priorität besitzen, welche Primärquellen für bestimmte Themenkomplexe maßgeblich sind und wo feste Grenzen verlaufen.

Diese funktionale Aufteilung entspringt einer frühen strategischen Entscheidung in der Architektur des Knowledge Layers: Die Basis wird durch den Root-Einstieg erklärt, während die Navigation operativ durch den Closure Index gesteuert wird. Eine redundante Übersichtsseite wie wiki/index.md wird absichtlich nicht gepflegt, da sie keinen eigenständigen Nutzen stiftet. So wird gewährleistet, dass die Orientierung im System konsequent auf reale Praxisfragen ausgerichtet bleibt und nicht in einer bloßen Anhäufung von Verzeichnissen resultiert.

Frontmatter als technisches Metadatenmodell

Damit der Knowledge Layer maschinenlesbar prüfbar bleibt, tragen Wiki-Seiten ein einfaches Frontmatter. Die wichtigsten Felder sind nicht dekorativ, sondern Teil der technischen Umsetzung.

status beschreibt, ob eine Seite als aktueller Stand, Review-Kandidat, veraltet, historisch oder ungeklärt gelesen werden soll. source_of_truth nennt die führenden Quellen, gegen die die fachliche Aussage geprüft wurde: Code, Routen, Policies, Tests, Konfiguration, Migrationen oder andere Primärquellen. doc_sources nennt ergänzende Dokumentationsquellen. last_verified markiert das Datum der letzten fachlichen Quellenprüfung. provenance kann festhalten, aus welchem Ticket oder Arbeitskontext eine Seite entstanden ist, welche letzte relevante Änderung sie berührt hat und worauf sich die letzte Prüfung stützte. staleness_risk bewertet grob, wie schnell eine Seite voraussichtlich driftet.

Ein typischer, verkürzter Frontmatter-Ausschnitt sieht deshalb etwa so aus:

status: current
last_verified: 2026-07-21
source_of_truth:
  - backend/routes/v1
  - backend/app/Policies
doc_sources:
  - AGENTS.md
provenance:
  created_from: AIDEV-157
  last_review: Knowledge Refresh
staleness_risk: medium

Der Ausschnitt zeigt die praktische Lesart: Ein Agent erkennt, ob die Seite als aktuell gilt, welche Primärquellen führend sind, wann sie zuletzt fachlich geprüft wurden und ob bei Änderungen eher mit Drift zu rechnen ist. Die Felder verhindern nicht, dass Wissen mit der Zeit veraltet. Sie machen aber prüfbar, woran eine spätere Kontrolle ansetzen muss: Ohne source_of_truth gäbe es keinen klaren Quellenbezug, ohne last_verified keinen Prüfstand, ohne Provenienz keine nachvollziehbare Entstehung.

Das Open Knowledge Format wird in Lutions nur ergänzend berücksichtigt. Neue oder fachlich berührte Wiki-Seiten sollen OKF-nahe Felder wie type, title und description prüfen. Führend bleiben aber die Lutions-Felder, weil sie direkt auf Quellenführung, Drift und Prozessintegration zielen (Lutions, 2026c; McVeety und Hormati, 2026; GoogleCloudPlatform, 2026).

Operativer Arbeitsprozess

Dieser Abschnitt veranschaulicht, wie der Knowledge Layer im täglichen Entwicklungsbetrieb eingesetzt und kontinuierlich aktuell gehalten wird. Er stellt zuerst die Einstiegsregel und das Prozessmodell vor. Danach folgt die konkrete Umsetzung entlang von Karpathys drei Prozessschritten: Ingest, Query und Lint. Abschließend werden die übergreifenden Agentenregeln beschrieben, die diese Schritte im Arbeitsalltag verbindlich machen.

Wiki-first Requirement Intake als Arbeitsregel

Die wichtigste operative Regel heißt in Lutions Wiki-first Requirement Intake. Bei nichttrivialen fachlichen, UI-, API-, Security-, Operations-, Knowledge-, Help- oder prozessnahen Anforderungen startet der zuständige Developer-Agent, also der Agent für die technische Bearbeitung einer Anforderung, zuerst im Knowledge Layer, bevor er breit im Repository sucht.

Der Standardpfad ist bewusst einfach:

1. wiki/README.md
2. wiki/knowledge-layer-closure-index.md
3. passende Rollen-, Fragefamilien-, Modul-, API-, Security-, Support- oder Governance-Seiten
4. gezielte Prüfung der dort genannten source_of_truth-Pfade gegen Code, Tests, Routen, Policies, Migrationen oder Konfiguration

Demnach fungiert das Wiki nicht als Entscheidungsinstanz, sondern bietet Orientierung. Es hilft, wahrscheinliche Produktbereiche, bekannte Grenzen, Supportfragen und führende Quellen begründet zu finden. Danach wird gegen die primären Quellen geprüft.

Damit wird der Knowledge Layer Teil der Umsetzung, ohne zum Gate zu werden. Für triviale oder eindeutig mechanische Änderungen kann der Intake entfallen; sonst würde aus einem nützlichen Pattern ein bürokratischer Reflex.

Knowledge Operations als Prozessmodell

Diesen operativen Pflegeprozess nennen wir in Lutions Knowledge Operations. Der Begriff bezeichnet hier die Übersetzung von Karpathys Dreiklang aus Ingest, Query und Lint in den Entwicklungsprozess (Karpathy, 2026; Lutions, 2026c):

• Ingest fragt: Welche neue oder geänderte Quelle muss in Wissen überführt werden? Das kann eine Route, eine Policy, ein Ticket, ein Supportfall, ein Review-Fund oder eine Architekturentscheidung sein. Der Ingest endet nicht zwangsläufig mit einer neuen Seite; er kann auch ein bestehendes Knowledge Object bestätigen, eine View aktualisieren oder begründet feststellen, dass kein Update nötig ist.
• Query fragt: Welche reale Frage wurde gestellt, und was lernen wir aus der Antwort? Support- oder Entwicklerfragen zeigen, ob ein Register, eine Matrix oder ein Testindex in einer konkreten Situation trägt.
• Lint fragt: Ist der Knowledge Layer gesund, konsistent und aktuell? Dabei geht es um veraltete Aussagen, fehlende Quellen, widersprüchliche Views und Drift zwischen Code und Wiki.

Der entscheidende Perspektivwechsel lautet: Wissensarbeit beginnt nicht mit der Frage „Welche Seite schreiben wir?“. Sie beginnt mit der Frage „Welche Quelle, Frage oder Prüfung verändert unser Wissensmodell?“ Eine neue Seite ist nur eine mögliche Folge.

Die späteren Lutions-Abschnitte lassen sich deshalb als konkrete Ausprägungen dieses Dreiklangs lesen:

Karpathy-Schritt	Lutions-Umsetzung im Artikel	Zweck
Ingest	Ingest: Vom Ticket zur Knowledge-Entscheidung	Neue oder geänderte Quellen werden bewertet und bei Bedarf in den Knowledge Layer überführt.
Query	Query: Reale Arbeitsfragen als Smoke-Test	Reale Arbeitsfragen prüfen, ob das Wiki die betroffene Situation noch sinnvoll erklärt.
Lint	Lint: Reportende Prüfung statt automatischer Pflege, darunter Freshness und Release-Governance	Drift, veraltete Aussagen, unklare Quellen und Review-Kandidaten werden sichtbar gemacht.

Die Zuordnung ist nicht vollkommen trennscharf, weil ein Ticket oft alle drei Schritte enthält. Sie hilft aber, die Lutions-Begriffe auf das ursprüngliche Pattern zurückzuführen.

Die Skizze zeigt den operativen Ablauf als Entscheidungs- und Prüfstruktur. `Ingest` beginnt mit dem Wiki-first Einstieg, der Suche nach relevanten Primärquellen und der Prüfung von `source_of_truth`. `Query` übersetzt die Aufgabe in eine konkrete Arbeitsfrage: Kann der Knowledge Layer die Situation rückführbar beantworten, oder wird eine Wissenslücke sichtbar? `Lint` prüft anschließend Freshness, Drift und Widersprüche über Signale wie `last_verified`, `source_of_truth` und den Knowledge Refresh Report.

Die Rückkopplungen sind gezielte Nachprüfungen, kein automatischer Neustart des Prozesses. Ein Wiki-Update oder Follow-up entsteht erst, wenn die fachliche Prüfung gegen Primärquellen zeigt, dass Wissen tatsächlich ergänzt, korrigiert oder neu entschieden werden muss.

Ingest: Vom Ticket zur Knowledge-Entscheidung

Damit Knowledge Operations im Alltag funktionieren, braucht es einen kleinen, wiederholbaren Entscheidungsblock. Lutions nutzt dafür den Knowledge Impact Check, der als Prüfschritt im Knowledge-Operations-Workflow beschrieben und über den Entwicklungsprozess verankert ist.

Der tatsächliche Ablauf verbindet alle drei Karpathy-Schritte: Intake und Impact Check bereiten Ingest vor, Query Smoke prüft die spätere Nutzbarkeit, und Lint beziehungsweise Drift Check schließt die Konsistenzprüfung an. Ein nichttriviales Ticket läuft aus Knowledge-Sicht durch mehrere Schritte:

1. Wiki-first Requirement Intake: Der Agent liest zuerst Root-Einstieg, Closure Index und passende Rollen-, Modul-, API-, Security-, Support- oder Governance-Seiten.
2. Product Framing: Die Änderung wird auf Nutzerproblem, betroffene Rolle, bestehende Unsicherheit und sinnvolle Abgrenzung geprüft.
3. Reality Change Check: Der Agent benennt, welche technische oder fachliche Realität sich wirklich ändert: Route, Policy, Datenmodell, UI-Verhalten, Fehlermeldung, Betriebsannahme, Supportablauf oder User Journey.
4. Knowledge Impact Check: Es wird geprüft, welche Knowledge Objects, Views, Playbooks, Matrizen, Assistant-Fragen oder UI-Hinweise betroffen sind.
5. Ingest: Wenn Wissen betroffen ist, wird die neue oder geänderte Quelle in den Knowledge Layer überführt. Das kann eine Seite aktualisieren, eine Relationship ergänzen, eine offene Frage markieren oder ein Follow-up erzeugen.
6. Consumer Mapping: Der Agent entscheidet, wo dieses Wissen später gebraucht wird: Wiki, Assistant-Antwort, UI-Hinweis, Fehlermeldung, Support-Playbook, Admin-Hilfe, Onboarding oder Entwicklerindex.
7. Query Smoke: Mindestens eine reale Frage prüft, ob der Knowledge Layer die betroffene Situation sinnvoll beantworten kann.
8. Lint und Drift Check: Vor Abschluss werden widersprüchliche Aussagen, fragwürdige Frontmatter, historische Quellen, redundante Seiten und Drift-Signale geprüft.
9. Ticketabschluss mit Knowledge Status: Das Ticket dokumentiert, ob Wissen betroffen war, welche Quellen und Consumer relevant sind, welcher Query Smoke geprüft wurde und welche Lücken bleiben.

Diese Reihenfolge ist kein neues Bürokratieformular. Sie beschreibt, was ein Agent ohnehin klären muss, wenn eine Änderung mehr als eine lokale Codezeile betrifft. Der Unterschied ist, dass die Prüfung sichtbar und wiederholbar wird.

Im Zentrum steht der Knowledge Impact Check, welcher die Evaluierung auf wesentliche Fragestellungen komprimiert: Was ändert sich an der Systemrealität? Welche Quellen belegen diese Änderung? Welche Knowledge Objects, Views oder Indizes sind betroffen? Welche Consumer nutzen dieses Wissen später? Welche reale Frage muss nach der Änderung beantwortbar sein?

Daraus resultiert kein automatisierter Schreibauftrag, sondern eine Auswahl aus vier Pfaden: kein Knowledge Update nötig, Knowledge Review nötig, Knowledge Update im Scope oder Follow-up-Ticket nötig. Diese Form ist absichtlich proportional: Kleine Änderungen brauchen eine kurze Notiz, mittlere Änderungen betroffene Views und eine Query, große Änderungen expliziten Ingest, Consumer Mapping, Query Smoke, Lint und Follow-ups.

Das war eine wichtige Umsetzungserkenntnis: Ein LLM-Wiki kann nur dauerhaft funktionieren, wenn Pflege in normale Arbeit integriert wird. Wenn sie als späteres Dokumentationsprojekt danebensteht, driftet sie.

Query: Reale Arbeitsfragen als Smoke-Test

Query bedeutet in Lutions nicht, dass ein Agent beliebig im Wiki sucht und eine Antwort formuliert. Gemeint ist eine konkrete Arbeitsfrage, die prüft, ob der Knowledge Layer für eine reale Situation tragfähig ist. Deshalb taucht Query im Ticketablauf als Query Smoke auf: Der Agent hält mindestens eine Frage fest, die nach der Änderung beantwortbar sein muss.

Ein Query Smoke kann zum Beispiel fragen, welche Permission für eine bestimmte Aktion gilt, welche API-Route für einen Client relevant ist oder welches Support-Playbook bei einer Fehlermeldung heranzuziehen ist. Die Antwort muss nicht nur plausibel klingen, sondern auf die im Wiki genannten Quellen zurückgeführt werden können. Wenn die Frage nicht beantwortbar ist, zeigt das keine Chat-Schwäche, sondern eine Wissenslücke im Knowledge Layer.

Für wiederkehrende Prüfungen unterstützt scripts/wiki/query-smoke-suggestions.ps1 diesen Schritt. Das Skript erzeugt keine Wahrheit, sondern schlägt Prüffragen aus Candidate-Signalen vor. Der Agent entscheidet anschließend, welche Frage fachlich sinnvoll ist und dokumentiert das Ergebnis im Ticket, Review oder Release-Kontext.

Lint: Reportende Prüfung statt automatischer Pflege

Die technische Umsetzung folgt einem bewussten Muster: Automatisierung soll Hinweise erzeugen, aber keine fachlichen Entscheidungen treffen. Deshalb gibt es mehrere kleine Reports, die zusammen den Pflegeprozess unterstützen.

Ausgeführt werden diese Tools nicht automatisch im Hintergrund. Sie werden bewusst angestoßen, wenn ein Ticket, ein breiter Diff, ein Knowledge-Review oder ein Release-Schnitt Anlass dazu gibt. Typischerweise nutzt sie der Developer-Agent vor dem Abschluss; der Test-Agent kann Query-Smokes oder Review-Hinweise zusätzlich prüfen; beim Release-Schnitt liegt die Verantwortung beim Release-Agent.

Tool	Aufgabe
scripts/wiki/knowledge-candidates.ps1	sucht mögliche betroffene Wiki-Seiten über source_of_truth, doc_sources und Pfadheuristiken
scripts/wiki/query-smoke-suggestions.ps1	leitet aus Candidate-Signalen konkrete Prüffragen ab
scripts/wiki/freshness-report.ps1	prüft, ob referenzierte Quellen neuer sind als last_verified oder aktuell geändert wurden
scripts/wiki/knowledge-followup-slices.ps1	schlägt sinnvolle Zuschnitte für Follow-ups oder Parent-/Child-Tickets vor
scripts/wiki/knowledge-refresh-report.ps1	bündelt Freshness, Candidates und Query-Smoke-Vorschläge in eine Entscheidungsliste

Standardmäßig schreiben die Skripte Markdown oder JSON auf die Konsole. Der Agent übernimmt relevante Befunde in den Ticketabschluss, in einen Review-Kommentar oder in den Abschnitt Knowledge Refresh Befund des Release-Tickets. Nur dauerhafte Wissensänderungen führen zu einem Wiki-Update oder Follow-up; temporäre Reportläufe werden nicht als eigene Wiki-Artefakte abgelegt.

Freshness und Knowledge Refresh

Ein Knowledge Layer altert nicht gleichmäßig. Manche Seiten bleiben lange gültig. Andere werden durch kleine Codeänderungen plötzlich riskant. Wieder andere wirken technisch veraltet, weil ein breiter Commit viele Dateien berührt hat, obwohl die fachliche Aussage weiterhin stimmt.

Deshalb wurde in Lutions ein Wiki Freshness Radar eingeführt. Der Report liest Wiki-Frontmatter, insbesondere source_of_truth und last_verified, und vergleicht referenzierte Quellen gegen Git-Änderungen. review-needed bedeutet dabei nicht, dass eine Seite falsch ist. Es bedeutet nur, dass eine referenzierte Quelle neuer ist als der dokumentierte Prüfstand oder aktuell im Working Tree geändert wurde.

Dieser Freshness-Prozess ist keine 1:1-Übernahme aus Karpathys LLM-Wiki-Pattern oder dem Open Knowledge Format. Er ist eine code-nahe Operationalisierung derselben Grundidee. Bei Karpathy gehört die Prüfung veralteter Aussagen, Widersprüche und fehlender Verweise zum Lint-Schritt. OKF betont ebenfalls Markdown, Frontmatter, Quellen, Provenienz, Status und Freshness-Signale als Grundlage für agenten- und menschenlesbares Wissen (Karpathy, 2026; McVeety und Hormati, 2026; GoogleCloudPlatform, 2026). Lutions übersetzt diese Idee in einen Git-basierten Prüfprozess: Nicht nur die Wiki-Seite zählt, sondern auch die Frage, ob ihre führenden Quellen seit der letzten fachlichen Prüfung geändert wurden.

Seit der Erweiterung um SemanticReviewRisk trennt der Report technische Freshness von semantischer Review-Priorität. SemanticReviewRisk ist dabei kein eigener Prozess und kein Wahrheitsflag, sondern ein Feld in der Reportausgabe. Es hilft, Review-Kandidaten zu sortieren: Eine direkte Änderung an API, Datenmodell, Permission, Security, Prozess oder Release-Operations wird eher als high oder medium eingestuft. Ein breiter formaler Commit, der viele Wiki-Dateien oder Baseline-Dateien technisch neuer macht, kann dagegen als technische Drift niedriger priorisiert werden. So verhindert der Prozess, dass ein pauschales Aktualisieren von last_verified nur Frische simuliert.

Der Knowledge Refresh Report bündelt mehrere Hinweise in einer Entscheidungsliste. Er zeigt erstens, welche Wiki-Seiten durch den aktuellen Git-Diff wahrscheinlich betroffen sein könnten, weil ihre source_of_truth– oder doc_sources-Pfade berührt wurden. Das sind die sogenannten Knowledge Candidates. Zweitens schlägt er passende Query-Smokes vor: konkrete Prüffragen, mit denen der Agent testet, ob das Wiki die betroffene Situation noch sinnvoll erklärt. Der Report setzt dabei kein last_verified, erzeugt keine Tickets und verändert keine Seiten.

Ein einfaches Beispiel aus dem laufenden Prozess macht die Unterscheidung greifbar: Wird eine Policy geändert, die in einer Permission-Matrix als source_of_truth referenziert ist, meldet der Report review-needed; SemanticReviewRisk kann high sein, weil eine fachliche Aussage zu Berechtigungen betroffen sein könnte. Der Agent prüft dann die Policy, die betroffene Wiki-Seite und mindestens eine passende Query-Smoke-Frage. Ergibt die Prüfung, dass die Matrix angepasst werden muss, lautet die Entscheidung update-in-scope. Ergibt sie, dass die Aussage weiter korrekt ist, lautet sie reviewed-current.

Anders sieht es bei einem breiten Repository- oder Knowledge-Layer-Commit aus, der viele Dateien technisch neuer macht, ohne eine konkrete fachliche Regel zu ändern. Auch dann kann eine Seite formal review-needed erscheinen. SemanticReviewRisk hilft aber, solche Fälle als technische Drift niedriger zu priorisieren.

Die Entscheidung bleibt fachlich. Pro relevanter Seite soll eine der folgenden Entscheidungen dokumentiert werden:

• not affected
• reviewed-current
• update-in-scope
• follow-up

Eine vereinfachte Ausgabe kann zum Beispiel so aussehen:

Wiki-Seite	Signal	Hinweis	Entscheidung
Permission Matrix	high	Policy- oder Middleware-Quelle geändert	update-in-scope
Support-Playbook 403	medium	passende Query-Smoke-Frage vorgeschlagen	reviewed-current
Operations-Runbook	low	breite technische Datumsdrift	not affected

Im Ticket- oder Release-Kontext wird daraus kein vollständiger Reportanhang, sondern ein kurzer Befund, der die Entscheidung nachvollziehbar macht:

Knowledge Refresh Befund
Basis: working tree gegen letzten geprüften Stand
Wiki-Seite: wiki/security/permission-matrix.md
Signal: review-needed
Grund: referenzierte Policy-Quelle wurde geändert
Entscheidung: update-in-scope
Nachzug: Permission Matrix nach fachlicher Quellenprüfung aktualisieren

Damit bleibt der operative Nachweis dort, wo die Arbeit abgeschlossen oder freigegeben wird. Das Wiki selbst wird nur geändert, wenn sich aus dem Befund eine dauerhafte Wissensänderung oder ein dokumentierter Review-Stand ergibt.

Release-Governance mit Knowledge Refresh

Besonders wichtig wurde der Knowledge Refresh beim Release-Schnitt. Im aktuellen Lutions-Release-Prozess ist verbindlich, dass zu Beginn eines Release-Schnitts ein Knowledge-Refresh-Report ausgeführt wird, bevorzugt releasebezogen von einem letzten Release-Tag bis HEAD (Lutions, 2026d).

Das Release-Ticket muss einen eigenen Abschnitt Knowledge Refresh Befund enthalten. Dort werden Befehl und Basis, Kurzbefund, release-relevante Entscheidungen, Wiki-Nachzug oder Follow-ups und die Go/No-Go-Auswirkung dokumentiert.

Diese Release-Verankerung macht den Knowledge Layer zu einem Teil der Produktverantwortung. Wenn ein Release mehrere Tickets bündelt, wird nicht nur Code geprüft; auch das erklärende Wissen über relevante Änderungen darf nicht stillschweigend veralten.

Übergreifende Agentenregeln für Wiki-first Arbeit

Dieser Abschnitt ist kein vierter Prozessschritt neben Ingest, Query und Lint. Er beschreibt die Regeln, die dafür sorgen, dass Agenten diese drei Schritte im normalen Arbeitsablauf tatsächlich berücksichtigen.

Im ursprünglichen LLM-Wiki-Pattern definiert ein Schema, wie das LLM mit Quellen, Seiten, Konflikten und offenen Fragen umgehen soll (Karpathy, 2026). In Lutions verteilt sich diese Regelung auf operative Prozessquellen: AGENTS.md, den guideline-enforcer-Skill, Governance-Seiten im Wiki und spezialisierte Skills für Release- und Autorenarbeit.

Die Rollen lassen sich allgemein unterscheiden: Ein Developer-Agent setzt Anforderungen um und dokumentiert Knowledge- und Help-Impact. Ein Test-Agent prüft Antworten, Query-Smokes oder Verifikationspfade aus einer unabhängigen Testperspektive. Ein Release-Agent bündelt mehrere Änderungen für einen Release-Schnitt und muss dabei Knowledge Refresh, Release-Gates, Release Notes und Artefakte zusammenführen. Die konkreten Lutions-Skills operationalisieren diese Rollen, aber die Rollenlogik ist allgemeiner als ein einzelner Skillname.

Für den Developer-Agent bedeutet das: Er liest bei nichttrivialen Anforderungen zuerst den Knowledge Layer, prüft danach Code und Tests, dokumentiert Knowledge- und Help-Impact und hält fest, ob ein Auditor, Test-Agent oder Spezialskill nötig ist. Der Knowledge Layer ist also nicht nur Inhalt. Er ist auch Arbeitsanweisung.

Einordnung und Übertragbarkeit

In diesem Abschnitt erfolgt eine klare Differenzierung zwischen der technischen Realisierung, nachvollziehbaren Nutzenvermutungen sowie der bislang unbestätigten Effektivität.

Nutzenannahmen aus der Umsetzung

Ob das LLM-Wiki Agenten schneller, günstiger oder fehlerärmer arbeiten lässt, ist nicht Gegenstand dieses Umsetzungsartikels und wird später separat betrachtet. Dieser Artikel beschreibt die technische und prozessuale Umsetzung in Lutions. Aus dieser Umsetzung ergeben sich aber vier prüfbare Nutzenannahmen, die in einem nächsten Schritt untersucht werden können:

1. Orientierung: Root-Einstieg, Closure Index, Rollenpfade und Fragefamilien sollen Agenten begründeter zu relevanten Primärquellen führen.
2. Quellenklarheit: source_of_truth soll sichtbar machen, welche Aussagen auf Code, Tests, Routen, Policies, Konfiguration oder Prozessdokumentation zurückgehen.
3. Drift-Erkennung: Änderungen an referenzierten Quellen sollen früher als Prüfbedarf sichtbar werden.
4. Wiederverwendbare Fragen: Query-Smokes sollen zeigen, ob der Knowledge Layer konkrete Arbeitsfragen beantworten kann.

Diese Annahmen sind bewusst noch kein Wirkungsnachweis. Erste Gegenproben wurden zwar bereits vorbereitet und in ersten Durchläufen erprobt, aber ihre Auswertung gehört in einen eigenen Erkenntnisartikel. Dort kann sauber getrennt werden, ob das Wiki nur anders wirkt, ob es tatsächlich bessere Prüfpfade erzeugt und welche zusätzlichen Tests oder instrumentierten Traces nötig sind.

Grenzen des Knowledge Layers

Die Umsetzung zeigt auch klare Grenzen.

1. Der Knowledge Layer ersetzt keine primären Quellen. Bei Widersprüchen führen Code, Tests, Konfiguration, Policies, Migrationen und reales Produktverhalten. Das Wiki ist Karte, nicht Gelände.
2. Freshness ist keine Wahrheit. Ein neuerer Commit kann eine Seite semantisch unberührt lassen. Eine unveränderte Quelle kann trotzdem fachlich unvollständig sein. Der Freshness Radar ist daher ein Hinweisgeber, kein Beweis.
3. Automatisierung ist bewusst begrenzt. Die Reports erzeugen Entscheidungsvorlagen, aber keine automatischen Wiki-Updates. Das ist kein Mangel, sondern eine Schutzmaßnahme gegen Synthesis Drift: Gemeint ist das Risiko, dass automatisch erzeugte oder fortgeschriebene Zusammenfassungen plausibel wirken, sich aber fachlich unbemerkt von den Primärquellen entfernen.
4. Vollständigkeit bleibt unrealistisch. Ein lebendes Softwareprojekt ändert sich zu schnell, um jeden Zusammenhang sofort perfekt zu kuratieren. Der Knowledge Layer muss daher priorisieren: sensible Bereiche, wiederkehrende Fragen, Support- und Operationswissen, Security- und Permission-Grenzen, Release-relevante Änderungen.
5. Datenschutz und Berechtigungen bleiben kritisch. Als fachliche Risiko-Einordnung folgt aus dem Lutions-Governance-Modell: Ein Wiki, das Code, Tickets, Supportfälle und Betriebswissen zusammenführt, kann Zusammenhänge sichtbar machen, die in Ursprungssystemen getrennt waren. Deshalb braucht ein produktiver Ausbau klare Regeln, welche Informationen aufgenommen, zusammengeführt und an welche Consumer weitergegeben werden dürfen.

Übertragbare Prinzipien für andere Projekte

Die konkrete Lutions-Umsetzung mit genau diesen Wiki-Pfaden, Ticketregeln, Agentenrollen und PowerShell-Reports lässt sich nicht unverändert auf jedes andere Projekt übertragen. Übertragbar sind eher die darunterliegenden Prinzipien.

1. Man sollte mit einem klaren Root-Einstieg beginnen. Ein LLM-Wiki braucht eine Seite, die erklärt, was der Knowledge Layer ist, welche Bereiche belastbar sind und welche Grenzen gelten.
2. Es braucht rollen- oder frageorientierte Navigation. Ein Wiki, das nur nach interner Ordnerlogik sortiert ist, hilft Agenten und Menschen weniger als ein Wiki, das reale Fragen priorisiert.
3. source_of_truth und last_verified sollten früh eingeführt werden. Nicht als Perfektionsanspruch, sondern als Mindeststruktur für spätere Freshness-Prüfung.
4. Knowledge Maintenance sollte in den Entwicklungsprozess eingebettet werden. Wenn Wissen betroffen ist, gehört ein kurzer Knowledge Status in Ticket, Abschluss oder Review. Wenn Wissen nicht betroffen ist, reicht eine knappe Begründung.
5. Automatisierung sollte reportend beginnen. Reports, Kandidatenlisten und Query-Smoke-Vorschläge sind nützlich. Automatische Umschreibungen sind riskant, solange keine starke semantische Prüfung und menschliche Freigabe existieren.
6. Erfolg sollte nicht an Seitenzahl gemessen werden, sondern an Quellenklarheit, nachvollziehbaren Agentenwegen, sichtbarer Drift und besser dokumentierten Folgeentscheidungen.

Ausblick

Der nächste Schritt liegt nicht in „mehr Wiki“. Er liegt in der Prüfung, ob diese technische Umsetzung in konkreten Agentenläufen tatsächlich sichtbar andere Arbeitswege erzeugt.

Der naheliegende Test ist ein Zwei-Pfade-Vorgehen. Dieselbe ticketförmige Aufgabe wird einmal repo-first und einmal wiki-first bearbeitet. Danach werden Quellenweg, Suchrauschen, erste belastbare Primärquelle, frühe Taxonomie, erkannte Grenzen, Verifikationspfad und offene Wissenslücken nebeneinandergelegt. Erst diese Gegenüberstellung kann zeigen, ob die Mechanismen im Arbeitsfluss tatsächlich Orientierung, Quellenführung oder Grenzmarkierung verbessern.

Für belastbarere Aussagen braucht es anschließend bessere Mess- und Beobachtungsdaten: instrumentierte Traces der Agentenarbeit, gesicherte Such- und Lesereihenfolgen, dokumentierte Fehlpfade, unabhängige Review-Auswertung und wiederholte Testfälle aus unterschiedlichen Domänen. Erst dann wären vorsichtige Aussagen über Wiederholbarkeit, Fehlervermeidung, Rework oder Aufwand möglich.

Technisch bleibt zusätzlich ein Ausbau in Richtung besserer Verbindungen möglich: Knowledge Objects, Relationships, route-to-policy-to-test-Ketten, Modulverantwortungen, Supportfragen und Release-Auswirkungen könnten stärker maschinenlesbar werden. Auch OKF-kompatiblere Metadaten oder exportierbare Knowledge-Views können sinnvoll werden, wenn Austauschbarkeit zwischen Tools wichtiger wird (McVeety und Hormati, 2026; GoogleCloudPlatform, 2026; Hermanns, 2026a).

Fazit

Die Lutions-Umsetzung führt die Grundidee der ersten beiden Artikel in eine konkrete technische Form. Ein LLM-Wiki wird in der Softwareentwicklung nicht dadurch belastbar, dass ein LLM Markdown schreibt. Es braucht eine überprüfbare Einbettung in den Entwicklungsprozess.

Der code-nahe Knowledge Layer ist dabei weder Sourcecode noch Handbuch noch Chatverlauf. Er ist als persistente Orientierungsschicht zwischen technischer Realität, verstreuten Wissensquellen und späteren Fragen angelegt. Quellenführung, Frontmatter, Freshness-Signale, Query-Smokes, Follow-up-Entscheidungen, Release-Governance und Agentenregeln bilden die technische Grundlage, auf der Wissen nicht nur erzeugt, sondern weiter prüfbar gehalten werden kann.

Damit ist die technische Grundlage beschrieben. Ob diese Grundlage in konkreten Agentenläufen zu nachvollziehbar anderen oder besseren Wegen führt, ist noch nicht Ergebnis dieses Artikels. Das gehört in die nächste Betrachtung: kontrollierte Gegenproben, saubere Beobachtungskriterien und eine ehrliche Trennung zwischen plausibler Orientierungshypothese und tatsächlich belegter Wirkung.

Quellenverzeichnis

Primärartikel dieser Reihe

• Hermanns, Christoph (2026a). Das LLM-Wiki: Persistentes Wissen für Menschen und KI-Agenten. docs/aidev/articles/LLM-Wiki/llm-wiki-grundlagen_ta.md
• Hermanns, Christoph (2026b). Vom LLM-Wiki zum code-nahen Knowledge Layer. docs/aidev/articles/LLM-Wiki/llm-wiki-software-development_tba.md
• Hermanns, Christoph (2026d). Agentic AI: Wie ich zu meiner idealen Entwicklungsumgebung kam. docs/aidev/articles/Agentic-AI/lutions-projekt-einstieg_tba.md

Öffentlich prüfbare externe Bezugspunkte

• Karpathy, Andrej (2026). LLM Wiki. GitHub Gist. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• McVeety, Sam; Hormati, Amir (2026). Introducing the Open Knowledge Format. Google Cloud Blog, 12. Juni 2026. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
• GoogleCloudPlatform (2026). Open Knowledge Format (OKF) specification and reference implementation. GitHub Repository. https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

Interne Nachweisbasis der Lutions-Umsetzung

Die folgenden Quellen liegen im Lutions-Repository. Sie sind für externe Leser nicht notwendigerweise zugänglich, dokumentieren aber die interne Belegbasis dieses Umsetzungsberichts.

• Lutions (2026b). Knowledge-Layer-Einstieg und Closure Index. wiki/README.md; wiki/knowledge-layer-closure-index.md
• Lutions (2026c). Knowledge Operations, Governance und Refresh-Tooling. Wiki-Governance-Seiten, Knowledge-Operations-Dokumente und Skripte unter wiki/governance/**, docs/aidev/knowledge-operating-system/** und scripts/wiki/**
• Lutions (2026d). Agenten-, Entwicklungs- und Release-Prozess. AGENTS.md, relevante Skills und Release-Prozessdokumente