The Architecture of Canonical AI Memory: Integrating Knowledge Graphs, LLM Wikis, and UAI-1 Specifications

Full report

On this page

The Epistemological Crisis of Stateless Artificial Intelligence

The rapid proliferation and deployment of Large Language Models (LLMs) have exposed a profound structural deficit in contemporary artificial intelligence architectures: the reliance on stateless, ephemeral memory systems. Traditional operational paradigms approach knowledge retrieval through mechanisms where the machine is forced to rediscover, re-contextualize, and synthesize complex domain information from scratch during every single computational interaction.1 As models scale to encompass enterprise-wide deployments, multi-agent workflows, and highly technical research environments, this localized approach to memory leads to severe token inefficiency, compounding logical inconsistencies, and the catastrophic decay of reasoning over prolonged operational periods.1 The underlying problem is that transformer architectures, while highly adept at localized pattern recognition within a given context window, lack an inherent capability to permanently accrue and compound knowledge in a structured, deterministic format.3

To resolve these inherent limitations, the paradigm of Canonical AI Memory has been formalized. Canonical AI Memory moves beyond fragmented Retrieval-Augmented Generation (RAG) by instituting a persistent, continuously compounding cognitive infrastructure.1 It represents a formalized, machine-consumable, and concurrently human-readable storage layer that maintains an evolving, verifiable state of organizational and domain-specific knowledge.5 This structural paradigm is achieved through the sophisticated integration of three distinct technological frameworks. First, LLM Wikis serve as the durable, markdown-based knowledge repository.1 Second, Knowledge Graphs (KGs) overlay this textual base, mapping topological relationships and enabling programmatic structural reasoning.2 Finally, the UAI-1 (User-AI) Specification provides the rigorous schematic boundaries necessary for establishing trust, maintaining verifiable evidence ledgers, and executing portable agent handoffs across diverse operational environments.5 The intersection of these technologies facilitates a fundamental transition from reactive, query-bound AI tools to proactive cognitive architectures capable of self-healing, deterministic retrieval, and advanced cross-domain synthesis.8

Deconstructing the Limitations of Retrieval-Augmented Generation

The dominant methodology for augmenting LLMs with external knowledge is standard Retrieval-Augmented Generation (RAG). RAG systems operate on a highly lossy and inherently episodic mechanism.1 When a query is initiated, the system converts the natural language input into a high-dimensional vector embedding, searches a database for mathematical cosine similarities, and retrieves localized chunks of text for the LLM to process in real-time.10 While this methodology proves effective for isolated fact retrieval and basic question-answering applications, it systematically collapses under the weight of complex, multi-hop reasoning requirements.1

Because the LLM does not possess a persistent understanding of the overarching domain topology—relying solely on the fragmented shards of text injected into its context window—it consistently fails to recognize underlying structural contradictions, gaps in the literature, or longitudinal shifts in the underlying data.2 The system performs the massive computational labor of synthesizing disparate information anew for every interaction, wasting token bandwidth and dramatically increasing the probability of hallucinations.1 Furthermore, relying entirely on semantic vector proximity often surfaces text that shares keywords but lacks true causal or logical relationships with the core inquiry.10 The architecture requires the LLM to act as a real-time sense-maker for disorganized data dumps, rather than allowing it to navigate a pre-compiled, logically consistent ontology.1

The LLM Wiki Paradigm: Compounding Knowledge Through Durable Architecture

The LLM Wiki architecture, initially conceptualized in foundational models by researchers such as Andrej Karpathy and subsequently expanded into robust enterprise frameworks, fundamentally reverses the RAG operational flow.1 Instead of merely retrieving raw document fragments dynamically at query time, the AI system compiles and maintains a persistent, heavily interlinked collection of structured markdown files.1 The computational effort of synthesis is intentionally front-loaded to an ingestion phase, operating under the principle that knowledge must be compiled once and queried infinitely.1

The Structural Hierarchy of the LLM Wiki

