LLM-Wiki: Wenn der Agent die eigene Wissensbasis pflegt

Der eigentliche Unterschied zu RAG

Vier Fehler, die RAG nicht hat

• 1Halluzinationen werden persistent. Bei RAG verschwindet eine falsche Antwort mit dem Chatverlauf. Im Wiki steht sie als Seite und wird beim nächsten Ingest als „bestehendes Wissen“ gegen die neue Quelle gehalten. Das „Compounding“ gilt für Fehler genauso wie für Wissen. Gegenmittel: Jede Aussage im Wiki trägt einen Verweis auf die Rohquelle; Aussagen ohne Quelle sind per Schema verboten und werden vom Lint gemeldet.
• 2Das Schema driftet mit. Die CLAUDE.md ist Konfiguration, wird aber wie Prosa behandelt. Nach zwanzig Sessions weiß man nicht mehr, welche Regel warum hinzukam. Gegenmittel: Jede Schemaänderung bekommt einen Log-Eintrag mit Anlass, genau wie eine Wiki-Änderung.
• 3Ingest ohne Review. Karpathy ingestiert eine Quelle nach der anderen und liest die Änderungen mit. Sobald man batchweise ingestiert, schreibt der Agent ungeprüft ins Wiki. Gegenmittel: eine Quelle pro Auftrag, ein Log-Eintrag pro Änderung mit Begründung, und danach lesen.
• 4Die Messgröße fehlt. Bei RAG hat sich eingebürgert, Retrieval-Qualität zu messen. Für ein Wiki gibt es keine etablierte Metrik, und „das Wiki fühlt sich besser an“ ist keine. Ein Gegenmittel, das ich selbst noch nicht eingebaut habe: ein fester Satz Fragen, deren richtige Antworten man kennt, nach jedem Ingest erneut gestellt. Das beweist nicht, dass das Wiki hilft, aber es meldet, wenn eine Änderung etwas kaputt gemacht hat.

Mein Schema

• raw/ bleibt unangetastet. Jede Wiki-Seite zitiert Dateien in raw/. Fehlt eine davon, lässt sich die Seite nicht mehr prüfen. Der Agent darf deshalb nichts löschen, verschieben oder umbenennen.
• outputs/ wird beschrieben, aber nicht gelesen. Dort liegen generierte Antworten und Analysen, teils veraltet, teils ungeprüft. Nähme der Agent sie beim nächsten Auftrag als Quelle, würde aus einer früheren Halluzination bestehendes Wissen. Deshalb greift er auf outputs/ nur zu, wenn ich einen Ordner ausdrücklich nenne.
• Frontmatter nach einem öffentlichen Standard. Ich verwende Googles Open Knowledge Format, weil es type, sources und generated.at als Pflicht- bzw. Erwartungsfelder vorgibt und ein Linter die Struktur prüfen kann. Das ersetzt keinen Review, macht aber Seiten ohne Quelle maschinell auffindbar.

CLAUDE.md · Wurzel der Wissensbasis

# Knowledge Base Schema

## What This Is

A knowledge base maintained by an LLM agent: markdown pages with YAML frontmatter, linked into a
graph, with an `index.md` hierarchy and a `log.md` history. The page format follows Google's Open
Knowledge Format (OKF) v0.2; the bundle root `wiki/index.md` declares `okf_version: "0.2"`.

## How It's Organized

- `raw/` contains unprocessed source material. It is IMMUTABLE: never modify, delete, move, or rename
  anything in `raw/`. The wiki's provenance depends on every cited raw file staying exactly where it
  is; a deleted raw source makes its wiki article impossible to rebuild or re-verify. If `raw/` seems
  to contain junk, propose its removal and wait for explicit approval; never delete on your own
  initiative.
- `wiki/` contains the organized wiki. The agent maintains this entirely.
  - `wiki/concepts/` — topic pages (one `.md` per topic)
  - `wiki/entities/` — people, organizations, places, products
  - `wiki/explorations/` — saved query results and durable analyses
  - `wiki/index.md` + per-folder `index.md` — hierarchy, one line per page
  - `wiki/log.md` — append-only change log
  - `wiki/AGENTS.md` — detailed governance rules for maintaining the wiki (read it before editing wiki
    content)
- `outputs/` contains generated reports, answers, and analyses. It is a working area, not curated
  knowledge: material there may be stale, superseded, or unreviewed.
- Root allows only `raw/`, `wiki/`, `outputs/` and hidden dotfiles/dotdirs (tool config, e.g.
  `.obsidian/`, `.git*`). No other visible top-level file or folder is allowed. Curated content goes
  in `wiki/`, generated work in `outputs/` (its own subfolder), sources in `raw/`. If a stray root
  item appears, propose where it belongs and wait for approval before acting.

