Knowledge Graph

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.

Graphing a Reasoning Trace Instead of a Corpus

Every graph tool catalogued above builds its graph from documents — pages, sources, a codebase. local-knowledge-graph inverts the direction: it graphs a local model’s reasoning steps, one node per step, produced while answering a single question. The corpus is the model’s own thinking, and the graph exists because the reasoning happened, not because a corpus was indexed.

Two properties of that graph are worth carrying over regardless of what is being graphed.

Edges are typed by how they were established, not only by what they mean. Blue edges are embedding similarity — association. Green edges are what an exact evaluator settled, computed in fractions. The colour is the provenance of the connection, so a reader can see which links were checked and which are merely plausible. This is the same axis graphify exposes with its EXTRACTED versus INFERRED edge tags, and the same distinction attested-computation formalises in OKF v0.2 — three independent arrivals at the idea that an edge’s epistemic status deserves to be a first-class property.

“Strongest path” is exactly solvable, not heuristic. The path maximises the product of similarities along it, equivalent to minimising a sum of -log(similarity); those costs are non-negative, so Dijkstra returns the optimal path, and the reported score is the geometric mean of its edges.

Implications: This vault’s graph layer answers proximity questions — graph_neighbors, community detection — but nothing answers how two pages connect and how strongly, and every wikilink is rendered identically whether it was drawn from a source or inferred by an agent. A scored strongest path and an edge-provenance property are both additive to the existing wiki/graph/ export rather than replacements for it, and the second one costs almost nothing: the information already exists at ingest time and is simply discarded. It also sharpens the first Open Question below — the useful threshold may not be page count at all, but whether anyone needs to ask path-shaped questions.

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.

Knowledge Graphs as Controlled Reasoning Tasks

The paper Loop, Think, & Generalize uses a directed knowledge graph as a controlled test bed for implicit reasoning: nodes represent entities, edges represent atomic relations, and a multi-hop query asks the model to infer the final node from a starting node plus a relation sequence. This turns graph traversal into a measurable composition problem rather than only a storage or navigation structure.

The setup also separates two kinds of generalization. Systematic generalization tests combinations of known atomic facts that were never composed during training. Depth extrapolation tests whether the model can apply the same rule to longer paths than those seen during training. Recurrent-depth transformers performed better than vanilla transformers in the reported synthetic experiments, but the paper explicitly limits the result to one small-scale family of tasks.

Implications: A knowledge graph can serve not only as a retrieval substrate but also as a controlled evaluation environment for composition. This is useful for separating “the model knows the facts” from “the model can combine the facts,” while avoiding the stronger claim that synthetic graph performance automatically transfers to real-world reasoning.

Related Concepts

• 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)
• semantica — graph-native context-graph infrastructure with W3C PROV-O provenance and decision intelligence
• 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
• local-knowledge-graph — graphs a reasoning trace rather than a corpus; typed edge provenance and an exactly-solvable strongest path
• gitnexus — codebase→graph engine that precomputes clusters, traces, and confidence at index time so agents get complete context in one MCP call
• implicit-reasoning — composes graph-stored facts without an explicit chain-of-thought
• recurrent-depth-transformers — reuses transformer layers to perform iterative graph-like composition

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)

External Links

• https://github.com/punnerud/Local_Knowledge_Graph

Sources

^[raw/articles/genai-unplugged-llm-wiki.md] ^[raw/transcripts/sozai-fable-llm-wiki-video.md] ^[raw/external/github-com-local-knowledge-graph-0793437a.md]