The sustainability of an LLM Wiki depends on a rigid directory structure that enforces a strict separation of concerns between raw evidence and derived synthesis.3 This hierarchical framework prevents the corruption of primary sources while providing the LLM with a dedicated cognitive workspace.

The canonical architecture consists of several critical layers:

1. The Raw Evidence Layer (raw/): This directory serves as an immutable repository for all primary source materials, including raw datasets, academic papers, competitive intelligence reports, and meeting transcripts.3 The AI agent maintains strictly read-only access to this layer. This ensures that the foundational evidence remains untampered and cryptographically verifiable, providing an anchor against which downstream LLM hallucinations can be audited.6
2. The Active Synthesis Layer (wiki/): This directory constitutes the active cognitive workspace owned and maintained by the LLM. It contains derived entity pages, conceptual summaries, systemic models, and synthesized records.1 Pages within this directory are densely interconnected using standard \[\[wikilinks\]\], a syntax that allows both human operators and language models to navigate the corpus natively and understand immediate topological relationships.3
3. The Output and Task Layer (output/, todos/): A dedicated destination where the model stores generated insights, interaction logs, formulated research hypotheses, and prioritized analytical tasks.3
4. The Schematic Configuration Layer (CLAUDE.md, AGENTS.md): These vital configuration files govern the explicit behavior of the AI agent. They dictate strict naming conventions, formatting rules, and standard operating procedures for editing the wiki.1 These configuration files are essential because they transform a generic, highly compliant language model into a disciplined, domain-aware knowledge architect that resists the urge to bypass formatting protocols.1

The Autonomous Maintenance Lifecycle

A static repository of files rapidly decays into obsolescence. The LLM Wiki averts this fate through an autonomous maintenance loop consisting of Ingest, Query, and Lint operations.1

During the ingestion phase, the addition of a single new document triggers a sophisticated cascade of asynchronous updates.1 The LLM reads the source material and extracts novel concepts.1 It does not simply create a new summary file; rather, it traverses the existing wiki, updating multiple entity pages to reflect the new data, strengthening prevailing theories, and explicitly flagging any contradictions between the new source and the existing repository.1 A single document ingestion may necessitate modifications across ten to fifteen different markdown files to ensure absolute consistency across the entire network.1

The "Lint" operation serves as an automated health check where the system actively hunts for structural degradation.1 Operating on a scheduled cadence (e.g., via cron jobs or background agents), the model scans the entire corpus to identify orphan pages—nodes that possess no incoming links, indicating that the knowledge base has grown around them without properly integrating their insights.16 Furthermore, the linting process flags stale claims that have been logically superseded by newer data and identifies unresolved contradictions.1 This continuous pruning ensures that the knowledge base compounds in value rather than collapsing under its own unmanaged weight, effectively solving the primary failure mode of human-maintained corporate wikis.15

The LLMWikis.org Strategic Guide for Organizational Implementation

Transitioning from personal note-taking experiments to enterprise-grade AI memory requires profound operational standardization. The LLMWikis.org framework provides the canonical public architecture designed to ensure that organizational knowledge remains durable, citable, and operationally safe for autonomous agent consumption.6 The strategic guide explicitly addresses the failure patterns of initial AI deployments—such as context loss, stale documentation, and the ingestion of unverified intelligence—by enforcing a rigorous "structured knowledge flow".6

Memory Shapes and Contextual Delivery Mechanisms

The LLMWikis.org strategic guide heavily emphasizes the architectural distinction between differing "memory shapes." Organizations frequently fail when they attempt to use a single memory paradigm for disparate operational requirements.7 The standard delineates memory into specialized shapes based on computational function:

Implementing the Trust Model and Metadata Standardization

To prevent AI systems from hallucinating based on deprecated, speculative, or unverified data, the LLMWikis.org standard mandates a strict Trust Model integrated directly into the markdown frontmatter.6 Every entity page, systemic model, and synthesized document must carry an explicit epistemic status label.6