## Source Discipline

- Knowledge lookups, research, and content for new deliverables draw on `wiki/` (curated) and `raw/`
  (immutable sources) only.
- Never read, cite, or reuse material from `outputs/` on your own initiative, not as examples, prior
  art, or reference. Work with an `outputs/` subfolder only when the user explicitly names it for the
  current task.
- Writing new deliverables into `outputs/` (each in its own subfolder) remains the normal workflow.

## Searching the Repository

- Always search with `rg` (ripgrep), never with `grep`/`find`. Reason: `grep -r` pulls in binaries,
  SVGs and large HTML scrapes from `raw/` and returns noise.
- Default call: `rg -i "pattern" wiki/ raw/`. File names only: `-l`. Markdown only: `-g '*.md'`. Cut
  noise: `-g '!*.svg' -g '!*.html'`.
- `rg` skips hidden directories and respects `.gitignore`. For dotdirs: `rg --hidden --no-ignore -g
  '!.git/'`.
- Find files instead of contents: `rg --files -g '*pattern*'` instead of `find`.

## Wiki Rules (OKF v0.2)

- Every content page carries YAML frontmatter: `type` is required (Concept, Organization, Person,
  Place, Product, Exploration); `title`, `description`, `tags` and `generated` (by + at, UTC) are
  expected; `sources` (structured list, `resource` per entry), `verified`, `status`, `stale_after`,
  `resource` are optional.
- `index.md` files carry no frontmatter (root `wiki/index.md`: exactly `okf_version`).
- Every page starts (after frontmatter) with a one-paragraph summary.
- Article bodies link related pages with bundle-absolute markdown links
  (`[topic](/concepts/topic.md)`, `[name](/entities/name.md)`); `raw/` and `outputs/` pointers stay
  relative; index files use relative markdown links. Wikilinks are legacy; the linter flags them.
- Maintain the `index.md` files: every page listed once with a one-line description.
- When new raw sources are added, update the relevant wiki articles, record citations in `sources:`,
  and refresh `generated.at`.
- Details in `wiki/AGENTS.md`; verify structural edits with the OKF linter before committing.

## Answering Knowledge Questions

- Answer from the curated wiki, grounded in `wiki/` and `raw/`, with sources cited.
- If the wiki does not cover a question, say so; do not fill the gap from general knowledge without
  marking it as such.
- Durable answers (comparisons, analyses, connections) are filed back into `wiki/explorations/` and
  listed in the index.

## Change Log

- Maintain `wiki/log.md`, a chronological record of wiki changes so recent activity is easy to see.
- Append a new entry whenever wiki files are created, updated, split, renamed, or deleted (including
  during reindex runs).
- Entry format: `## YYYY-MM-DD` header (group multiple edits on the same day); beneath it, one bullet
  per change: what changed + one-line why/trigger. Keep bullets terse; the wiki files themselves are
  the detail.
- Newest entries go at the top of `log.md`. Only append; never rewrite historical entries.
- If the log gets long (~500 lines), archive older entries to `wiki/log-archive.md` grouped by year.

wiki/AGENTS.md · Detailregeln

# Wiki Governance

Instructions for any AI agent maintaining this wiki. The wiki follows Google's Open Knowledge Format
(OKF) v0.2. The bundle root is `wiki/`; its `index.md` declares `okf_version: "0.2"`.

## Structure

- `concepts/` holds topic pages, one file per topic. Categories: AI & Machine Learning (`ai-ml`),
  Domain Applications (`domain-applications`), Foundations (`foundations`), Business (`business`).
- `entities/` holds pages for people, organizations, places, and products that recur across concepts.
  Create an entity page when something is referenced from two or more concepts or is load-bearing for
  the business.
- `explorations/` holds saved query results and durable analyses. Large generated artifacts (reports,
  decks, code packs) belong in `outputs/` instead.
- `index.md` in each folder lists every page with a one-line description; `index.md` at wiki root
  links the sections. Update indexes in the same turn as any page create/rename/delete.
- `log.md` is the append-only change log (rules below).

## Page Format (OKF v0.2)

Every content page starts with YAML frontmatter, then a one-paragraph summary, then the body:

    ---
    type: Concept            # required; Concept, Organization, Person, Place, Product, Exploration
    title: "Page Title"
    description: "One-line summary used in indexes"
    tags: [ai-ml]            # category tag for concepts; kind tags for entities
    sources:                 # optional; where the page's citations live (see below)
      - resource: "https://example.org/doc"
        id: "s1"
        title: "Short label"
    generated:               # required here; who last produced/updated the page + when (UTC)
      by: "process:claude-wiki-maintenance"
      at: 2026-07-31T12:00:00Z
    ---

