Setting up my Digital Brain Karpathy Wiki with RAG system and local DB, running on local models

I’ve kept a Carbon Interface journal on GitHub every year since 2015: logs of whatever I was learning or stuck on that year. Eleven years of it now. The writing was never the problem; finding anything again was. “Didn’t I already fight this exact Postgres indexing problem in 2022?” Probably! No way to know without grepping eleven years of repos by hand.

2026 is the year I stopped accepting that. I found Nate Jones’ Open Brain (OB1) project: the pitch is that your notes app should be a database with vector search underneath it, not a database quietly hiding behind a notes app, and I used it as the skeleton for turning this year’s vault into something that can actually answer questions about itself.

Brain Architecture

Claude Code talks to the whole thing through a local MCP server, so day to day I just ask it to search or capture something instead of opening a SQL client.

The one rule that matters more than any of the code: the database is the source of truth, the wiki is a build artifact. This is straight from Karpathy’s LLM-wiki idea: treat the wiki as an emergent, regenerable view over atomic state, not a thing you edit directly. I broke this rule for myself exactly once, hand-edited a wiki page to make a demo look nicer, and the next nightly compile silently overwrote it. Lesson learned the annoying way.

Going fully local

Stock OB1 assumes you’re comfortable sending your notes out to OpenAI or OpenRouter for embeddings, billed per call. I wanted this local, partly cost, mostly because eleven years of “what I was stuck on and why” isn’t something I want living on someone else’s inference endpoint by default. So:

• 1024-dim vectors via local Ollama (mxbai-embed-large) instead of 1536-dim OpenAI embeddings. Not interchangeable: switching embedding models later means re-embedding the entire table, no partial migration.
• The MCP server runs as a local stdio process, not a cloud edge function, because an edge function has no way to reach a model running on my own machine.
• Entity extraction and edge classification run as local scripts: the upstream versions of those workers call out to cloud LLMs by default.
• A nightly job checks whether Ollama is actually running and starts it if not. Past me forgot to leave it running more nights than I’d like to admit, and woke up to a failed log instead of an updated wiki.

Scheduling automations

A scheduled job runs every night: import whatever changed in the vault, drain the entity queue, classify new reasoning edges, regenerate the entity and topic wiki pages. It’s persistent, so if my laptop was asleep at compile time, it just catches up next boot.

The part that’s actually changed my mornings, though, is a daily brief that reads my calendar and email and drops a summary into that day’s note before I’ve opened either app: which meetings collide, what’s still waiting on an RSVP, an email triage (what got archived, what got routed to unsubscribe, how many Scholar alerts came in and whether any are worth a second look), plus whatever tasks I didn’t finish yesterday, carried forward. It’s blunt about it, too: it’ll tell me flat out I’ve double-booked 2pm instead of letting me find out live in the meeting.

This is the same Scholar-alert pipeline from my Week 1 literature review post, just further downstream now: alerts land in Gmail, the digest reads them, and the ones worth keeping get pulled into the vault as their own atomic thoughts instead of dying in an inbox.

There’s a Learning Biography the compiler regenerates too, a standing synthesis of just the technical material (coursework, the AI-news archive, book reviews, the reading log), with personal journal content deliberately excluded. It stays a separate document from my autobiography on purpose. I don’t want a career-learning log quietly absorbing personal reflection, or the reverse.

Contributing back to Nathan Jones’ open source repo

Working inside someone else’s codebase for months means you keep bumping into rough edges, and fixing them upstream felt more useful than quietly patching my own fork. Three PRs open on Nate’s repo right now:

• #443: the dashboard’s kanban board had a real bug. Dropping a card onto another card (instead of into empty column space) silently failed, which meant a full column was effectively unreachable. Fixed the drag handler, finished the intra-column reordering that was scaffolded but never wired up, and fixed a genuinely funny bug where the card-edit modal rendered nearly transparent over the board.
• #444: a reading-list schema that had been sitting in the “planned” column of the schemas README. Books, articles, podcasts through want-to-read → reading → finished, plus abandoned, because DNF-ing a book is a real outcome and I didn’t want a future ALTER TABLE just to admit that.
• #445: finished the daily-digest recipe’s Supabase Edge Function path, stubbed as “planned, contributions welcome” since the recipe was written. Kept it template-based rather than routing it through an LLM call on purpose, a free, zero-marginal-cost path for anyone who wants a scheduled digest without needing an API key for anything.

Nothing world-changing, but each one was a real thing that bugged me enough to fix properly instead of routing around it in my own fork.

Why bother

The point was never “build a RAG pipeline for fun.” It’s that eleven years of logs are only worth as much as they’re findable. Now when I’m stuck on something, I can just ask, and it can tell me whether past-me already fought this exact fight, and usually, annoyingly, the answer is yes.

At AidKit, I logged many of the tangled bugs that I struggled through in my CarbonInterface. As I continue to grow as an engineer and researcher, I am making a practice of documenting each tricky problem I solve, and the various O’Reilly books and workshops I work through, in order to build a searchable database that can help me more easily navigate future challenges, while keeping track of my growth and learning with the metrics that are already part of this “Digital Brain”, which I will continue to refine in the coming weeks.