The primary trust labels include "Authoritative," indicating the data has been human-reviewed, cross-verified, and is entirely safe for autonomous execution; "Draft," indicating the file is currently under construction by the LLM or awaiting human validation; "Proposal," which identifies generated structural changes or hypotheses staged for future approval; and "Historical/Deprecated," which ensures legacy data is maintained for referential integrity but is strictly flagged to prevent the AI from utilizing the data for active reasoning.6

This Trust Model is enforced via a rigid Metadata Standard.7 The standard requires all wiki pages to possess agent-readable YAML frontmatter detailing source traces, identified contradictions, ownership identity, and the exact timestamps of the last LLM verification.6 This schematic requirement forces the AI agent to evaluate the epistemological weight and freshness of a document before utilizing it in a workflow, eliminating the danger of an agent executing a critical task based on obsolete instructions.6

Agent Interaction Protocols and Operational Boundaries

Autonomous agents operating within the LLM Wiki framework are governed by strict interaction protocols. These rules are fundamental to preventing systemic degradation and ensuring operational security 6:

First, agents must adhere to a strict routing protocol. They are programmatically forbidden from blindly searching the file system or executing arbitrary global queries.6 Instead, they are instructed to begin their execution at root discovery files such as index.md, llms.txt, or sitemap.xml.6 By traversing the index first, the agent interprets the overarching topology of the repository before routing to the smallest, most relevant subset of pages, dramatically conserving context tokens.6

Second, agents operate under a strict citation mandate.7 When generating outputs or executing actions, agents must anchor their reasoning using durable page links (wikilinks) that point back to the local evidence contained within the repository.6 Relying on private, ephemeral chat memory or pre-trained parametric knowledge is explicitly penalized by the system prompts.7

Third, to prevent "single-pass drift"—the gradual accumulation of errors through unsupervised LLM writing—agents must follow a two-step ingest pipeline.7 The agent analyzes the raw source, stages the proposed changes in a temporary output file or flags them as a "Proposal," and only commits the update to the durable wiki after human review or automated secondary validation.7 This ensures that the canonical layer remains pristine.

Finally, agents must possess programmatic safety constraints and hard stopping boundaries. If an agent encounters missing data, contradictory evidence, missing permissions, or files tagged with explicit risk boundaries (such as unredacted PII or secret keys), it must immediately halt execution and escalate the query to a human operator.7

Knowledge Graphs: The Topological Engine of Artificial Reasoning

While the LLM Wiki provides excellent textual synthesis and human readability, markdown files remain structurally flat.18 A language model reading a directory of text files relies entirely on linear text parsing to understand systemic relationships. This approach becomes computationally prohibitive and highly inefficient as the corpus scales to encompass thousands of documents, repositories, and raw data feeds.3 To achieve true structural reasoning, the markdown files must be translated into a mathematical graph.3

The integration of Knowledge Graphs into the LLM Wiki workflow transforms isolated documents into a queryable, multi-dimensional topology.19 In this architecture, each markdown page represents a node, and every \[\[wikilink\]\] or explicitly stated semantic connection represents an edge.3 This enables the application of formal graph theory to unstructured human knowledge.

Ontological Implementation via InfraNodus

The implementation of this ontological layer follows stringent operational rules, frequently leveraging specialized network analysis tools such as InfraNodus.3 The knowledge graph is maintained in a strictly controlled directory, defined as the infranodus/ folder, which resides at the root level of the LLM Wiki project.21

All graph data and ontology files are stored at the root of the infranodus/ directory without nested subfolders, ensuring rapid programmatic indexing by the LLM.21 Furthermore, the system enforces a policy of incremental appending.21 The ontology files are treated as highly curated, compounding artifacts that capture intense domain nuance.21 Consequently, the AI agent is strictly forbidden from regenerating these ontology files from scratch.21 When new relations are extracted during the ingest phase, the model must read the existing ontology file and incrementally append the new connections. It is directed to match existing casing, entity naming conventions, and relationship tag styles exactly to prevent the bifurcation of unified concepts.21 Edges are defined using consistent relationship codes and wikilinks to ensure absolute machine readability across disparate modeling frameworks.21

