Andrej Karpathy's conceptual model for an "LLM Wiki" is moving from whiteboard theory to code. A developer known as Kell published a detailed breakdown on DEV.to of how they implemented Karpathy's three-part framework—preserved sources, related pages, and agent guidance documents—within an Obsidian-based workflow. The project, dubbed "Cereja Flamejante," aims to solve the persistent problem of maintaining consistent context for AI agents across complex technical research without dumping entire knowledge bases into limited context windows.

From Theory to SHA-256 Hashes

Kell's implementation diverges from simple file storage by introducing rigorous provenance tracking. The ingestion command calculates a SHA-256 hash of each source file, embedding it directly into the note's filename. This ensures that if a document's bytes change, the system detects it immediately, preventing silent corruption of source truth. Unlike automated watchers, the system relies on explicit commands to trigger ingestion, a choice Kell made to maintain control over the knowledge pipeline. The metadata schema is equally strict: notes begin in a 'draft' state with fields like 'certainty: unverified' and 'extraction_status: not_attempted,' forcing human review before any content becomes canonical knowledge for the agents.

The Human-in-the-Loop Gatekeeper

The architecture explicitly separates machine generation from human approval. While the LLM can generate syntheses and reference specific pages from PDFs (processed via Poppler's pdftotext), it cannot promote a note to 'stable' status. A check in the system rejects any stable note attributed solely to a model, requiring a named human responsible party. This addresses the hallucination risk inherent in RAG systems: the wiki stores knowledge, but the agent only uses what has been vetted. Kell notes that while RAG (Retrieval-Augmented Generation) is useful for fetching snippets, the organizational structure of the wiki serves a different, complementary function—curating the *quality* of the context rather than just its availability.

Portability and the Open Knowledge Format

The project also engages with the Open Knowledge Format (OKF) v0.1, a proposal from Google Cloud that standardizes knowledge representation in Markdown with YAML metadata. Kell sees OKF as a potential bridge to make this Obsidian-based wiki portable across different agent frameworks and tools. However, the developer cautions that compatibility isn't automatic; the current implementation uses custom fields for provenance and rights management that don't yet map cleanly to the OKF spec. The goal is to decouple the knowledge base from the interface, allowing the same structured data to serve both human readers in Obsidian and autonomous agents via API.

Key Takeaways

  • Provenance is Primary: The first step in the pipeline is recording where data came from (URL, hash, author), not summarizing it. Extraction and synthesis are deferred until after this audit trail is established.
  • Explicit Over Implicit: There are no file watchers or scheduled tasks. Ingestion is a deliberate command, preventing accidental knowledge pollution from transient files.
  • Human Authority is Hard-Coded: The system technically prevents LLMs from self-promoting content to 'stable' status, enforcing a human review gate for all canonical knowledge.
  • Context ≠ Knowledge: The wiki is the long-term store; the agent's context window is the short-term workspace. The system is designed to fetch only the necessary, vetted subset of the wiki for each task.

The Bottom Line

Most 'LLM memory' projects fail because they treat the context window as a database. Kell's implementation gets it right by treating the wiki as a source of truth that requires human verification before it ever touches the model. It’s a slow, boring, and correct way to build agent knowledge.

Technical Reality Check

The current build (PR #34) is minimal. It handles file hashing and metadata creation but lacks automated PDF extraction or synthesis. Kell admits that OCR and automatic monitoring are future needs, not current features. The system passed two new tests, though an existing bug in the 'Flame' library related to Windows path separators caused a suite failure. This is a foundational layer, not a finished product, but the architectural decisions—specifically the separation of ingestion, verification, and synthesis—offer a robust template for anyone building agentic workflows today.