WikiKit: Wissen mit Herkunft

Diesen Beitrag anhören (12 Min.)

Im Protokoll steht ein unscheinbarer Satz: „The retry budget is shared across all attempts.“ Drei Wochen später soll ein Agent klären, 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, welchen geprüften Status der Satz heute trägt, wer ihn freigegeben hat und ob eine spätere Entscheidung ihn ersetzt.

Stand 16. August 2026 gilt: WikiKit archiviert die 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 zur archivierten Quelle.

Dieser Auftakt verfolgt eine einzelne Aussage durch diesen Weg.

Vier Dinge, die leicht verwechselt werden

Eine Quelle ist das eingereichte Rohmaterial: Markdown, Text, eine URL oder ein hochgeladenes Dokument. Bei Dokumenten extrahiert WikiKit den Inhalt zunächst als Markdown. Der daraus entstandene Quelleninhalt wird unverändert archiviert. Sein SHA-256-Hash verhindert, dass derselbe Inhalt mehrfach als neue Quelle gespeichert wird.

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. Bei der modellgestützten Synthese beschreibt die Confidence zwischen 0 und 1, wie stark das Zitat die Aussage trägt; die menschliche Prüfung bleibt davon getrennt. Sie ist weder Status noch Freigabewahrscheinlichkeit. Im Beispiel lautet die Aussage: Die Retry Policy verwendet ein gemeinsames Zeitbudget.

Ein Änderungsvorschlag bündelt die geplanten Änderungen. Er ist für Leser unsichtbar, bis ein Mensch ihn freigibt. Damit kann ein Modell beim Verdichten helfen, ohne selbst festzulegen, was künftig als geprüftes Wissen gilt.

Der Claim kann schematisch so aussehen:

{
  "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"
    }
  ]
}

Die Trennung spart die mühsame Rekonstruktion später. Der Leser muss nicht raten, welche Formulierung aus einer Quelle stammt und welche beim Zusammenfassen entstand.

Quelle · unverändert archivieren und eindeutig adressieren
Claim · eine kleine Aussage mit Zitat und Herkunft formulieren
Vorschlag · die mögliche Wissensänderung getrennt halten
Review · Beleg, Widerspruch und Geltungsbereich prüfen
Konzept-Revision · Freigabe atomar sichtbar machen oder begründet ablehnen

Der erste Schritt bewahrt den Quelleninhalt

Ein Agent oder ein Mensch reicht das Meeting-Protokoll über die HTTP-API ein. Die API antwortet auf den Ingest mit 202 Accepted und einer Kennung. Der Client fragt den Status anschließend separat über diese Kennung ab.

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."
  }'

# 202 response: {"ingest_id":"<ingest-id>", ...}
curl "$WK/v1/ingests/<ingest-id>" \
  -H "Authorization: Bearer $WK_KEY"

WikiKit normalisiert den archivierten Quelleninhalt nicht nachträglich. 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 erkennt eine identische Wiederholung, entscheidet aber 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 formuliert, der Grounding Guard prüft das Zitat

Nach der Archivierung entsteht ein Vorschlag mit Claims und Zitaten. Das Modell darf formulieren und zuordnen. Der Grounding Guard kontrolliert danach mechanisch, ob jedes angegebene Zitat tatsächlich in der referenzierten Quelle vorkommt.

Diese Kontrolle beweist nicht, dass eine Interpretation fachlich richtig ist. Sie verhindert eine konkrete 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. Die prüfende Person sieht dadurch den Zusammenhang, statt fünf voneinander getrennte Kleinä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.

Schematisches Beispiel:

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.

Der Prüfpfad gehört zum Wissensmodell

WikiKit setzt den Kreislauf aus Quelle, Kuration und Wiederverwendung mit konkreten Zuständen und Regeln um:

Rohmaterial bleibt als Quelle erhalten; die sichtbare Zusammenfassung ersetzt es nicht.
Jede einzelne Aussage trägt einen wörtlichen Beleg.
Agenten dürfen mit passend beschränkten Schlüsseln lesen und Änderungen vorschlagen, ohne Freigaberechte zu erhalten.
Freigaben und Ablehnungen bleiben als Entscheidungen protokolliert.
Claims besitzen einen getrennten Lebenszyklus: proposed wartet auf Prüfung, verified ist freigegeben, disputed markiert einen Konflikt und deprecated eine überholte Aussage.