Structural Gap Analysis and the Discovery of Blind Spots

The most profound cognitive capability unlocked by graph integration is structural gap analysis.3 Standard LLMs are notoriously poor at identifying "unknown unknowns." They can fluently summarize information that is present within a context window, but they fundamentally struggle to articulate what information is logically missing.2

By rendering the knowledge base as a topological network using network analysis algorithms, the system calculates node centrality, graph density, and modularity.3 This mathematical visualization instantly highlights structural "blind spots": conceptual clusters that exist robustly within the database but lack connective edges to other relevant domains.3

For example, the gap analysis algorithm might identify robust, dense clusters around "Regression Analysis" and "Market Flow Dynamics," but note a complete absence of edges connecting the two concepts.3 Instead of prompting the LLM with generic, open-ended inquiries, the user—or an autonomous sub-agent—feeds this exact structural deficiency into the reasoning engine, commanding the model to "bridge the gap" between the isolated clusters.3 This shifts the AI from a passive information retrieval tool into an active, self-evolving research collaborator capable of genuine, structurally-guided insight generation.3

GraphRAG Mechanisms and Token Efficiency

The synthesis of Knowledge Graphs and retrieval pipelines yields GraphRAG, a methodology that fundamentally outperforms semantic vector search in complex reasoning tasks.4 Vector databases map text snippets as high-dimensional coordinates, retrieving chunks based on spatial proximity in the embedding space.10 However, spatial proximity does not equate to logical, causal, or hierarchical relationships.10

GraphRAG circumvents this limitation by traversing the curated ontological edges.4 When a complex query is submitted, the system locates the optimal entry nodes based on keyword or initial vector matching, and then systematically traverses the neighboring relationships, retrieving a highly contextualized, logically coherent subgraph.4

The mathematical advantage of GraphRAG can be conceptually modeled as a hybrid retrieval probability, merging semantic similarity with topological importance.11 This hybrid approach yields superior context assembly, drastically reducing token consumption. Instead of flooding the context window with hundreds of loosely related text blocks—which triggers the "lost in the middle" phenomenon common to large context window LLMs—the system feeds the LLM only the specific, mathematically proven pathways required for reasoning.10 In large enterprise repositories or vast software codebases, this graph-driven approach can reduce token costs by up to 70x while simultaneously driving a dramatic increase in factual accuracy and logical consistency.24

Tooling, Ecosystem Integration, and Visual Interfaces

The theoretical architecture of Canonical AI Memory relies on a burgeoning ecosystem of open-source tools, integrated development environments (IDEs), and specialized plugins that bridge the gap between human visualization and machine computation.25

The Obsidian Ecosystem and Visual Graph Interfaces

Obsidian frequently serves as the primary integrated development environment (IDE) for human operators interacting with the LLM Wiki.1 Because the entire repository is composed of standard markdown files and wikilinks, Obsidian natively renders the knowledge graph, allowing humans to visually explore the topology that the AI is constructing.1

Advanced deployments utilize plugins such as the Graph Explorer Base View, which overcomes the limitations of standard flat-file browsing.18 This visualization layer allows users to render any subset of the wiki as an interactive force-directed graph.18 Nodes can be dynamically colored based on the LLMWikis.org metadata—such as confidence levels, maturity status, or unexplored frontier nodes.18 This enables a visual "Maturity Pipeline" tracking system, where human operators can instantly see which areas of the wiki are mere stubs generated by the LLM and which have graduated into mature, authoritative permanent notes.18

Furthermore, the Dataview plugin allows users to run SQL-like queries over the YAML frontmatter embedded by the LLM.14 A user can execute a query to instantly surface all concepts where the LLM marked its own confidence as "low," creating an immediate, actionable task list for human verification.16 Tools like Marp further extend this capability, allowing the programmatic generation of presentation slide decks directly from the validated wiki content.14

The Model Context Protocol (MCP) and Programmatic Execution

