I got mem-local reviewed as a finished design by asking Claude, in a separate conversation, to act as a critical friend: is this likely to meet the needs of both the AI and me, and how does it stack up against what else is out there. What came back placed it against three recognisable home-lab patterns, named plainly rather than hedged, and it’s the clearest single account of where this system actually sits — so it’s reproduced close to source rather than thinned out.
The three camps
“Most personal-memory home-lab builds fall into three camps, and yours avoids the characteristic failure of each:
- Vector-dump-into-Chroma/Qdrant + RAG — the common one. Fails on exactly the thing you fixed: no rationale, no supersession, stale facts asserted confidently, unbounded growth. Yours is materially better here.
- Plain markdown vault + grep/embeddings (Basic Memory, Obsidian-MCP, etc.) — simpler, genuinely portable, but no temporal model and no real entity graph. You correctly crib their retrieval layer without inheriting their flat-file limitations.
- Heavyweight knowledge-graph stacks (Neo4j + separate vector service + LangChain/GraphRAG) — over-built for personal scale, operationally heavy, lock-in-prone. You explicitly reject this, rightly.”
Each camp fails a different way, and mem-local’s shape answers each failure directly rather than making a generic “best of all worlds” claim:
- Against the vector-dump camp, the answer is bi-temporal supersession and a scoped rationale field on every entry — covered in full in theme-bitemporal-supersession.
- Against the markdown-vault camp, the answer is the explicit edges table — a real graph, not a folder of cross-linked files with embeddings layered on — covered in theme-graph-not-vector-dump. Basic Memory specifically was rejected as a fork base for this reason, while its retrieval layer was still worth borrowing.
- Against heavyweight graph stacks, the answer is scale-matching: one SQLite file instead of Neo4j plus a separate vector service plus an orchestration framework, because the actual corpus is megabytes and tens of records, not enterprise volume. The review’s own framing of the trade this avoids: “over-built for personal scale, operationally heavy, lock-in-prone.”
Where the review said I was distinctive
The verdict on the single decision that sets mem-local apart from all three camps has its own page — theme-human-approval-write-gate — because it came up independently, twice, as the strongest single differentiator. Two smaller merits from the same review are worth keeping here because they’re specific rather than generic praise:
- “One refresh function = three boundaries.” Cache-correctness, scope enforcement, and embedding-currency all collapse into a single tested function rather than three separately-maintained mechanisms — genuinely elegant, and the kind of thing that keeps a personal project maintainable years on rather than accreting parallel logic that quietly drifts out of sync.
scope:local_onlyas a fail-closed hard wall, with the explicit honesty that anything marked that way becomes useless to the hosted model as a direct consequence. Most systems hand-wave privacy; this one draws the boundary precisely and accepts its cost out loud rather than pretending there isn’t one.
Where the review said the field beats mem-local — honestly, not defensively
I went back to this later and tried to catch myself being smug about the design — asked outright whether it’s more token-efficient and lower-maintenance than the alternatives, half-hoping for a clean yes. What came back was closer to “yes, but stop taking credit for the wrong reason”: the token efficiency is real, but it’s owned by retrieval and capture discipline — returning a small dense set, excluding stale entries server-side — not by the storage choice itself. And “lower maintenance” is only true after the bi-temporal SQL is validated and frozen; until then it carries more risk than a fork would have, because getting append-only-never-mutate wrong corrupts history irreversibly. The honest trade: recurring ambient maintenance (file-sync coherence, frontmatter mapping, tracking someone else’s fork) swapped for one concentrated, high-stakes thing that has to be got right once.
The capability gap named as real rather than a hedge: no semantic search over history. The vector index only covers the current graph; anything superseded drops to keyword-only retrieval. Graph-first, full-temporal-embedding systems can answer “what were we thinking about X six months ago” natively; mem-local can only grep it. The other commonly-cited gaps — no graph-walk retrieval as a first-class primitive, no zero-friction auto-capture, single-user only — were declined on purpose, because they solve problems that don’t exist at this scale. The historical-search gap is different: it’s a problem not yet had, but plausibly acquired if the system keeps working. What’s actually being done about it, and what’s deliberately still open, is covered in 06-open-questions.
The idea that didn’t get built, and might be worth revisiting
One suggestion from the same review never got taken up, and it’s worth recording rather than letting it quietly disappear: for the hard-deletion problem — the one genuine unsolved tension between “never delete” and “sometimes you actually have to” — the review proposed crypto-shredding rather than deletion-across-derivatives. Encrypt each assertion’s erasable content under a per-entity key; “hard delete” becomes “destroy the key,” one atomic operation that renders content, embeddings, and any merged-survivor copies unreadable without touching the bi-temporal structure at all. The audit skeleton — that an assertion existed and was erased — survives; the content doesn’t. It’s the standard answer in event-sourced systems facing exactly this collision, and it was never evaluated against the plan already on the table. Filed here rather than acted on, because hard deletion is still explicitly parked until something sensitive actually needs it.
Sources: Home lab proposal review and comparison, 19 Jun 2026 (full critical-friend review, quoted extensively above); earlier, unpublished notes memory-system-differentiation-and-historical-search-decision (“the features I’m proud we didn’t build” and the token-efficiency accounting).