LLM Wiki — Synaptic Lattice

Knowledge Graph

Properties1
tagsconcept, llm-wiki, architecture, second-brain

Leitura de 4 min

Definition

A knowledge graph is a network of interconnected entities and concepts where the connections (edges) represent meaningful relationships. In the LLM Wiki pattern, the knowledge graph emerges naturally from wikilinks between pages — the LLM creates these links during ingest, building a dynamic web of related ideas. Tools like roam-research pioneered the bidirectional linking concept that makes this navigable.

Key Points

  • In LLM Wiki, the knowledge graph is implicit: wikilinks (backtick-wrapped) are the edges, markdown pages are the nodes
  • Obsidian’s graph view provides a visual representation of this knowledge graph
  • The graph grows organically with each ingest — new sources add nodes and edges
  • Unlike traditional knowledge graphs that require manual schema design, the LLM Wiki graph is self-organizing
  • The graph reveals correlations between sources that would be easy to miss reading separately

Typed Relationships and Entity Extraction

LLM Wiki v2 extends the implicit wikilink graph with typed relationships and structured entity extraction. ^[raw/articles/llm-wiki-v2-rohitg00-2026.md] Instead of bare wikilinks (“A relates to B”), relationships carry semantic weight: “uses,” “depends on,” “contradicts,” “caused,” “fixed,” “supersedes.” Entities (people, projects, libraries, concepts, files, decisions) get a type, attributes, and explicit relationships to other entities.

Current Implementation

This vault has adopted typed relationships using the "type" [[page-name]] syntax in ## Relationships sections of entity pages. As of 2026-07-15, all 33 entity pages with Relationships sections use typed syntax. The relationship type vocabulary is maintained in _schema.md.

Syntax

## Relationships
 
- "created" [[llm-wiki]] — Originator of the LLM Wiki pattern
- "implements" [[agent-memory-systems]] — Strongest memory-systems implementation
- "contradicts" [[rag]] — Graph traversal beats keyword search at scale

Usage

  • The scripts/wikilint.ps1 Check 10 validates that all typed relationships use recognized types from the vocabulary
  • The scripts/mcp-server.py endpoint GET /relationships/{slug} exposes typed edges programmatically
  • The _schema.md ## Typed Relationship Types section defines the canonical vocabulary
  • All 18 recognized types are in active use across entity pages

Graph traversal for queries becomes possible: when asked “what’s the impact of upgrading Redis?”, the LLM starts at the Redis node, walks outward through “depends on” and “uses” edges, and finds everything downstream. This catches connections that keyword search misses.

Implications

Typed relationships make the knowledge graph computationally useful — not just visually navigable. The trade-off is maintenance cost: typed relationships require more effort during ingest to classify each connection. For vaults under 100 pages, bare wikilinks likely suffice; typed edges become valuable at scale when automated graph traversal saves more time than the extra classification costs.

Explicit Graph Layer

Some implementations add an explicit graph layer alongside the implicit wikilink graph. The praneybehl/llm-wiki-plugin, for example, outputs graph data in multiple formats:

  • nodes.jsonl — all pages as nodes with metadata
  • edges.jsonl — all wikilinks as edges with source/target
  • graph.sqlite — queryable SQLite database of the graph
  • graph.graphml — standard graph exchange format for external tools (Gephi, Neo4j, etc.)

These formats enable graph algorithms (centrality, community detection, path finding) and visualization beyond Obsidian’s built-in graph view. Systems like denser-ai extend this approach with production-grade graph compilation. For this vault at 37 pages, the implicit wikilink graph suffices; an explicit layer would become useful beyond 100+ pages for navigation and gap analysis.

Connection Methods

Different tools create and maintain the knowledge graph differently. The connection-methods comparison analyzes five approaches — from Karpathy’s original lint checks to graph/RAG layers for scaling retrieval. Each method changes how edges (wikilinks) are created, validated, and consumed.

  • llm-wiki — The LLM Wiki pattern builds a knowledge graph through wikilinks
  • obsidian — Obsidian’s graph view visualizes the knowledge graph
  • second-brain — The knowledge graph is the structural backbone of an AI second brain
  • connection-methods — Five methods for creating and maintaining graph connections
  • llm-wiki-vs-memory-and-graph-rag — larger comparison that includes LLM Wiki.
  • cognee — production knowledge-graph memory engine (633 nodes / 1090 edges)
  • rightmemory — tree+graph coding-agent memory with typed edges
  • swarmvault — local-first LLM Wiki + knowledge graph service
  • danvega-karpathy-wiki — JVM implementation that emits an explicit backlinks.md
  • graphify — 85.8k⭐ folder→graph skill with EXTRACTED/INFERRED edge tags

Open Questions

  • At what vault size (page count) does the graph layer become more useful than wikilink-based navigation? Sources describe both approaches but don’t provide heuristics for the transition point.
  • Does explicit graph construction (nodes.jsonl, edges.jsonl) add value beyond what’s already captured by [[wikilinks]] in the markdown files? The graph formats suggest not — they read from the same source of truth.
  • When should an agent prefer the graph SQLite DB over a direct [[wikilinks]] grep for retrieving relationships? No source addresses this operational question.

^[raw/articles/google-okf-spec.md] (L3 Compiled requires gaps surfaced)

Sources

^[raw/articles/genai-unplugged-llm-wiki.md]

Visão de gráfico

Backlinks