To fully orchestrate the triad of LLM Wikis, Knowledge Graphs, and external data sources, modern cognitive architectures heavily rely on the Model Context Protocol (MCP).3 The MCP serves as a universal interface, standardizing how LLMs interact with local filesystems, external databases, and specialized analytical engines.3

By deploying specialized MCP servers—such as the InfraNodus MCP server for text network analysis or the OpenTrace MCP server for software architecture graphs—developers grant the LLM persistent, programmatic access to the domain ontology.3

In programmatic execution modes, AI agents running in terminal environments (e.g., Claude Code, OpenClaw, or Aico-CLI) query the MCP server via standard API calls.12 For example, when an agent is tasked with architecting a new software module, it queries the OpenTrace graph to understand systemic dependencies.19 The MCP server traverses the typed relationship edges and returns a deterministic response.19 The agent receives an exact dependency chain, preventing it from hallucinating non-existent microservices or suggesting code modifications that would inadvertently trigger downstream failures.19

Other critical ecosystem tools include QMD, a local search engine for markdown files that utilizes hybrid BM25 and vector search with LLM re-ranking, and schema-first extraction tools like GLiNER2, which ensure that named entities are harvested with absolute structural consistency before being committed to the wiki.16

The UAI-1 Specification: Assertion Boundaries and Portable Agent Handoffs

While LLMWikis.org governs the internal structuring and local maintenance of organizational knowledge, the transmission, validation, and inter-agent exchange of this knowledge across distributed networks require an entirely different level of cryptographic and schematic rigor. This external integration domain is governed by the UAIX.org registry and the UAI-1 (User-AI) Specification.5

Establishing the UAI-1 Architecture

The UAI-1 Specification operates as the canonical public message standard designed specifically for structured AI-to-AI communication.5 It functions as a highly portable evidence and handoff layer for agentic systems that require a reviewable, mathematically verifiable public record of operations.5

Unlike generalized protocols that focus purely on establishing real-time host-client tool sessions, the UAI-1 specification defines AI memory as a long-term release-evidence record.5 It ensures that when an agentic workflow crosses runtime boundaries—such as moving from a secure enterprise internal system to a third-party vendor's autonomous agent—the identity of the source, the continuity of the workflow, and the conformance evidence travel seamlessly alongside the raw data payload.5 Downstream AI systems can react to this payload mechanically, understanding exactly what the data is, who verified it, and what operational constraints apply.5

The UAI-1 Canonical Memory Package Schema

A canonical AI memory package under the UAI-1 schema is generated using deterministic manifests and canonical templates, often initiated via a Package Wizard.5 The resulting Registry Output is assembled into a strict file hierarchy designed for maximum auditability, consisting of several mandatory components 5:

Assertion Boundaries and Epistemic Governance

The most critical innovation of the UAI-1 standard is the formal implementation of Assertion Boundaries.5 In standard, unbounded LLM workflows, conversational context is passed continuously, allowing unverified assumptions, hallucinations, and probabilistic errors to bleed freely between sessions and across agentic boundaries. The UAI-1 protocol forces the system to erect an explicit Assertion Boundary: the system must formally declare the epistemological state of the memory before it is permitted to cross a trust threshold.5

Before an AI memory package is exported or shared, the UAI-1 profile forces the generation of an Evidence Ledger.5 This ledger establishes strict Source Authority, defining exactly which human entity, database, or specific language model owns the absolute truth of the memory.5 It tracks the provenance of every data point contained within the package, logging precisely when and how the information was validated.5

Furthermore, the system establishes explicit Conflict-Resolution schemas.5 If an incoming UAI-1 memory package contradicts the receiving agent's internal LLM Wiki or existing knowledge graph, the system profile dictates pre-defined fallback actions.5 The agent knows exactly whether it is authorized to overwrite its local data, sandbox the incoming information for human review, or discard the packet entirely.5 All of these exchanges are secured by Validator-Backed Release Evidence, which utilizes checksum review expectations to guarantee that the context payload has not been intercepted, corrupted, or altered during the asynchronous handoff.5