- `type` is mandatory on every page. `title`, `description`, `tags`, `generated` are house-required
  even though OKF marks them optional.
- `generated.at` replaces the old v0.1 `timestamp`; refresh it on every substantive edit.
  `generated.by` follows the OKF actor convention: `process:<id>` or `<producer>/<version>` for
  agents, `human:<id>` for people.
- Citations live in frontmatter `sources:` (list of mappings; `resource` required per entry,
  `id`/`title` optional, ids `s1..sN` unique). An explanatory citation section in the body may stay
  for the human reader, but frontmatter is authoritative.
- Optional trust fields: `verified:` (list of `{by, at}`; a `human:` entry marks the page
  human-reviewed), `status:` (`draft` | `stable` | `deprecated`; absent means stable), `stale_after:`
  (`YYYY-MM-DD`; linter warns once passed).
- Optional `resource:` may point to a canonical external URL (repo, console, dashboard) when one
  exists.
- `index.md` files carry NO frontmatter. Sole exception: the bundle root `wiki/index.md` declares
  exactly `okf_version: "0.2"`.

## Linking

- Article bodies cross-link with markdown links, bundle-absolute from the wiki root: `[topic
  name](/concepts/topic.md)`, `[entity name](/entities/name.md)`. Wikilinks (`[[...]]`) are v0.1
  legacy; the linter flags them (double brackets inside code spans, e.g. C++ `[[nodiscard]]`, are
  fine).
- Links out of the bundle (immutable sources, artifacts) stay relative:
  `[label](../../raw/pack/README.md)`.
- Index files use relative markdown links (`[Title](slug.md)`).
- Link liberally: concepts to concepts, entities to the concepts that mention them, and back. The
  linter reports pages with no incoming article links as orphans.

## Change Log

- Append a new entry to `log.md` whenever wiki files are created, updated, split, renamed, or deleted
  (including reindex runs).
- Entry format: `## YYYY-MM-DD` header (group same-day edits); beneath it one bullet per change: what
  changed plus a one-line why/trigger. Terse bullets; the wiki files are the detail.
- Newest entries at the top. Only append; never rewrite historical entries.
- At ~500 lines, archive older entries to `log-archive.md` grouped by year.

## Verification

- After structural edits (new/renamed/deleted pages, index changes), run the OKF linter from the
  Knowledge root. It checks OKF v0.2 conformance: frontmatter validity, required `type`, `generated`
  (actor + ISO datetime), `sources`/`verified`/`status`/`stale_after` structure, index.md frontmatter
  rules, markdown-link resolution, leftover wikilinks, index coverage, orphan pages, and uncited
  top-level `raw/` entries. Errors must be fixed; warnings (orphans, stale `outputs/` pointers, passed
  `stale_after`) are review queues.

## Content Rules

- Every page starts (after frontmatter) with a one-paragraph summary.
- `raw/` is IMMUTABLE source material: never modify, delete, move, or rename anything in it. The
  wiki's provenance depends on cited raw files staying in place. When new raw sources arrive, update
  the relevant concept pages. If raw/ seems to hold junk, propose removal and wait for explicit user
  approval; never prune raw/ on your own initiative.
- Never source wiki content from `outputs/`: it is generated working material, possibly stale or
  unreviewed. Wiki updates draw on `raw/` sources and existing wiki pages; touch an `outputs/`
  subfolder only when the user explicitly names it.
- German content uses formal "Sie". Prose avoids em dashes (use colon, comma, parentheses, or period).
- Prose reads direct and human: concrete verbs, no filler abstractions.

• Der Linter. Ein Python-Skript prüft nach jeder Strukturänderung Frontmatter, Links, Index-Abdeckung, verwaiste Seiten und Rohquellen, die noch keine Wiki-Seite zitiert. Fehler behebt der Agent sofort; Warnungen sind die Prüfliste für den nächsten Durchgang. Inhaltliche Widersprüche findet das Skript nicht, dafür frage ich den Agenten.
• Das Log. Jeder Eintrag nennt, was geändert wurde und warum. Ich löse jeden Ingest selbst aus und lese danach das Log; das ist mein Review. Ein Agent, der eine Quelle nach der anderen einarbeitet und dabei Rechenschaft ablegt, braucht keinen Freigabe-Knopf.

Was bleibt

Wer das mit Claude Code aufsetzen will, für sich oder im Team, findet Schema-Dateien, Hooks und Review-Workflows als Übungsteil in meiner Claude-Code-Schulung.