LLM Wiki — Synaptic Lattice

Connection Methods for LLM Wikis

Properties1
tagscomparison, llm-wiki, workflow, guardrail, architecture

Leitura de 5 min

Connection Methods for LLM Wikis

Five distinct methods for creating and maintaining connections between wiki pages, extracted from the raw source corpus. Each addresses a different part of the problem: how to create links, how to keep them healthy, and how to scale them.

Method 1: Karpathy Lint (Origin)

Sources: karpathy-llm-wiki-gist.md, venturebeat-llm-wiki.md

The original gist defines three lint checks that govern connection health:

  • Broken links — wikilinks pointing to non-existent pages
  • Orphan pages — pages with zero inbound links
  • Contradictions — conflicting claims across pages

The LLM creates wikilinks (backtick-wrapped syntax) during ingest. The lint pass runs after each batch to verify the graph is intact. No external tooling required.

Effectiveness: Foundational but manual. Catches problems after they exist.

Method 2: Wyndo Production Guardrails

Sources: genai-unplugged-llm-wiki.md

Four guardrails from a production LLM Wiki that prevent connection degradation:

  1. Link cap (5-8 per page) — prevents hub pages from accumulating too many connections and becoming single points of navigation
  2. Twice-referenced rule — entity pages created only after 2+ mentions, preventing noise pages
  3. Forward-only linking — ingest never retroactively adds links to old pages, bounding the cost of each batch
  4. Edit ceiling (2-5 pages per ingest) — limits how many existing pages are updated per batch

Effectiveness: Proactive prevention. The link cap is especially effective at maintaining graph quality as the wiki grows.

Method 3: Wikilint CLI

Sources: levelup-llm-wiki-deep-dive.md

Oleg Ivanchenko’s Go CLI tool that enforces structural invariants:

  • No orphan pages (pages with no inbound links)
  • No broken wikilinks
  • No duplicate slugs
  • Each page has exactly one H1, a Summary, and a Sources section

Each batch must pass wikilint: OK before being considered complete.

Effectiveness: Automated enforcement. The most rigorous method but requires a specific tool. Catches structural issues that manual review misses.

Method 4: OKF Consumer Tolerance

Sources: google-okf-spec.md

The OKF v0.1 draft specifies that consumers MUST NOT reject a bundle for:

  • Broken cross-links
  • Missing index.md
  • Unknown frontmatter keys or type values

This is a baseline tolerance level, not a prohibition on stricter local governance. A vault can lint for these conditions as local quality rules without violating the format.

Effectiveness: Resilient design. Tolerates errors gracefully rather than breaking entirely. Pairs well with local lint.

Method 5.5: Typed Relationships (Edge Semantics)

Sources: llm-wiki-v2-rohitg00-2026.md, _schema.md, wiki/concepts/knowledge-graph.md

This vault extends bare wikilinks with typed relationship syntax in ## Relationships sections of entity pages. Instead of:

- [[llm-wiki]] — Originator of the pattern

Each bullet carries a relationship type:

- "created" [[llm-wiki]] — Originator of the pattern

The type vocabulary (18 types across 5 categories) is defined in _schema.md and validated by scripts/wikilint.ps1 Check 10. The scripts/mcp-server.py exposes two typed relationship endpoints.

Effectiveness: Low overhead for human editors, machine-parseable, works alongside existing untyped wikilinks. Best for vaults that want to pilot typed edges without adding an explicit graph layer.

Method 5: Graph/RAG Layer (Future Scale)

Sources: LightRAG paper, HippoRAG papers/2, deep research report, Denser.ai analysis

Graph-enhanced systems that could supplement wikilinks at scale:

  • LightRAG — builds a knowledge graph from entities and relations, supports dual-level retrieval and incremental graph updates
  • HippoRAG — uses hippocampal indexing theory with Personalized PageRank for multi-hop associative retrieval
  • GraphRAG — graph/community summaries for global questions over private corpora

These are retrieval layers, not link-creation methods. They become useful when the wiki outgrows manual index.md navigation.

Effectiveness: High potential, heavy infrastructure. Premature for a small vault. Best added after the artifact-first approach proves value.

Comparison Matrix

| Dimension | Karpathy Lint | Wyndo Guardrails | Wikilint CLI | OKF Tolerance | Typed Relationships | Graph/RAG Layer | |---|---|---|---|---|---|---|---|---| | What it does | Checks health | Prevents decay | Enforces structure | Allows errors | Adds edge semantics | Scales retrieval | | When applied | Post-ingest | During ingest | Post-ingest | At consumption | During ingest | Query time | | Automation | Manual | Procedural | CLI tool | Specification | Manual + lint check | Software | | Link creation | LLM during ingest | LLM with limits | Validates only | Tolerates any | LLM assigns types | Infers new links | | Catches orphans | Yes | Indirectly (link cap) | Yes | No | No | No | | Best for | Small vaults | Medium vaults | Any vault | Interop | Entity-heavy vaults | Large vaults |

Our vault uses Methods 1+2+4+5.5 (Karpathy lint + Wyndo guardrails + OKF tolerance + Typed Relationships). The wikilint (Method 3) is implemented as scripts/wikilint.ps1 and runs with every batch, including Check 10 for typed relationship validation.

  • lint — the lint operation that checks connection health, now validates typed relationships
  • knowledge-graph — the emergent graph from wikilinks, now supports typed edges
  • ingest — the process that creates links between pages
  • rule — guardrails that govern connection quality
  • llm-wiki — the pattern that produces interlinked pages
  • _schema.md — relationship type vocabulary

Sources

^[raw/articles/karpathy-llm-wiki-gist.md] ^[raw/articles/genai-unplugged-llm-wiki.md] ^[raw/articles/levelup-llm-wiki-deep-dive.md] ^[raw/articles/google-okf-spec.md] ^[raw/articles/venturebeat-llm-wiki.md]

Visão de gráfico

Backlinks