Asynchronous Multi-Agent Coordination and the Honest Back-Channel

One of the primary strategic applications of the UAI-1 specification, operating in tandem with the LLM Wiki structure, is the execution of complex Project Handoffs.6 This is an advanced workflow designed to solve the immense friction of asynchronous coordination between disparate AI agents.32

In a multi-agent ecosystem, different LLMs operate in highly isolated sessions, frequently losing the broader context of the macro-task.32 Using the UAI-1 standard, agents can utilize a formal asynchronous dialogue thread.32 When an agent completes a specific sub-task, it compiles its working memory into a UAI-1 Startup Packet and deposits it into the Wiki.5 The Receiver Brief explicitly directs the next agent in the sequence on exactly where to resume operations and what assumptions to carry forward.5

To preserve operational transparency without corrupting the finalized Wiki pages, these multi-agent systems utilize an "honest back-channel".32 This is a separate, hidden directory where agents log their raw observations, execution failures, and probabilistic doubts without applying the diplomatic or instructional filtering required for the main wiki.32 This ensures that the canonical wiki voice remains authoritative and decisive, while the granular, operational debugging data remains fully accessible for future validators or human oversight teams.32

Advanced Cognitive Architectures and Stratification Engines

The most advanced implementations of Canonical AI Memory move entirely beyond the concept of a static repository, transforming the LLM Wiki and Knowledge Graph into a "living cognitive architecture" capable of autonomous self-healing and continuous learning.8 Experimental frameworks, such as the Nebula project, demonstrate how these components are synthesized into an active systemic mind.8

Memory Stratification and Heartbeat Optimization

State-of-the-art architectures incorporate automated heartbeat engines and Stratification Engines.8 Operating via scheduled chronological jobs, these engines continuously evaluate the knowledge graph and execute memory distribution operations based on temporal velocity and usage patterns 8:

• Layer 0-1 (Core Knowledge): High-frequency, recently validated, and foundational concepts kept in an active, immediately retrievable state.8
• Layer 2-3 (Working Memory): Moderately relevant contextual data utilized for ongoing reasoning tasks but not critical for core identity or basic operations.8
• Layer 4+ (Archival): Data points and edges where the decay rate exceeds predefined thresholds. These are automatically demoted to deep storage, optimizing the distribution of memory and preserving the speed of retrieval algorithms without permanently deleting historical records.8

Simultaneously, a Heartbeat Optimization Loop runs at fixed intervals (e.g., every five minutes) to conduct micro-maintenance.8 This loop scans for emerging logical contradictions introduced by concurrent agent operations, executes self-healing protocols to repair broken wikilinks, and initiates proactive curation.8 Proactive curation algorithms actively attempt to discover and register new associative links between seemingly disparate concepts, generating novel hypotheses and staging these connections as "Proposals" in the wiki for human review.8

Mitigating Plasticity Loss in Deep Learning Systems

This separation of computational reasoning from data storage provides a robust solution to one of the most persistent problems in deep reinforcement learning and continual model training: "loss of plasticity".30 Loss of plasticity occurs when a neural network is trained sequentially on shifting data distributions; over time, the network loses its ability to learn from new experiences, often due to a reduction in the curvature of the optimization landscape and the sparsification of the activation footprint.30

While internal mitigation strategies like Concatenated ReLUs (CReLUs) offer architectural relief, Canonical AI Memory solves the problem externally and definitively.34 By outsourcing the long-term, structured memory to a mathematically stable, externally maintained Knowledge Graph, the LLM is freed from the burden of internalizing endless, contradictory parametric updates via fine-tuning.1 The language model acts strictly as the reasoning engine; the Graph provides the persistent state.1 This separation of concerns guarantees absolute determinism in enterprise environments where parametric hallucination—caused by catastrophic forgetting or plasticity loss—is entirely unacceptable.15

Synthesis and Strategic Outlook

