Knowledge Graphs for LLM Wikis

A knowledge graph is the semantic layer that makes an LLM Wiki more than searchable markdown. It names the things the wiki knows about, the claims being made, where those claims came from, how pages relate, which facts are stale or contradicted, and which path an agent should follow before it answers or updates memory.

Layered graph architecture

The strongest LLM Wiki graph does not start with a database. It starts with governed source memory and derives graph views from it. Each layer has a job, and agents should know which layer they are reading before they answer, summarize, or propose a write.

RDF, property graph, and markdown roles

Markdown remains the reviewed memory that people can inspect. RDF/JSON-LD is strongest when a team needs standards-aligned interchange, named graph snapshots, and SHACL-style validation. A property graph is strongest for impact analysis, relationship exploration, graph dashboards, and operational queries. A mature LLM Wiki can support more than one projection, but it should never let a generated projection drift into a second source of truth.

Knowledge graph build order

1. Keep raw sources immutable. Store originals, source summaries, hashes, and locators before graph extraction starts.
2. Make markdown pages graph-ready. Add page type, status, source trace, related pages, contradictions, and last-reviewed fields.
3. Name durable entities and claims. Use stable IDs for projects, pages, concepts, people, systems, constraints, decisions, claims, and evidence records.
4. Derive graph edges from reviewed content. Generate supports, contradicts, supersedes, depends-on, derived-from, reviewed-by, and archives-to links from visible page fields and reviewed notes.
5. Validate before retrieval. Run deterministic link, metadata, provenance, contradiction, and freshness checks before exposing the graph to retrieval, GraphRAG, or export tools.

Minimum graph model

Stable IDs

Titles, routes, and filenames change. Stable graph identity should not. Use project-owned IDs for durable records, snapshot IDs for release or archive states, and source IDs that survive file moves. Avoid durable blank-node-style identity for important handoff facts, because future agents need to cite the same thing after a rename.

kg:page/operations-ingest
kg:section/operations-ingest#write-checklist
kg:claim/ingest-requires-log-entry
kg:source/raw-2026-05-06-kg-report
kg:review/2026-05-06-public-guide-pass

Claim, source-span, and review states

For AI handoff, the most useful graph node is often the claim. A claim is smaller than a page and stronger than a keyword. It can say exactly what is being asserted, which source span supports it, who reviewed it, whether it is contradicted, and where it may be promoted.

Hybrid retrieval order

Graph retrieval is strongest when it works with plain search and exact paths. Use the graph to connect evidence, not to replace evidence. A good assistant answer should be able to show the path it walked.

1. Start exact. Check named routes, page IDs, source IDs, issue IDs, package names, and file paths before broad retrieval.
2. Search text. Use lexical search over reviewed pages and source summaries to catch names, aliases, and explicit wording.
3. Traverse the graph. Follow supports, contradicts, supersedes, depends-on, reviewed-by, and archives-to edges to gather surrounding context.
4. Use vectors last as recall help. Embeddings can find nearby concepts, but similarity is not proof.
5. Filter by governance. Remove or flag private, stale, blocked, unreviewed, and unsupported nodes before answer drafting.
6. Cite and abstain. Cite source pages and source records. If the graph lacks reviewed evidence, say so instead of inventing an answer.

Relation vocabulary

Standards mapping

GraphRAG boundary

GraphRAG can help an agent gather related concepts and traverse evidence paths, but it must not turn nearest-neighbor confidence into truth. A graph-assisted answer should cite the pages and source records it used, name contradictions, avoid unsupported synthesis, and write any useful new result back as a reviewed candidate rather than an invisible chat-only memory.

Implementation sequence

1. Pick the authoring contract. Define frontmatter fields, page kinds, claim states, relation names, source-span format, sensitivity labels, and review events.
2. Seed graph-ready pages. Convert a small, high-value slice before broad ingest: one source page, one concept page, one contradiction record, one review log entry, and one query fixture.
3. Build deterministic extraction first. Parse frontmatter, headings, explicit links, route maps, source traces, and review logs before asking an LLM to suggest extra entities or claims.
4. Run graph lint. Fail export readiness when required IDs, source traces, contradiction owners, sensitivity labels, or review states are missing.
5. Publish derived artifacts deliberately. Name whether the output is markdown navigation, JSON-LD/RDF, property graph, search index, vector cache, or GraphRAG context bundle.
6. Review answer behavior. Test useful queries, contradiction handling, citation presence, stale/blocked filtering, and abstention before using graph retrieval in handoff.

Evaluation and safety checks

Graph lint checklist

• Every reviewed claim has a source trace or an explicit source-needed status.
• Every contradiction edge has a contradiction record, owner, and next review action.
• Every superseded page points forward to the current page and carries stale or archived status.
• Every GraphRAG candidate answer lists source pages, graph path, unresolved contradictions, and promotion target.
• Every export names whether it is JSON-LD/RDF, property graph, search index, or retrieval cache, and whether it is read-only.