Die Artikel Wissen, das die Session überlebt, Sauberes Grounding I und Sauberes Grounding II beschreiben den methodischen Hintergrund. WikiKit konkretisiert ihn als Prüfpfad einer einzelnen Aussage. Retrieval kann eine passende Quelle liefern. Erst Claim, Beleg, Status und Review machen sichtbar, welchen geprüften Status die Aussage im jeweiligen Space hat.

Der Leseweg synthetisiert nicht

Für die normale Suche ist kein Sprachmodell nötig. Die Volltextsuche liefert Treffer aus dem sichtbaren Wissensstand. Ein Client kann danach ein Konzept vollständig lesen und bei Bedarf seine Quellen oder seine Geschichte abrufen.

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"

Anschließend lässt sich der Treffer über Claim und Zitat bis zur Quelle verfolgen. Auch diese Werte sind schematisch:

Concept revision 4
└─ Claim: retry-policy uses_budget one shared budget
   └─ Citation: "The retry budget is shared across all attempts."
      └─ Source: source_7f2c

Eine Suche soll Fundstellen liefern und keine scheinbar vollständige Antwort erfinden. Wer zusätzlich eine natürlich formulierte Antwort erzeugen will, kann 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 den nativen MCP-Endpunkt. Die sichtbaren Werkzeuge hängen von seinen Scopes ab. Ein reiner Leseschlüssel sieht Suche, Lesen und Quellenzugriff. Ein Schlüssel mit knowledge:propose darf zusätzlich Material einreichen oder einen strukturierten Vorschlag anlegen. Review-Werkzeuge erscheinen erst mit knowledge:review; die endgültige Entscheidung trifft ein Mensch über die native Form-Elicitation oder den menschlichen Übergabelink.

Fehlt der Scope, wird das Werkzeug nicht angeboten. Über die ihm angebotenen MCP-Werkzeuge kann ein Agent die Freigabe dann nicht auslösen.

Woran ein Leser die Herkunft prüft

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?

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, darf das System die Lücke nicht mit einer unbelegten Antwort verdecken. Der Lint-Weg meldet unter anderem Widersprüche, fehlende Zitate und veraltete Claims. Eine Suche ohne Treffer darf ohne Antwort enden. 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. Zuerst klärt die prüfende Person, 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:

{
  "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.

Wer die Seite später öffnet, muss nicht mehr die gesamte Entstehungsgeschichte rekonstruieren. Die Herkunft wurde beim Übergang ins Wissen mitgeführt, statt erst bei einer strittigen Frage mühsam nachgetragen zu werden.

Ein Wissenszustand, drei Zugänge

WikiKit trennt das Wissensmodell von seinen Zugängen. Es speichert Herkunft und Freigabe im Wissenszustand, nicht in einer einzelnen Oberfläche. Menschen arbeiten im eingebauten Cockpit unter /cockpit; MCP und REST bleiben eigenständige Zugänge für Agenten und feste Dienste. Alle drei greifen auf denselben kuratierten Zustand zu.

WikiKit speichert den Wissenszustand in PostgreSQL; die dokumentierte Konfiguration verlangt dafür eine PostgreSQL-Verbindung. Ein LLM-Provider ist dagegen nur für die modellgestützten Wege wie Ingest und Query erforderlich. Volltextsuche, Lint, Health sowie Export und Import bleiben ohne Provider verfügbar.

Ein Space lässt sich als deterministisches ZIP mit einem Markdown-Baum oder als OKF-v0.1-Bundle exportieren. Claims laufen über Frontmatter verlustfrei durch den Markdown-Weg; ein Import durchläuft wieder die Freigabeprüfung. Der exportierte Markdown-Baum bleibt auch ohne laufenden Dienst lesbar; das OKF-Bundle bleibt transportierbar.

Ohne diese Kette kann ein System nur sagen, dass es einen Satz gefunden hat. Mit Quelle, Claim, Zitat, Revision und Freigabe kann es zusätzlich zeigen, weshalb dieser Satz im aktuellen Wissensstand als geprüft geführt wird.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare