# WikiKit: Wissen mit Herkunft URL: https://www.mikebild.dev/de/blog/wikikit-wissen-mit-herkunft/ Im Protokoll steht ein unscheinbarer Satz: „The retry budget is shared across all attempts.“ Drei Wochen später fragt ein Agent, ob jeder neue Versuch wieder das volle Zeitbudget erhält. Eine Volltextsuche kann das Protokoll finden. Ein Sprachmodell kann den Absatz zusammenfassen. Beides beantwortet noch nicht zuverlässig, ob der Satz weiterhin gilt, wer ihn geprüft hat und ob eine spätere Entscheidung ihn ersetzt. Genau dort beginnt WikiKit. Das System archiviert die ursprüngliche Quelle, leitet daraus kleine Aussagen mit wörtlichen Belegen ab und legt jede Wissensänderung zuerst als Vorschlag ab. Erst eine menschliche Freigabe macht daraus sichtbares Wissen. Wer die Aussage später liest, kann den Weg zurückgehen: von der aktuellen Konzept-Seite über den Claim und sein Zitat bis zum unveränderten Protokoll. Dieser Auftakt verfolgt eine einzelne Aussage durch diesen Weg. Die folgenden Artikel der Serie zerlegen Quellen, Claims, Review, Widersprüche, Spaces, MCP, Entscheidungen, Lint, Export und Betrieb jeweils genauer. ## Vier Dinge, die leicht verwechselt werden Eine Quelle ist das eingereichte Rohmaterial: Markdown, Text, eine URL oder ein hochgeladenes Dokument. WikiKit bewahrt den extrahierten Inhalt unverändert auf und bildet einen SHA-256-Hash. Derselbe Inhalt wird dadurch nicht mehrfach als neue Quelle behandelt. Ein Konzept ist eine gepflegte Seite über eine Sache, zum Beispiel `retry-policy`. Der Text hilft beim Lesen, ist aber nicht die kleinste überprüfbare Einheit. Ein Claim ist eine einzelne Aussage. Er besteht aus Subjekt, Prädikat und Objekt, trägt eine Confidence und verweist auf mindestens ein wörtliches Zitat. Im Beispiel lautet die Aussage: Die Retry Policy verwendet ein gemeinsames Zeitbudget. Eine Änderungsvorschlag bündelt die geplanten Änderungen. Sie ist für Leser unsichtbar, bis ein Mensch sie freigibt. Damit kann ein Modell beim Verdichten helfen, ohne selbst festzulegen, was künftig als geprüftes Wissen gilt. ```json { "subject": "retry-policy", "predicate": "uses_budget", "object": "one shared budget across all attempts", "confidence": 0.96, "citations": [ { "source_id": "source_7f2c", "quote": "The retry budget is shared across all attempts.", "locator": "Decision, paragraph 2" } ] } ``` Diese Trennung wirkt zunächst ausführlicher als eine Wiki-Seite mit einem Absatz. Sie spart die mühsame Rekonstruktion später. Der Leser muss nicht raten, welche Formulierung aus einer Quelle stammt und welche beim Zusammenfassen entstand. ```mermaid flowchart LR S["Quelle
unverändert archiviert"] --> C["Claim
kleine Aussage mit Zitat"] C --> P["Vorschlag
noch unsichtbar"] P --> R{"Menschliche
Prüfung"} R -->|freigeben| K["Konzept-Revision
sichtbares Wissen"] R -->|ablehnen| H["Historie
mit Begründung"] ``` ## Der erste Schritt bewahrt das Original Ein Agent oder ein Mensch reicht das Meeting-Protokoll über die HTTP-API ein. Der Vorgang antwortet asynchron mit `202 Accepted`, weil Extraktion, Klassifikation und Synthese nicht in einen langen Request gezwängt werden. Der Client fragt den Status anschließend über die zurückgegebene Kennung ab. ```bash curl -X POST "$WK/v1/spaces/engineering/ingest" \ -H "Authorization: Bearer $WK_KEY" \ -H "Content-Type: application/json" \ -d '{ "title": "Retry policy meeting", "source_kind": "meeting", "markdown": "# Decision\nThe retry budget is shared across all attempts." }' ``` WikiKit normalisiert nicht still den Inhalt der Quelle. Das ist wichtig, weil ein späterer Beleg nur dann etwas wert ist, wenn er gegen genau den Text geprüft werden kann, den das Modell gesehen hat. Ein vermeintliches Zitat, das in dieser Quelle nicht wörtlich vorkommt, wird verworfen, bevor der Vorschlag den Review erreicht. Der Hash erfüllt dabei zwei Aufgaben. Er erkennt eine identische Wiederholung und macht den Inhalt adressierbar. Er entscheidet jedoch nicht über die fachliche Bedeutung. Zwei leicht unterschiedlich formulierte Protokolle können dieselbe Entscheidung beschreiben und bleiben trotzdem zwei Quellen. Ob sie dasselbe Konzept betreffen, gehört in die folgende Klassifikation und anschließend in die Prüfung. ## Das Modell schlägt vor, das System kontrolliert Nach der Archivierung sucht die Klassifikation nach betroffenen oder neuen Konzepte. Für jedes betroffene Konzept entsteht ein Entwurf mit Claims, Zitaten und Beziehungen. Das Modell darf formulieren und zuordnen. Der Grounding Guard kontrolliert danach mechanisch, ob jedes angegebene Zitat tatsächlich in der referenzierten Quelle vorkommt. Das ist eine bescheidene, aber wirksame Kontrolle. Sie beweist nicht, dass eine Interpretation fachlich richtig ist. Sie verhindert eine häufige Fehlerklasse: Ein flüssig formuliertes, frei erfundenes Zitat gelangt gar nicht erst zur Freigabe. Die anspruchsvollere Frage – ob der Satz die geplante Aussage wirklich trägt – bleibt beim Menschen. Mehrere Änderungen aus einem Ingest werden in einem gemeinsamen Vorschlag gesammelt. Der prüfende Person sieht dadurch den Zusammenhang, statt fünf voneinander getrennte Kleinständerungen zusammensuchen zu müssen. Der Vorschlag enthält außerdem den Ausgangsstand der betroffenen Seite. Wurde das Konzept inzwischen verändert, verhindert ein Stale-Base-Check die Freigabe gegen eine überholte Revision. ```text Proposal: retry-policy update Base revision: 3 Proposed revision: 4 Source: Retry policy meeting + uses_budget = one shared budget across all attempts quote: "The retry budget is shared across all attempts." ``` Eine Freigabe wendet die vorbereiteten Änderungen atomar in PostgreSQL an. Leser sehen damit entweder die alte oder die neue vollständige Revision. Ein halber Zustand, in dem der neue Seitentext bereits sichtbar ist, aber sein Claim oder seine Quelle noch fehlt, gehört nicht zum Lesemodell. ## Was sich seit damals geändert hat Der Artikel [Wissen, das die Session überlebt](https://www.mikebild.dev/de/blog/wissen-das-die-session-ueberlebt/) hat im Juni den nötigen Kreislauf beschrieben: Erfahrungen aus echten Sessions sammeln, durch Menschen kuratieren und das Destillat in die nächste Session geben. Versionierung, Review, Ownership und ein Lebenszyklus waren dort methodische Anforderungen. Als kleinster praktikabler Anfang dienten Dateien, Branches und Pull Requests. WikiKit setzt diesen Gedanken inzwischen als eigenständigen, headless Dienst um. Aus dem allgemeinen „Wissen wie Code behandeln“ sind konkrete Zustände und Regeln geworden: - Rohmaterial bleibt als Quelle erhalten; die sichtbare Zusammenfassung ersetzt es nicht. - Jede einzelne Aussage trägt einen wörtlichen Beleg und einen Status. - Agenten dürfen mit passend beschränkten Schlüsseln lesen und Änderungen vorschlagen, ohne Freigaberechte zu erhalten. - Abgelehnte, umstrittene und überholte Aussagen verschwinden nicht spurlos aus der Geschichte. Auch [Sauberes Grounding I](https://www.mikebild.dev/de/blog/sauberes-grounding-warum-ki-raet/) und [Sauberes Grounding II](https://www.mikebild.dev/de/blog/sauberes-grounding-antworten-erden/) endeten bei einer klaren Forderung: Antworten müssen sich auf tatsächlich vorhandene Informationen stützen. Neu ist die feinere Trennung zwischen Finden und Gelten. Retrieval kann eine passende Quelle liefern. Erst Claim, Beleg, Status und Review machen sichtbar, welche Aussage aus dieser Quelle im jeweiligen Space als geprüft gilt. Der gestern veröffentlichte Überblick [Werkzeuge, die zusammenspielen](https://www.mikebild.dev/de/blog/werkzeuge-die-zusammenspielen/) zeigt WikiKit bereits im Zusammenspiel mit Publishing und Präsentationen. Dieser Artikel zieht die Betrachtung enger. Er erklärt nicht die ganze Werkzeugkette, sondern den Prüfpfad einer Aussage. Genau diese Herkunftskette ist die technische Ergänzung zu den älteren methodischen Artikeln. ## Lesen bleibt frei von Synthese Für die normale Suche ist kein Sprachmodell nötig. Die Volltextsuche liefert Treffer aus den freigegebenen Konzept-Revisionen und sichtbaren Claims. Ein Client kann danach ein Konzept vollständig lesen und bei Bedarf seine Quellen oder seine Geschichte abrufen. ```bash curl "$WK/v1/spaces/engineering/search?q=retry+budget" \ -H "Authorization: Bearer $WK_READ_KEY" curl "$WK/v1/spaces/engineering/concepts/retry-policy" \ -H "Authorization: Bearer $WK_READ_KEY" curl "$WK/v1/spaces/engineering/concepts/retry-policy/history" \ -H "Authorization: Bearer $WK_READ_KEY" ``` Diese Aufteilung ist absichtlich. Eine Suche soll Fundstellen liefern und keine scheinbar vollständige Antwort erfinden. Wer eine natürlich formulierte Antwort benötigt, kann zusätzlich den Query-Weg verwenden. Der belegte Bestand bleibt aber auch ohne konfigurierten LLM-Provider suchbar, lesbar, prüfbar, exportierbar und lintbar. Ein Agent erhält dieselben Fähigkeiten über MCP. Die sichtbaren Werkzeuge hängen von seinen Scopes ab. Ein reiner Leseschlüssel sieht Such-, Lese-, Quellen-, Entscheidungs-, Historien- und Lint-Werkzeuge. Ein Schlüssel mit `knowledge:propose` darf zusätzlich Material einreichen oder einen strukturierten Vorschlag anlegen. Review-Werkzeuge erscheinen nur mit `knowledge:approve`; der letzte Approve- oder Reject-Schritt ist als bestätigungspflichtiger, irreversibler Write markiert. Das ist mehr als eine freundliche Instruktion. Fehlt der Scope, fehlt die Fähigkeit technisch. Ein Agent kann die Freigabe dann nicht versehentlich auslösen, weil das Werkzeug für ihn gar nicht angeboten wird. ## Woran ein Leser die Qualität erkennt Eine schön geschriebene Konzept-Seite kann hilfreich sein, reicht als Vertrauenssignal aber nicht. Für die Prüfung zählen andere Fragen: Gibt es zur konkreten Aussage einen Claim? Enthält er ein wörtliches Zitat? Ist die Quelle erreichbar? Welchen Status trägt der Claim? Welche Revision führte ihn ein, und wer hat den Vorschlag freigegeben? ```mermaid flowchart TD Q["Frage zur Retry Policy"] --> F["Volltextsuche"] F --> C["Konzept und sichtbare Claims"] C --> Z["Zitat und Locator"] Z --> S["archivierte Quelle"] C --> V["Revision und Freigabehistorie"] ``` Fehlt an einer Stelle die Verbindung, ist die richtige Reaktion kein sprachliches Kaschieren. Der Lint-Weg meldet unter anderem fehlende Zitate, Widersprüche, veraltete Claims, verwaiste Konzepte und beschädigte Beziehungen. Ein leerer Suchtreffer darf leer bleiben. Sichtbares Nichtwissen ist leichter zu korrigieren als eine überzeugende Antwort ohne Grundlage. ## Was beim Review tatsächlich geprüft wird Ein Vorschlag ist kein Korrekturlesen eines fertigen Wiki-Artikels. Der prüfende Person prüft zuerst, ob die vorgeschlagene Seite überhaupt zum richtigen fachlichen Begriff gehört. Eine Aussage über das gemeinsame Retry-Budget darf nicht versehentlich in einem allgemeinen Konzept über HTTP-Timeouts landen. Die Zuordnung entscheidet später darüber, ob Menschen und Agenten den Inhalt bei der passenden Frage finden. Danach kommt die Aussage selbst. Subjekt, Prädikat und Objekt sollen klein genug sein, dass Zustimmung oder Ablehnung eindeutig möglich sind. „Our retry handling is reliable“ wäre dafür ungeeignet. Der Satz vermischt Bewertung, unbekannte Kriterien und mehrere mögliche Beobachtungen. „Retry attempts use one shared time budget“ lässt sich dagegen an einer Quelle prüfen und später gezielt bestreiten oder ersetzen. Im dritten Schritt wird das Zitat im Zusammenhang gelesen. Der Grounding Guard bestätigt lediglich, dass die Zeichenfolge in der Quelle vorkommt. Vielleicht stand direkt davor: „For the legacy client only“. Dann wäre das Zitat echt, die daraus abgeleitete allgemeine Aussage aber zu weit. Genau deshalb bleibt die menschliche Prüfung auch bei einem technisch verifizierten Zitat nötig. Schließlich betrachtet die prüfende Person die Folgen für den vorhandenen Stand. Ergänzt der Claim eine Lücke? Wiederholt er eine bestehende Aussage? Oder widerspricht er einer bereits freigegebenen Regel? Bei funktionalen Prädikaten kann WikiKit unterschiedliche Objekte für dasselbe Subjekt und Prädikat als Konflikt markieren. Das System legt damit den Widerspruch offen; es entscheidet nicht durch sprachliche Plausibilität, welche Seite recht hat. Eine knappe Review-Notiz macht die Entscheidung später verständlicher: ```json { "decision": "approve", "note": "The source applies to the current HTTP client and the claim preserves the stated scope." } ``` Bei einer Ablehnung bleibt ebenfalls ein nachvollziehbarer Eintrag. Das Rohmaterial geht nicht verloren, und ein späterer Vorschlag kann dieselbe Quelle mit einer engeren Aussage erneut verwenden. Ablehnen bedeutet hier: Diese konkrete Änderung wird nicht zu sichtbarem Wissen. Es bedeutet nicht, dass das Meeting nie stattgefunden hat. Für einen kleinen Bestand dauert dieser Prüfgang oft nur wenige Minuten. Seine Wirkung zeigt sich später, wenn jemand die Seite öffnet und nicht mehr die gesamte Entstehungsgeschichte rekonstruieren muss. Die Herkunft wurde beim Übergang ins Wissen mitgeführt, statt erst bei einer strittigen Frage mühsam nachgetragen zu werden. ## Was einfach bleibt WikiKit ist bewusst headless. Es bringt weder eine eigene Weboberfläche noch eine Kommandozeile mit. Menschen können die REST-API verwenden; Agenten arbeiten über MCP. OpenAPI, `llms.txt` und `llms-full.txt` beschreiben die vorhandenen Wege maschinenlesbar. Für einen lokalen Start werden eine PostgreSQL-Instanz und optional ein LLM-Provider benötigt; ohne Provider bleiben die LLM-freien Kernfunktionen verfügbar. Die Speicherung in PostgreSQL macht aus WikiKit kein geschlossenes Format. Ein Space lässt sich als deterministischer Markdown-Baum oder als OKF-Bundle exportieren. Konzepte, Claims, Beziehungen, Quellen und Entscheidungen werden damit transportierbar. Wer den Dienst später austauscht, verliert nicht die einzige lesbare Fassung seines Wissens. Am Ende steht bei unserem Beispielsatz eine kleine, überprüfbare Kette. Der Leser sieht die aktuelle Retry Policy. Der Claim sagt präzise, welches Budgetmodell gilt. Das Zitat zeigt, worauf diese Aussage beruht. Die Quelle enthält den ursprünglichen Wortlaut. Die Revision erklärt, wann die Aussage sichtbar wurde. Und die Freigabe zeigt, dass ein Mensch die Änderung bewusst übernommen hat. Damit überlebt Wissen nicht nur eine Session. Es behält auch die Spuren, die erklären, weshalb man ihm heute vertrauen kann. ## Weiterführende Quellen - [WikiKit auf GitHub](https://github.com/MikeBild/wikikit) - [WikiKit Architektur](https://github.com/MikeBild/wikikit/blob/main/docs/ARCHITECTURE.md) - [WikiKit Interface Contracts](https://github.com/MikeBild/wikikit/blob/main/docs/CONTRACTS.md) - [WikiKit Coding-Agent-Integration](https://github.com/MikeBild/wikikit/blob/main/docs/coding-agent-integration.md) - [Model Context Protocol: Streamable HTTP](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports) - [OpenAPI Specification 3.1](https://spec.openapis.org/oas/v3.1.1.html) - [Wissen, das die Session überlebt](https://www.mikebild.dev/de/blog/wissen-das-die-session-ueberlebt/) - [Sauberes Grounding I](https://www.mikebild.dev/de/blog/sauberes-grounding-warum-ki-raet/) - [Sauberes Grounding II](https://www.mikebild.dev/de/blog/sauberes-grounding-antworten-erden/) - [Werkzeuge, die zusammenspielen](https://www.mikebild.dev/de/blog/werkzeuge-die-zusammenspielen/)