Canonical AI Memory establishes a highly sophisticated, interlocking technological triad. The LLM Wiki provides human-readable synthesis, strict metadata compliance, and durable file-based architecture. The Knowledge Graph overlays this foundation with structured, multi-hop topological reasoning capabilities, allowing the system to execute GraphRAG operations that drastically reduce token consumption and expose structural blind spots. Finally, the UAI-1 specification enforces cryptographic assertion boundaries, trust models, and verifiable evidence ledgers, ensuring that asynchronous agent handoffs occur securely and transparently.

Standard RAG architectures, constrained by the episodic and contextually shallow nature of vector embeddings, are mathematically and operationally insufficient for long-term, multi-agent enterprise deployments. By forcing the computational heavy lifting to an asynchronous ingest phase, organizing outputs into strict markdown schemas, and establishing explicit Assertion Boundaries before operational context is transferred, systems transition from reactive data retrieval tools into resilient, compounding cognitive architectures.

Organizations that master the deployment of Canonical AI Memory will construct information ecosystems that defy entropy. As new data is ingested, the system will seamlessly absorb contradictions, optimize its topological mapping, and serve as an impenetrable, fully auditable source of truth. The competitive advantage in artificial intelligence will no longer belong solely to entities possessing the largest parametric models, but to those possessing the most meticulously maintained, structurally coherent, and safely guarded cognitive architectures.

Works cited

