LLM Wikis As Mind Maps For AI - Source Excerpt 05 - Open questions and limitations

Summary

This source excerpt begins near Open questions and limitations and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis as Mind Maps for AI.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis as Mind Maps for AI.md

| Phase | Deliverables | Decision points | Starting KPI targets |
|---|---|---|---|
| Discovery and modeling | Define node types, relation taxonomy, canonical route rules, multilingual policy, public/private boundary | Is the source of truth Git, CMS, or semantic wiki? | Approved schema, route spec, editorial rules |
| Publishing MVP | Canonical pages, hub pages, breadcrumbs, internal links, XML sitemap, robots.txt, JSON-LD, SSR/SSG | Static-first or hybrid? | 100% canonical pages render meaningful HTML; zero JS-only essential content |
| Retrieval layer | Node summaries, chunking rules, embeddings, hybrid search, metadata filters | pgvector vs dedicated vector DB; graph needed now or later? | p95 retrieval within agreed SLA; eval set coverage improving week over week |
| Graph layer | Typed edge store, backlinks, “related nodes,” local graph view, recommendation logic | Need full KG now, or just typed adjacency over pages? | Orphan rate trending down; neighbor click-through improving |
| Agent layer | REST/MCP/SPARQL read surface, tool descriptions, prompt template, tracing | Public tool surface or internal only? | Tool-call success rate; steps-to-answer decreasing |
| Hardening | Cache-control, CDN strategy, CSP, auth, rate limits, monitoring | Which pages are public vs protected? | No major auth leaks; stable cache hit rate; indexing errors near zero |

For hosting and caching, the important tradeoff is static simplicity versus hybrid flexibility. Astro prerenders statically by default but can opt specific routes into on-demand server rendering; Nuxt explicitly supports universal, client, hybrid, and edge rendering; Next.js supports SSR for per-request HTML and can programmatically generate metadata files such as sitemaps and robots. Vercel documents CDN caching for pages, assets, and functions with targeted cache-control headers; Cloudflare caches static content by default and can cache dynamic HTML through rules. In practice, public canonical node pages should be cache-friendly, while personalized or access-controlled views should be rendered dynamically and either excluded from indexing or protected outright. citeturn34view3turn34view2turn27view1turn27view0turn25view6turn27view2turn27view3

Security should be designed in from the start because agent/tool interfaces enlarge the attack surface. OWASP’s API Security Top 10 highlights broken object-level authorization as the first-class risk for ID-based APIs, which is directly relevant when nodes and edges are addressable by stable IDs. A Content Security Policy helps reduce client-side attack surface for rich documentation front ends. For public/private mixed wikis, the safest default is a hard split: public canonical pages and noindexed/private agent-only surfaces should not share the same exposure assumptions. citeturn27view4turn27view5

The prototype below shows how a small, public-facing mind-map wiki could be modeled with ten canonical nodes.

| Node ID | Type | Title | Canonical URL | Parent | Key outgoing relations |
|---|---|---|---|---|---|
| N01 | hub | AI | `/en/ai/` | — | `child_of` → N02, N03, N04 |
| N02 | concept | LLM Wikis | `/en/ai/llm-wikis/` | N01 | `child_of` → N05, N06; `related_to` → N03, N04 |
| N03 | concept | Knowledge Graph | `/en/concepts/knowledge-graph/` | N01 | `related_to` → N04, N02; `prerequisite_for` → N08 |
| N04 | concept | RAG | `/en/concepts/rag/` | N01 | `related_to` → N03, N02; `implemented_by` → N08 |
| N05 | concept | Mind-Map Navigation | `/en/ai/llm-wikis/mind-map-navigation/` | N02 | `related_to` → N06, N07 |
| N06 | concept | SEO Crawlability | `/en/ai/llm-wikis/seo-crawlability/` | N02 | `prerequisite_for` → N09; `related_to` → N07 |
| N07 | concept | Structured Data | `/en/ai/llm-wikis/structured-data/` | N02 | `implements` → N10; `related_to` → N06 |
| N08 | concept | Agent Interfaces | `/en/ai/llm-wikis/agent-interfaces/` | N02 | `implemented_by` → N09; `depends_on` → N03, N04 |
| N09 | task | Build an AI Wiki | `/en/tasks/build-an-ai-wiki/` | — | `depends_on` → N06, N08; `uses` → N10 |
| N10 | source | GraphRAG Paper | `/en/sources/graphrag-paper/` | — | `supports` → N02, N03, N08 |

That small model is intentionally mixed: it includes concepts, a task, and a source page, because real AI-navigation systems usually need all three. Concepts answer “what is it?”, tasks answer “how do I do it?”, and source pages anchor provenance.

Recommended initial KPIs should be simple and visible to both product and engineering. A good first dashboard should include: **indexed canonical node count, orphan-node rate, hybrid-search success on a curated eval set, context precision/recall, answer faithfulness, median and p95 retrieval latency, impressions/clicks/CTR for strategic hubs, and the percentage of successful agent traversals that terminate on a cited canonical page**. Search Console provides the public-web metrics; ARES and RAGAs provide the retrieval/answer quality frame. citeturn30view0turn30view1turn30view3turn22search3turn6search5

The most sensible next steps are therefore: **choose the source of truth; commit to canonical node-page rules; implement a static/hybrid publishing layer first; add typed relations second; add hybrid retrieval third; and only then add agent orchestration and graph-specific ranking**. In almost every case, getting the canonical pages, sitemaps, breadcrumbs, and internal link graph right first will produce more durable value than starting with a visually impressive but weakly indexable canvas.

## Open questions and limitations

Several constraints that would materially affect the final architecture were not specified: the expected number of nodes, public versus private mix, editorial velocity, multilingual requirements, identity/auth model, desired freshness SLA, budget for managed infrastructure, and whether the primary audience is humans, search engines, internal copilots, or public agents. Because of that, the report treats the safest default as a **public or semi-public, English-first, mixed human/AI knowledge property** rather than an internal-only private knowledge graph.

The strongest recommendation in that context is still high-confidence: **make pages canonical, keep graph state secondary, publish typed relationships visibly, and expose the same structure to machines through structured data plus APIs**. What remains open is not the shape of the pattern, but the exact implementation choice: static-first docs stack, headless CMS, semantic wiki, or graph-native dual-surface stack.