LLM Wikis And Hierarchical Structure - Source Excerpt 03 - Candidate schemas for an LLM Wiki

Back to LLM Wikis And Hierarchical Structure

Summary

This source excerpt begins near Candidate schemas for an LLM Wiki and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis and Hierarchical Structure.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis and Hierarchical Structure.md

From these patterns, the most durable design rules are straightforward. **Use one structure for navigation, another for semantic facts, and another for retrieval.** **Keep provenance attached to claims, not just to whole pages.** **Retain heading paths and section anchors all the way into the index.** And **make maintenance metadata opt-in or hidden by default** so the retrieval layer can use it without polluting the reader experience. Those lessons map unusually well from Wikimedia to LLM systems because they address the same basic problem: large, changing corpora that must be understandable by both humans and machines. citeturn31view0turn31view1turn24view9turn31view2turn30search8turn25view3

## Candidate schemas for an LLM Wiki

The four candidate schemas below are not mutually exclusive. In practice, the best production design is often a **document-first primary schema with one or two secondary overlays**. The main choice is therefore not “which one is correct?” but “which one should be primary, and which ones should be sidecars?” That framing is consistent with the way vector indexes, graph layers, and summary layers are combined in modern RAG systems. citeturn25view0turn25view1turn25view3turn25view10turn25view9

' ' ' mermaid
flowchart LR
    Q[User query] --> I{Intent and policy router}
    I --> K[Keyword and metadata retrieval]
    I --> V[Vector ANN retrieval]
    I --> G[Graph or taxonomy expansion]
    K --> R[Reranker]
    V --> R
    G --> R
    R --> P[Parent section and page expansion]
    P --> C[Citation and ACL filter]
    C --> A[Answer with provenance]
' ' ' 

| Schema | Core node types | Key relationships | Versioning and ACL model | Update workflow | Retrieval sweet spot |
|---|---|---|---|---|---|
| **Document tree with semantic overlays** | Space, Page, Section, Chunk, Asset, Tag, Redirect | `contains`, `links_to`, `tagged_with`, `cites`, `redirects_to` | Page and section revisions; inherited ACLs with optional section overrides | Parse changed page; re-chunk only changed sections; refresh outgoing/incoming links; re-embed changed chunks | Default wiki search, FAQ, grounded answers, low-latency retrieval |
| **Entity and claim graph** | Entity, Property, Claim, Qualifier, Source, Page, Chunk | `has_claim`, `has_qualifier`, `supported_by`, `mentioned_in`, `same_as` | Immutable claim revisions plus validity windows; ACLs can attach to entity, claim, or source | Extract candidate claims from pages; deduplicate; optional human review; publish to graph sidecar | Precise fact QA, disambiguation, multi-hop relation traversal |
| **Taxonomy and concept lattice** | Concept, Preferred label, Alias, Page, Section, Chunk, Collection | `broader`, `narrower`, `related`, `about`, `member_of` | Versioned concept vocabulary with deprecations and replacements; collection- or concept-level ACL | Govern vocabulary centrally; auto-tag pages to concepts; audit orphan or overlapping concepts | Browsing, faceted search, topic pages, query narrowing, policy and knowledge navigation |
| **Summary and community graph** | Corpus, Topic community, Summary node, Page, Section, Chunk, Entity | `summarizes`, `member_of`, `derived_from`, `links_to`, `contains` | Batch-generated summary versions tied to source snapshots; safest ACL model is inherited intersection from sources | Nightly or scheduled summary regeneration; incremental chunk indexing during the day | Corpus-wide synthesis, thematic questions, exploratory analysis, long-context corpora |

A **document tree with semantic overlays** is the best general-purpose primary schema. It maps cleanly to how MediaWiki, Notion, Obsidian, and most documentation systems are authored. It makes versioning, ACL inheritance, and incremental updates relatively cheap because most edits affect only one page or section. The semantic overlay can stay lightweight at first: typed tags, aliases, redirects, entity mentions, and citation metadata are enough to support strong hybrid retrieval without forcing the whole corpus into a graph-first authoring model. This schema is the safest default if the wiki will have many editors and frequent updates. citeturn24view8turn24view10turn23view7turn25view12turn25view10turn25view7

An **entity and claim graph** should usually be a sidecar rather than the only store. It excels when the corpus contains many recurring entities, repeated facts, state changes, and policy-like assertions that benefit from qualifiers and references. In other words, it is ideal for product specs, internal policies, regulated knowledge, research catalogs, or any domain where the same entity appears across many pages and freshness matters. The trade-off is authoring cost: graph extraction, claim normalization, and source attachment are all more expensive than storing sections and chunks. That cost is justified only when the domain actually needs typed claims. citeturn24view3turn24view4turn31view2turn31view3turn25view8turn25view3

A **taxonomy and concept lattice** is valuable when the main retrieval problem is not facts but **scope control**. SKOS-style broader/narrower/related concept graphs are especially effective for large workspaces where users need help narrowing from vague topics to specific subtopics, or where several overlapping vocabularies need to coexist. This schema is lighter than a full ontology or claim graph, easier to govern, and a strong migration target for flat wikis because existing category systems can often be ported into it with relatively low friction. citeturn25view5turn31view0turn31view1

A **summary and community graph** is the right overlay for “what does this corpus say overall?” questions. It is inspired by RAPTOR and GraphRAG and is especially useful for long reports, meeting archives, research collections, or company-wide documentation sets where the answer may need to cross many pages and abstraction levels. The downside is operational: summaries age, batch jobs add cost, and the governance model becomes harder because every summary node is derived rather than directly authored. This overlay is worth adding after the base document tree is stable, not before. citeturn25view1turn25view2turn25view3

| Schema | Retrieval latency | Relevance | Update cost | Scalability | Maintainability | Multimodal support | Analytic judgment |
|---|---:|---:|---:|---:|---:|---:|---|
| Document tree with semantic overlays | 5 | 4 | 4 | 5 | 5 | 4 | Best default primary schema |
| Entity and claim graph | 3 | 5 | 2 | 3 | 3 | 3 | Best for precision and provenance |
| Taxonomy and concept lattice | 4 | 4 | 3 | 4 | 4 | 3 | Best for navigation and scope control |
| Summary and community graph | 3 | 5 | 2 | 4 | 3 | 4 | Best for corpus-wide synthesis |

These scores are relative design inferences, not benchmark measurements. They are grounded in the fact that ANN indexes such as HNSW and systems like Faiss are built for low-latency approximate similarity, while graph-heavy and summary-heavy methods add extraction, traversal, or regeneration steps that improve some query classes but increase operational cost. citeturn25view6turn25view7turn25view9turn25view10turn25view1turn25view3

If a single recommendation is needed, the strongest choice is a **composite of the first schema plus selective pieces of the second and fourth**: use the document tree as the source of truth, add a claim graph only for high-value entities and facts, and add summary communities only for collections where users routinely ask global questions. That mix preserves maintainability while still addressing the known failure modes of flat vector-only retrieval. citeturn25view0turn25view1turn25view3turn31view2turn31view3

## Implementation guidance

No single tech stack is required for an LLM Wiki. The durable design choice is to keep **authoring storage**, **semantic storage**, and **retrieval indexes** loosely coupled. In practice, that means choosing one durable system of record for pages and metadata, then adding retrieval and graph indexes that can be rebuilt or partially rebuilt as needed. This reflects the separation of concerns visible in LangChain and LlamaIndex, and it also aligns with how Wikipedia separates page content from Wikidata-style structured facts. citeturn27view2turn26view0turn24view3turn24view8