1. LLM Wiki \- GitHub Gist, accessed May 6, 2026, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
2. Knowledge Graphs for LLM Reasoning: Build AI Ontologies \- InfraNodus, accessed May 6, 2026, https://infranodus.com/docs/knowledge-graphs-llm-reasoning
3. Supercharging LLM Wiki with Knowledge Graphs: Build a Self-Evolving Research System, accessed May 6, 2026, https://support.noduslabs.com/hc/en-us/articles/26724863249180-Supercharging-LLM-Wiki-with-Knowledge-Graphs-Build-a-Self-Evolving-Research-System
4. Graph RAG (Retrieval Augmented Generation): The Future of AI-Powered Search & Retrieval | by Tahir | Medium, accessed May 6, 2026, https://medium.com/@tahirbalarabe2/graph-rag-retrieval-augmented-generation-the-future-of-ai-powered-search-retrieval-578f016b6597
5. UAIX | UAI-1 Open Exchange Contract for AI Systems, accessed May 6, 2026, http://uaix.org
6. LlmWikis.org \- LlmWikis.org, accessed May 6, 2026, https://llmwikis.org/
7. LlmWikis.org \- LlmWikis.org, accessed May 6, 2026, http://llmwikis.org
8. llm-wiki \- GitHub Gist, accessed May 6, 2026, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink\_comment\_id=6110770
9. How Knowledge Graphs integrate with LLMs | by Panos Mitzias \- Medium, accessed May 6, 2026, https://medium.com/@pmitzias/how-knowledge-graphs-integrate-with-llms-f0388c026776
10. When Your AI Wiki Outgrows the Context Window — A Practical Guide to RAG, accessed May 6, 2026, https://dev.to/zaferdace/when-your-ai-wiki-outgrows-the-context-window-a-practical-guide-to-rag-kc2
11. GraphRAG vs Traditional RAG: Knowledge Graphs for Accurate, Enhanced RAG Applications | by Tahir | Medium, accessed May 6, 2026, https://medium.com/@tahirbalarabe2/graphrag-vs-traditional-rag-knowledge-graphs-for-accurate-enhanced-rag-applications-2cc4f6f9f4b4
12. Text processing — list of Rust libraries/crates // Lib.rs, accessed May 6, 2026, https://lib.rs/text-processing
13. llm-wiki \- GitHub Gist, accessed May 6, 2026, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink\_comment\_id=6099069
14. What is LLM Wiki Pattern? Persistent Knowledge with LLM Wikis | by Tahir \- Medium, accessed May 6, 2026, https://medium.com/@tahirbalarabe2/what-is-llm-wiki-pattern-persistent-knowledge-with-llm-wikis-3227f561abc1
15. llm-wiki \- GitHub Gist, accessed May 6, 2026, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink\_comment\_id=6109892
16. How to Build Karpathy's LLM Wiki: The Complete Guide to AI-Maintained Knowledge Bases, accessed May 6, 2026, https://blog.starmorph.com/blog/karpathy-llm-wiki-knowledge-base-guide
17. Your LLM Has Been Forgetting Everything — Karpathy's Wiki Pattern Is the Fix \- Medium, accessed May 6, 2026, https://medium.com/@mustafa.gencc94/your-llm-has-been-forgetting-everything-karpathys-wiki-pattern-is-the-fix-6931ad90017b
18. I Built a Graph Explorer for Obsidian Bases. Here's Why LLM Wikis Need a Visual Layer, accessed May 6, 2026, https://www.dsebastien.net/i-built-a-graph-explorer-for-obsidian-bases-heres-why-llm-wikis-need-a-visual-layer/
19. Giving Claude Code architectural context via a knowledge graph MCP (inspired by Karpathy's LLM Wiki) : r/ClaudeAI \- Reddit, accessed May 6, 2026, https://www.reddit.com/r/ClaudeAI/comments/1sgae0h/giving\_claude\_code\_architectural\_context\_via\_a/
20. DeveloPassion's Newsletter \#210 \- LLM Wikis \- Sébastien Dubois, accessed May 6, 2026, https://www.dsebastien.net/developassions-newsletter-210-llm-wikis/
21. skills/skill-llm-wiki/SKILL.md at master · infranodus/skills · GitHub, accessed May 6, 2026, https://github.com/infranodus/skills/blob/master/skill-llm-wiki/SKILL.md
22. RAG Tutorial: How to Build a RAG System on a Knowledge Graph \- Neo4j, accessed May 6, 2026, https://neo4j.com/blog/developer/rag-tutorial/
23. Knowledge graph \- Wikipedia, accessed May 6, 2026, https://en.wikipedia.org/wiki/Knowledge\_graph
24. Graphify for Claude Code: How a Karpathy-Inspired Knowledge Graph Cuts Large Codebase Costs by 70x | MindStudio, accessed May 6, 2026, https://www.mindstudio.ai/blog/graphify-claude-code-knowledge-graph-large-codebase-70x
25. llm-wiki \- GitHub Gist, accessed May 6, 2026, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink\_comment\_id=6102777
26. What Is Andrej Karpathy's LLM Wiki? How to Build a Personal Knowledge Base With Claude Code | MindStudio, accessed May 6, 2026, https://www.mindstudio.ai/blog/andrej-karpathy-llm-wiki-knowledge-base-claude-code
27. Your OpenClaw agents can now build and maintain their own Karpathy-style LLM wiki. Markdown files, git history, no cloud. : r/clawdbot \- Reddit, accessed May 6, 2026, https://www.reddit.com/r/clawdbot/comments/1stfljb/your\_openclaw\_agents\_can\_now\_build\_and\_maintain/
28. Schema-First Extraction for LLM Wikis with GLiNER2 · VeriStamp Blog, accessed May 6, 2026, https://blog.veristamp.in/blog/schema-first-llm-wiki/
29. for Tod \- DTIC, accessed May 6, 2026, https://apps.dtic.mil/sti/tr/pdf/ADA221717.pdf
30. Marlos C. Machado \- University of Alberta, accessed May 6, 2026, https://webdocs.cs.ualberta.ca/\~machado/publications\_year.html
31. UnifAI Network (UAI) price Prediction \- Bitget, accessed May 6, 2026, https://www.bitget.com/price/unifai-network/price-prediction
32. AEVYRA/llm-wiki-coordination \- GitHub, accessed May 6, 2026, https://github.com/AEVYRA/llm-wiki-coordination
33. llm-wiki \- GitHub Gist, accessed May 6, 2026, https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f?permalink\_comment\_id=6109395
34. Marlos C. Machado \- University of Alberta, accessed May 6, 2026, https://webdocs.cs.ualberta.ca/\~machado/publications/research.html