A cold-start preamble for anyone reading the mem-local pages without the rest of the project behind them — what the project actually is, plus the handful of terms and conventions the timeline and theme pages use without re-explaining each time.
What mem-local is, in two sentences
It’s a personal, self-hosted memory system for AI conversations: a database that stores decisions, projects, and their relationships as a graph, with a human approving every write before it becomes permanent. Built from scratch from June 2026, running on hardware I already owned, because nothing off-the-shelf did all three of “remembers why, not just what,” “never silently rewrites history,” and “stays on my own machine.”
Terms
- MCP (Model Context Protocol). The standard Claude uses to call external tools. mem-local exposes itself to Claude as an MCP server with exactly six tools — no more.
- sqlite-vec. A SQLite extension that stores and searches vector embeddings — the piece that makes semantic (“finds things that mean the same, not just say the same”) search possible without a separate database.
- FTS5. SQLite’s built-in full-text search — ordinary keyword search, the complement to sqlite-vec’s semantic search.
- RRF (Reciprocal Rank Fusion). The formula mem-local uses to combine a keyword-search result list and a semantic-search result list into one ranked list, without either search type dominating the other.
- Bi-temporal. Tracking two independent timelines for every fact: when it was actually true in the world, and when the system found out about it. Covered in full in theme-bitemporal-supersession.
- Supersession. mem-local’s word for how a fact changes: never edit a row, insert a new one that supersedes the old, and keep the old one around. Nothing is ever deleted just because it’s out of date.
- The write gate. The rule that nothing reaches the permanent store without a human approving it first — Claude proposes, David approves or rejects. Covered in full in theme-human-approval-write-gate.
- The register. The project’s own internal decision log — a running, lettered list (Decision A, B, C… through the alphabet and beyond) of everything settled during the build, with the reasoning behind each one. It’s mem-local’s own documentation of itself, not part of the reconstructed vault pages, and it’s what the
register:...citations at the bottom of each page point back to. - Entity IDs (
e3,e40,proj:ai-memory-system, etc.). How mem-local names things internally — every stored decision, project, or concept gets a short ID. They show up in citations as pointers into the live store, not as something a reader needs to memorise.
One naming collision worth knowing about early
mem-local’s own build has its own internal “Stage 2” — the architecture-decisions session — which has nothing to do with Stage 2 of this six-part reconstruction timeline (which is, confusingly, also about that same session). Same word, two different countings, flagged in full where it first comes up in 02-architecture-decisions.
A companion to mem-local, written for a reader who’s arrived at one of the mem-local pages directly rather than through the project index.