MemPalace evaluation — dev workflow vs KH platform fit

MemPalace evaluation — dev workflow vs KH platform fit

Date: 2026-05-08 Branch: content-items-investigation Author: Claude Code session (source review on mempalace/mempalace@develop + Phase 0.7 grounding) Subject: MemPalace/mempalace v3.3.4 (PyPI: mempalace, MIT, Python 3.9+) — local-first AI memory system. Author: Milla Jovovich + co-founder Bensig. 51.5k stars, 6.8k forks at evaluation date — large community footprint, repo created 2026-04-05, very active (push date matches eval day). One-liner per Liam: “The best-benchmarked open-source AI memory system.” Status: Evaluation only — no installation, no integration changes proposed without explicit decision. Per parent-session framing: bias toward re-use of battle-tested infrastructure; “what should we be doing”, not “what’s lowest disruption”.

---

1. What MemPalace is (single paragraph)

MemPalace is a Python CLI + MCP server that stores conversation history and project files verbatim (no summarisation, no extraction-then-discard) into a hierarchical structure called a “palace”: Wings (people/projects/topics) → Rooms (days/sessions) → Drawers (verbatim text chunks). It uses ChromaDB (default, pluggable) for vector search over a 384-dim all-MiniLM-L6-v2 ONNX embedding (the ChromaDB default — no API key required, runs locally with optional CUDA/CoreML/DirectML acceleration), plus a temporal knowledge graph in local SQLite for entity-relationship triples with valid_from/valid_to validity windows (the architectural feature that distinguishes it from pure RAG). The retrieval layer is a hybrid BM25 + vector search with optional LLM rerank; the headline benchmark is 96.6% R@5 retrieval recall on LongMemEval with zero LLM calls (98.4% on held-out 450 questions with hybrid v4 keyword/temporal/preference boosting; ≥99% with LLM rerank). Ships as: a mempalace CLI, a mempalace-mcp stdio MCP server with 29 tools (palace read/write, KG operations, cross-wing tunnels, drawer CRUD, agent diaries), a Claude Code plugin (.claude-plugin/) bundling the MCP server + 5 commands (/help /init /mine /search /status) + Stop and PreCompact hooks that auto-save sessions to the palace, and a Codex plugin for the OpenAI Codex harness. Mission per MISSION.md: “Memory is identity. When an AI forgets everything between conversations, it cannot build real understanding.” Design principles per CLAUDE.md: verbatim-always, append-only, entity-first, local-first zero-external-API by default, hooks under 500ms, privacy by architecture (no telemetry, no phone-home).

2. No grounded run

Unlike the graphify evaluation (which executed the full pipeline locally on an lib/ai/ + docs/design/*.md subset), this evaluation is source-review only. Reasons:

1. MemPalace is a stateful local store — first install creates ~/.mempalace/ (palace + KG SQLite + ChromaDB). Reversibility is good (uv tool uninstall, rm -rf ~/.mempalace/) but the install footprint is heavier than graphify’s stateless CLI.
2. Two of the highest-value features (auto-save Stop hook, PreCompact hook) only fire over a real Claude Code session — would need to install the plugin into the session, not just inspect.
3. The benchmark numbers (§3.4) are reproducible per benchmarks/BENCHMARKS.md but require downloading LongMemEval / LoCoMo datasets — out of scope for an evaluation pass.

If this evaluation surfaces a “yes, install” verdict, the grounded next step is: install on a side branch, mine ~/.claude/projects/-Users-liamj-Documents-development-knowledge-hub/ (the existing 681 MB of session JSONLs + 524 KB / 103 memory files for the KH project), then evaluate the resulting palace + search quality against current Claude Code memory recall behaviour. Confidence cost: ~5% — claims about retrieval quality on KH’s own data are inferred from public benchmarks, not measured.

3. Architecture summary

3.1 Module layout (per source inspection of mempalace/)

Module	Function	Notes for KH
mcp_server.py	29-tool stdio MCP server, JSON-RPC over stdin/stdout	Stdio-only — incompatible with Claude.ai web (which needs OAuth + HTTP-streamable). Fine for Claude Code, Claude Desktop, Cursor, Codex; not for KH’s MCP App surface.
cli.py	14 subcommands: init mine sweep search wake-up split migrate status repair-status repair hook instructions mcp compress	CLI dispatcher; instructions <cmd> returns structured guidance for the Claude skill
config.py	MempalaceConfig + sanitize_* input validators	Reads ~/.mempalace/config.json; env override MEMPALACE_PALACE_PATH
miner.py	Project file miner (mine TS/Python/Markdown into wings)	Same shape as graphify detect+extract but emits drawers (verbatim) not nodes
convo_miner.py	Chat transcript miner (Claude Code JSONL, ChatGPT, Slack, plain text)	Key dev-workflow feature: mempalace mine ~/.claude/projects/ --mode convos --wing <project>
normalize.py	Format detection + normalisation; Claude Code JSONL parser strips system tags / hook chrome	NORMALIZE_VERSION = 2 (bumps invalidate prior drawers); _try_claude_code_jsonl() is the only format that needs cleaning — others pass through
searcher.py	Hybrid BM25 + vector search with closet-pointer rank boost	BM25 IDF computed over candidate set, not corpus — Lucene/BM25+ smoothed; closets are ranking signal, never gate
embedding.py	ChromaDB-compatible embedding factory; auto-selects CUDA/CoreML/DirectML/CPU	all-MiniLM-L6-v2 384-dim, ~300 MB on disk; falls back to CPU if accelerator unavailable
palace.py	Shared collection access (drawers + closets); SKIP_DIRS includes .git, node_modules, .next, .venv, dist, build, etc.	KH’s existing exclusions match almost 1:1
palace_graph.py	Room traversal + cross-wing “tunnels”	Tunnels are user-asserted edges connecting wings — adjacent to but separate from the temporal KG
knowledge_graph.py	Temporal entity-relationship graph in SQLite	triples(subject, predicate, object, valid_from, valid_to, confidence, source_drawer_id, adapter_name) — direct conceptual overlap with KH entity_relationships. See §5.3.
entity_detector.py + entity_registry.py	Auto-detect people/projects from content	Heuristic-first; v4 alpha adds local NLP (#507)
dialect.py	AAAK compression dialect for the closet (index) layer	Symbolic shorthand that lets an LLM scan thousands of entries cheaply — closet points to drawer for full text
layers.py	L0-L3 wake-up stack (mempalace wake-up ≈ 600-900 tokens)	“Show me what I should know about this project right now” — distillation of recent + important drawers
dedup.py	Content-hash dedup before drawer insert	Exact analog of KH’s content_text_hash strategy
hooks_cli.py	Stop / PreCompact / SessionStart hooks; reads JSON from stdin	Saves periodically and before context compression; injects MCP-tool-call instructions back to the assistant; STOP_BLOCK_REASON explicitly tells assistant “use MemPalace MCP tools, not auto-memory .md files”
query_sanitizer.py	Prompt-injection mitigation in user queries	Defensive; no special KH integration value
repair.py, migrate.py	Palace consistency + ChromaDB version migration	Migrates chromadb 0.6 → 1.5 HNSW format, repairs blob-seq drift
backends/base.py + backends/chroma.py	Pluggable storage backend; v4 alpha targets PostgreSQL + LanceDB	PostgreSQL backend (#665) is in v4-alpha review — direct relevance for KH (Supabase-backed). See §5.6.

3.2 Claude Code plugin shape

File	Content
.claude-plugin/plugin.json	name mempalace, version 3.3.4, declares one MCP server + one skill + Stop/PreCompact hooks
.claude-plugin/.mcp.json	{ "mempalace": { "command": "mempalace-mcp" } } — stdio invocation
.claude-plugin/skills/mempalace/SKILL.md	One skill, allowed-tools Bash, Read, Write, Edit, Glob, Grep. Skill body delegates: “run mempalace instructions <cmd> and follow the returned instructions step by step” — dynamic instructions live in Python, not in the skill
.claude-plugin/hooks/hooks.json	Stop hook → mempal-stop-hook.sh; PreCompact hook → mempal-precompact-hook.sh
.claude-plugin/hooks/mempal-stop-hook.sh	Thin wrapper: mempalace hook run --hook stop --harness claude-code (with module fallback)
.claude-plugin/commands/{help,init,mine,search,status}.md	5 slash commands; thin wrappers over the CLI

3.3 MCP tool surface (29 tools per mcp_server.py)

Read (palace): mempalace_status, mempalace_list_wings, mempalace_list_rooms, mempalace_get_taxonomy, mempalace_search, mempalace_check_duplicate, mempalace_get_aaak_spec Read (graph): mempalace_traverse_graph, mempalace_find_tunnels, mempalace_graph_stats, mempalace_list_tunnels, mempalace_follow_tunnels Write (palace): mempalace_add_drawer, mempalace_delete_drawer, mempalace_get_drawer, mempalace_list_drawers, mempalace_update_drawer Write (graph): mempalace_create_tunnel, mempalace_delete_tunnel, mempalace_kg_query, mempalace_kg_add, mempalace_kg_invalidate, mempalace_kg_timeline, mempalace_kg_stats Diary: mempalace_diary_write, mempalace_diary_read (per-agent journals) Maintenance: mempalace_hook_settings, mempalace_memories_filed_away, mempalace_reconnect

3.4 Benchmark detail (per benchmarks/BENCHMARKS.md)

Benchmark	Mode	Score	LLM	Notes
LongMemEval (500q, R@5)	Raw vector search	96.6%	None	$0/query, fully offline; reproducible from this repo
LongMemEval (held-out 450q, R@5)	Hybrid v4 (keyword + temporal + preference boost)	98.4%	None	Honest generalisable hybrid figure (50q dev set used for tuning)
LongMemEval (full 500, R@5)	Hybrid v4 + Haiku rerank	100%	Optional (Haiku ~$0.001/query)	Tuned on 3 specific wrong answers — flagged as teaching-to-the-test
LoCoMo (1,986 multi-hop QA, R@10)	Session, no rerank	60.3%	None	Baseline
LoCoMo (R@10)	Hybrid v5, no rerank	88.9%	None	Beats Memori’s 81.95%
LoCoMo (R@10)	bge-large + Haiku rerank	96.3%	Haiku	Single-hop 86.6%, temporal-inf 87.0%
ConvoMem (250 items, avg recall)	Default	92.9%	None	Per-category: Assistant Facts 100%, User Facts 98.0%, Preferences 86.0%
MemBench (ACL 2025, 8,500 items, R@5)	Default	80.3%	None	All categories

Comparison context (per WebSearch + mempalace’s own table caveat):

System	LongMemEval score	Caveat
BM25 (sparse baseline)	~70%	Keyword baseline
Mem0	~49%	Per Zep’s research — Mem0 doesn’t publish LongMemEval; their headline metric is LoCoMo QA
Zep	63.8%	GPT-4o
Letta	~83.2%	Reported 2026
Evermind (EverOS)	83.0%	Outperforms Zep + Mem0
Supermemory	85.4%	GPT-4o, QA accuracy (different metric)
Emergence AI	86%	RAG-based
Mastra OM	94.87%	GPT-5-mini, QA accuracy not retrieval recall
OMEGA	95.4%	GPT-4.1
MemPalace raw	96.6%	None, retrieval recall
MemPalace hybrid v4 held-out	98.4%	None, retrieval recall, generalisable

The honest delta: MemPalace’s headline 96.6% is the highest LongMemEval retrieval recall published with zero LLM calls. The mempalace project is explicit (in their own BENCHMARKS.md) that side-by-side comparison vs Mastra/Supermemory is not apples-to-apples because those publish QA accuracy, not retrieval recall. With that caveat respected: the raw 96.6% is genuinely the strongest published retrieval-recall number for an open-source memory system, and the architectural insight (“verbatim storage + good embeddings beats LLM-extraction systems because no information is lost”) is well-supported by the Mem0 30-45% on ConvoMem vs MemPalace 92.9% delta.

3.5 Storage + privacy posture

• Default backend: ChromaDB local, ~300 MB embedding model on disk, palace data under ~/.mempalace/<palace_name>/.
• KG backend: SQLite at ~/.mempalace/knowledge_graph.sqlite3 with journal_mode=WAL and chmod 0700 on parent dir.
• No telemetry, no phone-home, no external service for core operations. External LLM (Anthropic/OpenAI/Google) is BYOK and never silently enabled — explicit user opt-in, never a default fallback.
• v4-alpha (in review): PostgreSQL backend (#665) and LanceDB backend (#574) — relevant for KH’s Supabase architecture (see §5.6).

---

4. Lens 1 — Dev workflow value (Claude Code memory replacement?)

4.1 The current Claude Code memory system

KH’s Claude Code project at ~/.claude/projects/-Users-liamj-Documents-development-knowledge-hub/ currently has:

• 103 memory files (~524 KB total) under memory/ — MEMORY.md index (16.3 KB) + per-fact files (feedback_*.md, project_*.md, reference_*.md, user_*.md).
• 189 session JSONL files (681 MB total at project root) — every Claude Code session ever run, raw transcripts including tool calls, hook output, system tags.
• An _archive/ subdir under memory/ for retired feedback (10 files visible).

The memory format per the existing files is: 1 MEMORY.md index with bullets pointing at named feedback/project/reference files; each file is a name: / description: / type: frontmatter + free-text body documenting one pattern, decision, or piece of context. The MEMORY.md index hyperlinks to each file via filename — a flat, manually curated structure.

Claude Code’s existing auto-memory is the operational baseline. It works (proven across hundreds of sessions). It has known limitations (no per-fact deletion, drift in MEMORY.md as files accumulate, no cross-session search beyond the assistant grepping ~/.claude/projects/<project>/memory/ directly).

4.2 What MemPalace does that the existing system does not

Capability	Claude Code auto-memory	MemPalace
Verbatim transcript storage (not just curated facts)	No — only what the assistant wrote to a feedback_*.md file	Yes — mempalace mine ~/.claude/projects/ --mode convos ingests every JSONL session verbatim, chunked by Q+A pair, with normalisation (system tags / hook chrome stripped per NORMALIZE_VERSION=2)
Cross-session semantic search	No — assistant must grep memory dir	Yes — mempalace search "why did we switch to GraphQL" with hybrid BM25+vector, hits across all sessions in the wing
Cross-session keyword search	Grep, but only against memory/ not session JSONLs	Hybrid search includes BM25 — exact-term hits never miss
Temporal knowledge graph	No	Yes — kg_add(subject, predicate, object, valid_from, valid_to) with timeline queries; matches Zep’s pitch on local-only SQLite
Auto-save hooks	None — every memory write is assistant-initiated mid-conversation, costing tokens	Stop hook + PreCompact hook — fires after the conversation ends or before context compression, zero in-conversation tokens for memory bookkeeping. Per Mission doc: “What used to cost about $1.13 per session just in re-transmitted diary blocks is now zero, because the content never enters the chat window at all.”
Per-agent diaries	No	mempalace_diary_write(agent_name, entry, topic, wing) — each specialist agent gets its own journal, discoverable via mempalace_list_agents (no system-prompt bloat)
Wake-up context	Manual: read MEMORY.md + relevant files	mempalace wake-up returns L0+L1 stack ~600-900 tokens — distilled “what should I know about this project right now”
Performance budget	None enforced	Hooks under 500ms; startup injection under 100ms (per design principles)
Privacy	Local files, not encrypted, not chmod-restricted by default	~/.mempalace/ parent dir chmod 0700; SQLite WAL mode; no telemetry
Backend pluggability	Filesystem-only	ChromaDB default, PostgreSQL/LanceDB/PalaceStore in v4-alpha

4.3 What MemPalace does NOT do that the existing system does

1. No MEMORY.md-style hand-curated index. MemPalace is verbatim-first; the closest analog is mempalace wake-up (L0+L1 distilled) or the AAAK closet layer (compressed pointers). There is no human-authored “here are the patterns I want the assistant to recall” file. The current MEMORY.md (with its 100+ “Feedback & Patterns” entries hand-curated by Liam over months) is an editorial artefact, and MemPalace would not replace that — it would supplement it with verbatim recall over the underlying conversations.
2. No skill / hook integration beyond Stop / PreCompact / SessionStart. Claude Code’s existing Notification, UserPromptSubmit, PreToolUse, PostToolUse, SubagentStop, Skill hooks are not consumed. So mempalace cannot, e.g., auto-save a feedback file when the assistant writes a particular pattern via a hook on PostToolUse:Edit.
3. No structural awareness of feedback_*.md / project_*.md / reference_*.md types. MemPalace ingests all .md files into wings/rooms/drawers — the existing taxonomy (feedback / project / reference / user) is not preserved.
4. No bi-directional sync. If the assistant writes a new feedback_*.md, it does NOT auto-appear in the palace until the next mine. If the assistant updates a drawer via MCP, it does NOT propagate to a feedback_*.md.

4.4 Migration cost from existing memory files

Per source inspection of convo_miner.py + miner.py:

mempalace init ~/Documents/development/knowledge-hub/.mempalace
mempalace mine ~/.claude/projects/-Users-liamj-Documents-development-knowledge-hub/memory/
mempalace mine ~/.claude/projects/-Users-liamj-Documents-development-knowledge-hub/ --mode convos --wing knowledge-hub

Estimated wall clock on an M-series Mac (no GPU): ~5-15 minutes for the 524 KB memory dir + ~30-90 minutes for the 681 MB session JSONLs. Cost: zero (CPU-only embeddings via ChromaDB default). Storage: ~300 MB embedding model + ~50-150 MB palace data (estimated from chunk count × 384 floats × 4 bytes + drawer text).

The 524 KB memory dir mines as .md files — each file becomes one or more drawers under whatever wing is detected. The existing feedback_/project_/reference_/user_ prefix in filenames does not become a wing or room without manual hinting (--wing, --room, or post-mine reorganisation via the palace MCP tools).

The 189 session JSONLs mine as --mode convos — _try_claude_code_jsonl() recognises Claude Code’s JSONL format (role/sender, tool_use/tool_result blocks, system tags), strips noise per NORMALIZE_VERSION=2, chunks by Q+A pair into 800-char drawers, and files them into wings detected from content (with --wing override available). The _register_file() sentinel ensures empty/zero-chunk files don’t get re-mined every run.

Reversibility: rm -rf ~/.mempalace/ + uv tool uninstall mempalace. Hooks: mempalace hook uninstall. The Claude plugin: /plugin uninstall mempalace. Fully reversible — original .claude/projects/ files are read-only inputs, never modified.

4.5 Concrete dev-workflow integration shapes

Shape A — supplement, don’t replace. Keep current MEMORY.md + feedback_*.md (Liam’s editorial curation, irreplaceable). Install MemPalace as an additional MCP server. Use it for cross-session verbatim recall (“what did we say about RLS in session 226?”) via mempalace_search. Use it for temporal KG (“what was the EP2 status as of 2026-04-15?”) via mempalace_kg_query. No migration of existing memory files — they stay where they are. New session JSONLs auto-saved via Stop hook.

Shape B — full migration to MemPalace. Move all feedback_*.md content into mempalace drawers under wing=knowledge-hub, room=feedback. Replace assistant grep of memory/ with mempalace_search. Deprecate the MEMORY.md index (replaced by mempalace_get_taxonomy + mempalace wake-up). Risks: loses the editorial curation that makes MEMORY.md valuable as a Liam-curated “rules I want followed” doc; MemPalace’s verbatim-first design isn’t optimised for “list of 100 rules with priority”. Not recommended.

Shape C — verbatim transcript layer only. Don’t touch the existing memory/ dir. Just install the Stop hook + auto-mine ~/.claude/projects/<project>/<session>.jsonl. Add mempalace_search as the cross-session retrieval tool. Skip the KG, skip diaries, skip wake-up, skip mining the curated memory/ dir. Lowest-risk integration; addresses the actual gap (no cross-session verbatim search) without disrupting Liam’s editorial workflow.

4.6 Concrete fit with current Claude Code workflow

Compatibility checklist:

Question	Answer
Does mempalace integrate with Claude Code’s hooks?	Yes — Stop + PreCompact (own ones, registered via .claude-plugin/hooks/hooks.json). Does not consume UserPromptSubmit, PreToolUse, PostToolUse, Notification, SessionStart, SubagentStop, or skill events.
Does mempalace integrate with Claude Code’s Skill system?	Limited. Ships one mempalace skill (SKILL.md) that delegates to mempalace instructions <cmd>. Other skills don’t auto-invoke mempalace tools — that’s an assistant prompt-engineering decision.
Does mempalace integrate with the existing memory/ dir?	No — it’s a parallel store, not a sync layer.
Does mempalace require an API key?	No for core path. ChromaDB default + local ONNX embeddings + local SQLite KG. BYOK Anthropic/OpenAI/Google for optional LLM rerank only.
Does mempalace support the 1M context window framing?	Indirectly — its design goal is to make memory retrievable so the assistant doesn’t need everything in context. Per-message recall via mempalace sweep + per-session via Stop hook means the 1M context is used for current work, with mempalace_search filling in cross-session detail on demand.
Does mempalace install footprint conflict with KH’s Python pipeline?	Marginal. ChromaDB + onnxruntime + sentence-transformers add ~500 MB-1 GB to local Python deps. Not in CI (mempalace is a local dev tool). KH’s existing requirements.txt is for the Python ingest pipeline (Cloud Run); no overlap.
Worktree isolation?	Each worktree would point at the same ~/.mempalace/ (single shared palace). For per-worktree palaces use MEMPALACE_PALACE_PATH=<worktree>/.mempalace mempalace-mcp. Recommend single shared palace with --wing per worktree (worktree-content-items, worktree-prod-readiness, etc.) for cross-worktree recall.

4.7 Verdict — Lens 1

Recommended adoption: Shape C — verbatim transcript layer only. This is the highest-value, lowest-disruption shape:

• Solves a real gap: cross-session verbatim search. The current setup forces the assistant to read individual JSONL files via Bash, which is token-expensive and unreliable across the 681 MB transcript corpus.
• Preserves Liam’s editorial curation: MEMORY.md + per-fact files stay untouched.
• Auto-save with zero in-conversation cost: Stop hook fires after the assistant has finished — no wasted tokens on bookkeeping, addresses the same pain that Liam’s existing feedback_action_items_single_location.md and feedback_continuation_prompt_lean_template.md patterns are about (don’t waste tokens duplicating context).
• Reversible: rm -rf ~/.mempalace/ && uv tool uninstall mempalace && /plugin uninstall mempalace.
• Local-first, zero cost, MIT licence, large community footprint — meets every “battle-tested, re-use, not reinvent” criterion in the framing corrections.

What to add to the assistant’s prompt-engineering once installed: “Before grepping ~/.claude/projects/<project>/memory/ for prior context, call mempalace_search first. The current session is already auto-saved; you do NOT need to manually record anything to mempalace mid-conversation.”

Confidence: 85%. Sub-90% because: (a) the LongMemEval 96.6% R@5 result is on conversation-style queries; KH’s actual ask shape is mixed (some “what did we decide about X” — mempalace’s strength — and some “give me the verbatim text of Y” — also mempalace’s strength, but BM25 hit-rate on KH’s specific terminology is not measured); (b) Stop-hook reliability under Claude Code’s evolving plugin spec is a moving target.

4.8 Effort + cost (Lens 1)

Action	Effort	Token cost	Reversibility
uv tool install mempalace (parent + worktree environments)	2-5 min	0	uv tool uninstall mempalace
mempalace init ~/.mempalace/knowledge-hub + first mine of session JSONLs	~30-90 min wall (CPU only), ~150-400 MB disk	0	rm -rf ~/.mempalace/
Install Claude plugin: /plugin install mempalace@MemPalace/mempalace	1-2 min	0	/plugin uninstall mempalace
Update assistant guidance (one paragraph in CLAUDE.md or skill prompt)	5 min	0	Edit revert
Initial validation (compare mempalace_search vs grep memory/ on 5-10 representative queries)	30-60 min	Low (whichever model is running)	n/a

Total: half-session install + half-session validation.

---

5. Lens 2 — Platform feature value (per-user / per-organisation memory in KH)

5.1 The strategic positioning

Per graphify-evaluation-feedback.md quoting the AI-strategy doc: “The knowledge base IS the product. Bids are the first application; the same structured data will power sales proposals, compliance, training, and other use cases. … Claude is the primary AI interface — where most AI-powered interaction happens day-to-day. … Knowledge Hub’s value is in the data layer and API surface, not in building Claude’s equivalent inside the web app.”

Per kh-client-feedback.md Item 3: “AI safety needs the hub to enforce citation, not just answer. … the search tools should return content with citation metadata that’s hard to drop, and ideally the hub should expose a ‘strict extraction’ mode that returns only the matching chunk with its source ID and refuses to invent or paraphrase.”

MemPalace’s design principles speak directly to both:

• “The knowledge base IS the product, accessed primarily via Claude (Desktop/Cowork)” ↔ mempalace’s verbatim-storage + 29-tool MCP surface is the same shape as KH MCP (search-and-retrieve over a structured store, accessed via Claude). The architectural difference: KH’s MCP runs server-side via Vercel + Supabase; mempalace’s is local stdio. For a per-user/per-org memory layer that augments the KB, mempalace shape is a candidate.
• “AI safety needs verbatim, citable, refuse-to-paraphrase” ↔ mempalace’s “verbatim always, never summarize” design principle is non-negotiable in their CLAUDE.md. The whole architecture is built around the same insight Liam’s client just surfaced: extraction-then-discard loses information; verbatim storage with good retrieval beats it.

This is a strong strategic match — but the platform-fit question is more nuanced than the dev-workflow one.

5.2 What “per-user / per-organisation memory in KH” could mean

Three product framings, in increasing scope:

Framing 1 — Personalisation memory. “Remember this user’s preferences across sessions.” E.g. “I always cite NCSC principles by their full name”, “I prefer answers under 200 words”, “Don’t surface Bitdefender content for production-infrastructure questions” (per client feedback Item 3 anti-tag pattern). Lightweight, per-user, stored alongside users in Supabase. Read on every MCP call to bias responses.

Framing 2 — Conversation history memory. “Remember what we discussed last session.” E.g. “We were drafting the LBBD DPIA last week — pick up from question 12.” Per-user (or per-user-per-workspace), stored as conversation transcripts + retrievable via search. This is exactly what mempalace solves at the local-Claude-Code level — but moved server-side, multi-tenant.

Framing 3 — Organisational learning memory. “Remember what this organisation has answered before.” E.g. “User X answered question Y in bid Z six months ago — surface that as a candidate for question Y’ in current bid Z’.” Already partially exists as the Q&A library (P3) + entity_relationships, but not surfaced as “memory” — surfaced as content retrieval.

5.3 Compatibility with KH’s existing pgvector + entity_relationships

KH’s existing infrastructure (per 0.7-synthesis.md + memory MCP):

• content_items with embedding vector(1024) (text-embedding-3-large via OpenAI) + content_chunks for sub-document retrieval.
• entity_mentions(entity_text, entity_type, content_item_id, span_start, span_end, classification_confidence) — Pass 1 / Pass 2 classification output.
• entity_relationships(subject_entity, predicate, object_entity, ...) — currently no temporal validity windows.
• pipeline_runs, ai_call_log (Phase D-deferred), source_documents with version chain.
• Storage: Supabase Postgres (project rovrymhhffssilaftdwd, eu-west-2, pgvector 0.8.0).

MemPalace’s storage shape vs KH:

Concept	KH	MemPalace
Content unit	content_items row + content_chunks rows	Drawer (verbatim text chunk, default 800 chars)
Embedding	OpenAI text-embedding-3-large 1024-dim, in Supabase	Local ONNX all-MiniLM-L6-v2 384-dim, in ChromaDB / SQLite
Container	workspaces (per-tenant scoping), domains × subtopics (taxonomy)	wings (people/projects/topics) + rooms (days/sessions)
Entity	entity_mentions (typed, scoped to content_item)	entities(id, name, type, properties) — not scoped to a specific drawer
Relationship	entity_relationships(subject, predicate, object, ...) — no temporal validity today	triples(subject, predicate, object, valid_from, valid_to, confidence, source_drawer_id, adapter_name)
Lineage	source_documents with version + parent_id chain	source_drawer_id on each KG triple → traces back to verbatim source
Retrieval	Semantic search via match_chunks RPC	Hybrid BM25 + vector via searcher.py
Multi-tenant	One Supabase project per client (per CLAUDE.md)	Single palace per user (no multi-tenant model out of box)

Architectural compatibility:

• Embedding dimension mismatch: KH uses 1024-dim, mempalace uses 384-dim. Cannot share a vector index.
• Backend mismatch: KH uses Supabase pgvector; mempalace defaults to ChromaDB. However: v4-alpha PostgreSQL backend (#665) closes this gap — mempalace would write triples + drawers to Postgres tables.
• Multi-tenant model: mempalace is single-user-single-palace by design. Multi-tenanting would mean per-user palace dirs (e.g., ~/.mempalace/<user_id>/) or per-user wings within a shared palace. Both work but neither is the design centre of mempalace.
• Entity/relationship overlap: Conceptually 1:1 — entities ↔ entity_mentions, triples ↔ entity_relationships. The temporal validity windows mempalace has (and KH does not) is the most interesting platform-level addition: “this user works at company X” with valid_from='2025-01-01', valid_to='2026-03-15' solves a class of staleness problems KH currently has via archived_at + freshness governance.

5.4 Re-use vs integrate vs reinvent (platform lens)

Five integration shapes, ranked by ROI:

Shape A — Adopt mempalace’s temporal-KG schema for entity_relationships

Concept: Add valid_from, valid_to, confidence, source_drawer_id (or source_content_item_id — match KH naming), adapter_name columns to entity_relationships. Implement kg_invalidate(subject, predicate, object, ended) and kg_timeline(entity, as_of) as RPCs. This brings temporal knowledge graph to KH without depending on mempalace at runtime.

Why it’s the highest-ROI option:

• Zero new external dependency. We borrow the schema design, not the code.
• Solves a real KH problem (entity_relationship staleness, “fact validity” semantics) per upcoming canonical-pipeline work.
• Aligns with industry direction (Zep, Graphiti, mempalace all converging on temporal validity).
• Re-ingest is the natural moment to apply this — empty DB, fresh entity_relationships rows can carry validity from day 1.
• Pairs with the graphify evaluation’s Option C (provenance enum) — both are entity_relationships schema upgrades.

Effort estimate: ~1 day for migration + 2-3 days for RPC + Pass 2 emit + downstream readers update. Direct fit with the canonical-pipeline re-ingest sequence in 0.7-synthesis.md §5.2.

Risk: low. Reversible (additive columns, default null).

Shape B — Adopt mempalace’s verbatim-first design principle in KH’s content_chunks

Concept: Shift content_chunks from “extracted summary chunks” to “verbatim chunks with citation metadata that’s hard to drop”. Already most of the way there — current content_chunks stores chunked content with vector embedding, but is not surfaced through MCP with strict-extraction mode (per client feedback Item 3). Add a mode='strict_extract' parameter to search_knowledge_base MCP tool that returns only verbatim chunk + source content_item_id + chunk_id, no LLM rephrasing.

Why it’s strategic:

• Direct response to client feedback Item 3 (“AI safety needs the hub to enforce citation, not just answer”).
• mempalace’s mission doc and CLAUDE.md explicitly framed verbatim-first as the architectural answer to the “AI confidently pulling correct content from the wrong domain” failure class the client described.
• KH’s “scope tag” requirement from Item 3 maps directly to mempalace’s wing concept: production-infrastructure / internal-it / office-physical are mempalace-shaped wings.
• The mempalace_check_duplicate tool (re-use for content uniqueness checks at ingest) and mempalace_search with wing= filter (exact analog of KH’s workspace_id filter that was broken in Item 1) are pattern-tested in their own benchmarks at 96.6%.

Effort estimate: Strict-extraction MCP tool: ~2-4h (one new tool, returns chunk + content_item metadata + scope_tag). Scope-tag column on content_items: ~1 day (migration + classification prompt update + UI). Total: ~1.5 days.

Risk: low. Pure additive. We’re not depending on mempalace code — we’re applying its design principle.

Shape C — Mount mempalace MCP server alongside KH MCP for per-user memory

Concept: Run a hosted mempalace instance per Claude.ai workspace user (or per-organisation), exposing 29 mempalace tools alongside KH’s existing MCP tools. The mempalace palace stores conversation history + user preferences (Framing 1 + 2 above); the KH MCP serves organisational knowledge content. The two are complementary — when a user asks “draft my response to LBBD question 12 like we did last week”, the assistant calls mempalace_search to find the prior draft conversation + search_knowledge_base to find the canonical answer.

Why it’s interesting:

• Same shape as graphify Option B (mount complementary MCP server). Different question shape from KH’s search tools.
• Requires either: (a) hosting mempalace as a service per-tenant (adds infrastructure ops cost), or (b) shipping a mempalace plugin for Claude Desktop / Cowork that the client installs locally with their KH MCP plugin (zero infrastructure cost, but per-client install).
• Option (b) — local-only — fits KH’s “Claude is the primary interface” strategy: the user’s conversation memory stays on their machine, the org’s knowledge stays in Supabase, the assistant orchestrates between them.

Why it’s complicated for KH:

• mempalace is stdio MCP only; works fine for Claude Desktop / Claude Code / Cursor / Codex. Does NOT work for Claude.ai (which needs OAuth + HTTP-streamable, per mcp-handler gotcha in CLAUDE.md). KH’s MCP App surface is partially Claude.ai. So the per-user memory would only work for desktop-class clients.
• Multi-tenant model is per-user palace, not per-organisation. For “remember this client’s preferences”, we’d need either per-user (n palaces) or per-org-shared-palace (single palace, multiple wings) — neither is mempalace’s design centre.

Effort estimate: Option (a) hosted: ~2-3 weeks for per-tenant provisioning + auth proxy + ChromaDB-backed-by-Postgres deployment. Option (b) plugin distribution: ~1-2 days for an installer + onboarding doc. Recommend option (b) — local-only — at most.

Risk: medium. Stdio-only MCP excludes Claude.ai users. Multi-tenant story is forced.

Shape D — Fork mempalace’s PostgreSQL backend for KH-native deployment

Concept: When v4-alpha PostgreSQL backend (#665) ships, fork it to write drawers + KG triples to Supabase tables (or a separate per-tenant Supabase project). KH then has mempalace’s retrieval quality (96.6% R@5 on conversation-style data) backed by KH’s existing infrastructure.

Why it’s interesting:

• Bypasses the stdio-only / single-user constraints of Shape C.
• Inherits mempalace’s hybrid BM25+vector search + temporal KG quality without re-implementing.
• Compatible with KH’s “one Supabase project per client” model.

Why it’s likely deferred:

• v4-alpha is “in review” — not stable, schema may change.
• Fork-and-maintain commits us to tracking upstream, which is non-trivial for a fast-moving project (51.5k stars, very active).
• Most of the mempalace value is in design principles + benchmarks, not the code — Shape A and Shape B capture that without forking.

Effort estimate: ~2-4 weeks once v4-alpha PG backend is stable. Defer until v4 ships and we have post-launch experience with Shape A + B.

Shape E — Embed mempalace wholesale into KH ingestion

Concept: Each new content_item ingestion calls mempalace.miner.mine_file(); mempalace becomes the canonical extraction + chunking layer.

Why it’s the wrong shape:

• KH’s canonical pipeline (per 0.7-synthesis §2) has 5 shape adapters (URL, document-binary, document-text, qa-docx, rss-discovery) with specific extraction logic. mempalace’s miner is generic — it would not handle URL ingest, would not call unpdf/mammoth for binaries, would not extract Q&A pairs from docx tables.
• mempalace is filesystem-rooted (Path inputs throughout); KH operates on Supabase blobs and inline content.
• Schema mismatch: mempalace drawers vs KH content_items / content_chunks.
• Same conclusion as graphify Option E: don’t.

Verdict: don’t. Shapes A + B capture the design value without integration cost.

5.5 What this implies for canonical pipeline + re-ingest

• Canonical pipeline: Shape A (temporal validity columns on entity_relationships) complements the canonical-pipeline plan and should land alongside re-ingest. Re-ingest is the natural moment to populate valid_from from content_items.captured_date (per Q1 ratification: ingest-time stamp).
• Re-ingest: Shape B (strict-extraction MCP mode) is independent of canonical pipeline — pure new MCP tool. Could ship in Stream 1 (~1.5 days) regardless of A1 ratification.
• Phase D (ai_call_log): Shape A + B unaffected. Shape C (per-user memory) would need ai_call_log to track mempalace-mediated interactions — defer.

5.6 PostgreSQL backend roadmap (v4-alpha)

POST-S229 UPDATE (S230 WP8): v4-alpha has NOT shipped — three days after the 2026-05-08 eval date, mempalace remains on v3.3.5 (latest PyPI tag as of 2026-05-11). PR #665 (PG backend) and PR #1337 (HttpChromaBackend) are still open against main/develop. Separately, the mempalace_search “BROKEN upstream” gotcha referenced elsewhere in this doc is now FIXED in v3.3.5 (PR #1396 — retry-on-transient + drift-segment auto-quarantine, verified 2026-05-11). See 0.9-spike-S15-mempalace-v5-upgrade.md for the full empirical verification and decision-gate G15 = NO UPGRADE.

Per ROADMAP.md, v4-alpha (this week from mempalace’s POV) ships:

• PostgreSQL backend with pg_sorted_heap support (#665) — for production deployments needing ACID, concurrent access, standard backup/restore.
• LanceDB backend (#574) — for local-first deployments with multi-device sync.
• PalaceStore (#643, draft) — bespoke storage layer.
• Hybrid search keyword fallback (#662) — already in scope.
• Time-decay scoring (#337).

Implication for KH: if Shape D becomes interesting post-launch, the v4-alpha PG backend is the right hook — track it. Until then, Shape A + B don’t depend on it.

5.7 Direct mapping to kh-client-feedback.md

Client feedback (29 Apr)	mempalace pattern	KH application
Item 1 — list_user_workspaces returns array, schema declares record. Client cannot scope to LMS-only content.	mempalace_search has wing= filter that always scopes (cannot accidentally cross wings)	Shape B’s strict-extraction tool should require workspace_id parameter; reject unscoped calls or surface explicit cross_workspace=true flag
Item 2 — search misses good answers (FUNC-032 PCI, FUNC-025 Java stack). Causes: content_type mismatch, semantic gap (PCI-DSS vs payment providers), default limit=5, domain filter too restrictive	mempalace’s hybrid BM25+vector search beats pure-vector by 30-40 pp on ConvoMem (Mem0 30-45% vs mempalace 92.9%); BM25 catches exact terms vector misses	KH’s existing pgvector setup needs BM25 hybrid layer. PostgreSQL has tsvector — add to_tsvector(content) GIN index on content_chunks and combine with vector score in retrieval RPC. This is a Shape A/B-adjacent fix that lands in canonical-pipeline.
Item 3a — “AI confidently pulling correct content from the wrong domain” (Bitdefender to data-at-rest, office-physical to data-centre-physical)	mempalace wing is a hard scope; MCP tools cannot cross wings without explicit user opt-in	Shape B scope_tag column on content_items. Mandatory in every search result. Anti-tags (“does not apply to: production-infrastructure”) match mempalace’s tunnel/anti-tunnel concept
Item 3b — “AI safety needs hub to enforce citation, not just answer” — strict extraction mode that returns only matching chunk + source ID, refuses to invent or paraphrase	mempalace’s “verbatim always” is the architectural answer. From their CLAUDE.md: “We never summarize. We never paraphrase. We return your exact words. 100% recall is the design requirement”	Shape B strict-extraction MCP tool. Direct lift of mempalace’s design principle into KH’s MCP surface

The convergence is striking: mempalace shipped (a year before KH) the exact pattern client just asked for in Item 3. This is the strongest signal in the evaluation that re-use of mempalace’s design wins over reinvent.

5.8 What this implies for the KH product story

KH’s pitch is “high-quality, structured data accessible by AI.” MemPalace’s pitch is “100% recall is the design requirement — your exact words, instantly retrievable.”

These are convergent, not adjacent. Both are answers to the same question: how do you make knowledge AI-consumable without losing fidelity? KH’s canonical-pipeline + re-ingest work is a structural answer (typed columns, side-channel writes, version-chained source_documents). MemPalace’s verbatim-storage is a retrieval answer.

If KH adopts Shape A + B:

• Pitch widens to “high-quality structured data + temporal knowledge graph + strict-extraction citation, accessible by AI.”
• Direct response to client feedback Item 3 (citation, scope tags, anti-tags).
• Aligns with industry direction (Zep, Graphiti, mempalace, OMEGA, Mastra all converging on temporal-KG + verbatim-first).

5.9 Verdict — Lens 2

Recommended: Shape A (temporal-KG schema) + Shape B (strict-extraction MCP mode), NOT Shape C/D/E.

• Shape A lands as a small migration during canonical-pipeline foundation (Phase A in §5.2 of 0.7-synthesis). Adds valid_from, valid_to, confidence, source_drawer_id (rename to source_content_item_id for KH naming), adapter_name to entity_relationships. RPCs kg_query_as_of(entity, date), kg_invalidate(subj, pred, obj, ended_at), kg_timeline(entity).
• Shape B lands as a Stream 1 candidate (~1.5 days): new search_knowledge_base_strict MCP tool that returns verbatim chunk + content_item_id + scope_tag, no rephrasing. Plus scope_tag column on content_items per client Item 3. Pairs with confidence on entity_relationships.
• Shape C/D/E deferred or rejected.

This is NOT a “defer to post-launch” verdict (per framing corrections). Shape A + B are pre-launch work. The size is small (~3-4 days combined) and the strategic alignment with client feedback Item 3 + AI-strategy is strong.

Confidence: 80%. Sub-90% because: (a) the temporal-KG semantics need eval-driven prompt rules to fill validity windows correctly during Pass 2 — non-trivial; (b) scope_tag taxonomy for KH is unspecified (client suggested 5: internal-it / production-infrastructure / application-layer / office-physical / data-centre-physical); (c) Shape B’s strict-extraction mode interaction with the existing search_knowledge_base semantics needs design.

5.10 Effort + cost (Lens 2)

Shape	Effort	Token cost	Reversibility
A — Temporal-KG columns on entity_relationships	~1 day migration + 2-3 days RPC/Pass-2/readers	0 (schema)	Drop columns
B — Strict-extraction MCP tool + scope_tag column	~1.5 days	0 (additive)	Drop tool + column
A + B combined, in canonical-pipeline Stream 1	~3-5 days	0	Reversible
C — Per-user memory (option b: local plugin)	~1-2 days	0	Plugin uninstall
D — Fork v4-alpha PG backend	~2-4 weeks	0	Drop fork
E — Wholesale embed	(rejected)	n/a	n/a

---

6. Re-use vs integrate vs reinvent — consolidated verdict

Per the framing correction “BIAS toward re-use of battle-tested infrastructure”, here is the explicit verdict matrix per artefact:

mempalace artefact	Verdict	Why
CLI (mempalace mine/search/wake-up)	Re-use (Lens 1, Shape C)	Battle-tested, free, MIT, fully reversible. No reason to reinvent.
Stdio MCP server (29 tools)	Re-use locally (Lens 1) — local Claude Code only	Stdio incompatible with Claude.ai web. Re-use for dev-workflow only.
Stop / PreCompact hooks	Re-use (Lens 1)	Solves the “tokens wasted on bookkeeping” problem we already feel.
Auto-mine of session JSONLs (convo_miner.py + _try_claude_code_jsonl)	Re-use (Lens 1)	Format-aware Claude Code JSONL parser is non-trivial; reinventing wastes weeks.
Hybrid BM25 + vector search (searcher.py)	Borrow design, reinvent in Postgres (Lens 2) — KH already has pgvector + can add tsvector GIN. Don’t fork the Python.
Temporal KG schema (triples table)	Borrow design (Lens 2, Shape A)	The schema is the value. Implementation is straightforward in PG.
Verbatim-first design principle	Adopt as KH platform principle (Lens 2, Shape B + MP4)	Already implicit; make explicit. Aligns with client Item 3.
scope_tag / wings concept	Adapt (Lens 2, Shape B)	Design pattern lift; KH-specific taxonomy needed.
AAAK closet compression	Skip	KH has summary_data + content_chunks already; AAAK is a closet-layer optimisation we don’t need.
PostgreSQL backend (v4-alpha)	Watch, don’t fork (Lens 2, Shape D)	Track stability post-launch; revisit if Shape C demand surfaces.
Wholesale embedding into KH ingestion	Reject (Shape E)	Schema mismatch; mempalace is filesystem-rooted; KH canonical pipeline is already the right shape.

Net for re-use vs reinvent:

• Re-use the dev-workflow integration verbatim (CLI + plugin + hooks).
• Borrow the design principles (temporal KG, verbatim-first, scope_tag, hybrid BM25+vector) into KH-native Postgres implementations.
• Reject wholesale fork of mempalace code into KH platform — schema and runtime constraints (Vercel, Supabase, multi-tenant, 1024-dim embeddings) don’t match.

The “best-benchmarked” claim holds. MemPalace’s headline 96.6% R@5 on LongMemEval with zero LLM calls is the highest published retrieval-recall number for an open-source memory system as of May 2026, and the architectural insight (verbatim storage beats LLM-extraction systems by 2× on ConvoMem) is well-supported. The benchmark framing in their own BENCHMARKS.md is unusually honest — they explicitly call out the “100% R@5” tuned number as “teaching to the test” and prefer the held-out 98.4% as the generalisable figure. This is the integrity standard we want to model in KH’s own eval work (per feedback_eval_prompt_rules_surgical.md + feedback_self_silencing_failure_class.md).

---

7. Recommendations

7.1 Dev workflow (Lens 1)

1. Adopt Shape C (verbatim transcript layer only): install mempalace CLI + Claude plugin + Stop hook, mine ~/.claude/projects/.../{*.jsonl,memory/}. Do not touch existing MEMORY.md curation.
2. Update assistant guidance: add one paragraph to CLAUDE.md or session-start skill: “Before grepping ~/.claude/projects/<project>/memory/ or session JSONLs for prior context, call mempalace_search first.”
3. Single shared palace with per-worktree wings (worktree-content-items, worktree-prod-readiness, worktree-knowledge-platform, worktree-main) so cross-worktree recall works.
4. Validate before committing: run 5-10 representative queries through both mempalace_search and the current grep approach; compare quality. If mempalace doesn’t beat grep on KH-specific terminology (e.g., “OPS-X-CLASSIFY-UI”, “P0-1 silent-fail”), revisit.

7.2 Platform (Lens 2) — pre-launch

1. Adopt Shape A (temporal-KG schema on entity_relationships) as part of canonical-pipeline Phase A foundation. Re-ingest is the natural moment.
2. Adopt Shape B (strict-extraction MCP tool + scope_tag column) as a Stream 1 work item — direct response to client feedback Item 3. ~1.5 days.
3. Skip Shape C/D/E pre-launch.

7.3 Platform (Lens 2) — post-launch backlog candidates

1. OPS-MP1 — Conversation memory layer (Shape C option b, local plugin). After v1 launches and we observe whether users actually ask “remember last session” questions. Gate on: real user demand, not theoretical.
2. OPS-MP2 — Track v4-alpha PG backend (Shape D candidate). Watch mempalace #665 + #574 for stability; revisit if KH wants to back retrieval with mempalace’s hybrid search + temporal KG without re-implementing.
3. OPS-MP3 — Multi-org wings model. If post-launch we discover per-org palaces are useful, design a multi-tenant wings layer over mempalace. Currently theoretical.

7.4 Specific decisions for Liam

ID	Decision	Recommendation	Confidence
MP1	Install MemPalace as Claude Code dev tool (Shape C — verbatim transcript layer)?	Yes — half-session install, fully reversible, addresses cross-session search gap	88%
MP2	Add valid_from / valid_to / confidence / source_content_item_id columns to entity_relationships (Shape A)?	Yes — pre-launch, in canonical-pipeline Phase A	82%
MP3	Ship strict-extraction MCP tool + scope_tag column (Shape B)?	Yes — pre-launch, Stream 1, ~1.5 days	85%
MP4	Adopt mempalace’s design principle “verbatim always, never summarize” as a KH platform principle?	Yes — already implicit in canonical-pipeline + content_chunks design; make it explicit in ai-strategy doc	90%
MP5	Per-user / per-organisation memory (Shape C option b plugin)?	Defer to post-launch backlog OPS-MP1	75%
MP6	Fork v4-alpha PG backend (Shape D)?	Watch upstream; revisit post-launch	85%
MP7	Migrate existing memory/ dir into mempalace (Shape B from Lens 1)?	No — Liam’s editorial curation is irreplaceable	92%

---

8. Open questions

1. Stop-hook reliability under Claude Code’s evolving plugin spec. The ~/.claude/plugins/marketplaces install is stable but plugin spec changes (per CLAUDE.md worktree gotchas: .claude/plugins/* gitignored except knowledge-hub/). What’s the version-stability story across Claude Code updates?
2. Single shared palace vs per-worktree. Per-worktree gives clean isolation; single-shared gives cross-worktree recall. Recommend single-shared with --wing partitioning, but worth validating with first-week of use.
3. KH scope_tag taxonomy. Client suggested 5 (internal-it / production-infrastructure / application-layer / office-physical / data-centre-physical). Need to ratify against the Phew library’s actual content distribution before implementing Shape B.
4. mempalace v4-alpha timing. v4-alpha is “this week” from mempalace’s POV — does that affect MP6? If Shape D becomes interesting fast, we want to track v4 stability rather than v3.
5. Embedding-model parity. mempalace’s local 384-dim all-MiniLM-L6-v2 is significantly weaker than KH’s text-embedding-3-large 1024-dim. For dev-workflow recall it’s fine (LongMemEval 96.6% R@5 says so). For platform retrieval over the KB, we’d never replace KH’s embeddings with mempalace’s — Shape D would mean keeping KH’s embeddings as the vector layer with mempalace’s hybrid BM25 boost on top.
6. Shape A confidence column overlap with classification_confidence. KH already has entity_mentions.classification_confidence (numeric). mempalace’s KG confidence is also numeric. Naming clash — recommend kg_confidence on entity_relationships to disambiguate, or unify with the graphify-eval Option C provenance enum (EXTRACTED/INFERRED/AMBIGUOUS). Three converging signals (numeric classification_confidence from Pass 2, categorical provenance from graphify, numeric kg_confidence from mempalace) is too many — design one column that does both.
7. source_content_item_id vs source_drawer_id naming. mempalace uses source_drawer_id; KH equivalent is source_content_item_id (or chunk-level source_chunk_id). Recommend KH naming for the migration.

---

9. Confidence assessment

Section	Confidence	Reason
§1 What it is	95%	Sourced from README + CLAUDE.md + MISSION.md + ROADMAP.md + module inspection
§3 Architecture summary	92%	Sourced from mempalace/ module reads (mcp_server.py, knowledge_graph.py, convo_miner.py, normalize.py, embedding.py, palace.py, hooks_cli.py, searcher.py); no grounded run
§3.4 Benchmarks	90%	Numbers from official BENCHMARKS.md + cross-referenced WebSearch; comparison context from public sources
§4 Lens 1 dev workflow	85%	Recommendation rests on inferred recall quality on KH JSONL data — not measured
§5 Lens 2 platform value	80%	Shape A + B are well-grounded design borrows; semantic interpretation of valid_from for KH content needs prompt-engineering work not scoped here
§6 Recommendations	86%	Sequencing follows from canonical-pipeline plan + framing corrections
§7 Open questions	85%	Per-item confidence in §6.4

Overall evaluation confidence: 84%.

Items below 90%:

1. Lens 1 recall quality on KH-specific terminology (85%) — LongMemEval data is conversation-style; KH terminology is technical. BM25 fallback should mitigate but unmeasured.
2. Shape A temporal-validity prompt engineering (75%) — populating valid_from / valid_to from Pass 2 classification needs eval-driven prompts not yet specified.
3. Shape B scope_tag taxonomy (78%) — needs ratification against actual client content distribution.
4. Shape C multi-tenant model (70%) — mempalace single-user design centre is a real constraint.
5. v4-alpha PG backend stability (70%) — moving target.
6. Three-confidence-signals overlap (75%) — classification_confidence + provenance + kg_confidence need unification design.

---

10. Appendix — sources reviewed

• README.md (top-level)
• CLAUDE.md (mission + design principles + structure)
• MISSION.md (founder narrative)
• ROADMAP.md (v3.1.1 + v4-alpha)
• benchmarks/BENCHMARKS.md (full progression + caveats)
• .claude-plugin/plugin.json, .mcp.json, hooks/hooks.json, skills/mempalace/SKILL.md, commands/{help,init,mine,search,status}.md, hooks/mempal-stop-hook.sh
• mempalace/mcp_server.py (29 tool surface)
• mempalace/cli.py (14 subcommands)
• mempalace/knowledge_graph.py (temporal KG schema)
• mempalace/convo_miner.py (Claude Code JSONL ingest)
• mempalace/normalize.py (_try_claude_code_jsonl + NORMALIZE_VERSION=2)
• mempalace/embedding.py (ONNX provider factory)
• mempalace/palace.py (SKIP_DIRS + collection access)
• mempalace/hooks_cli.py (Stop / PreCompact / SessionStart hook logic + STOP_BLOCK_REASON / PRECOMPACT_BLOCK_REASON)
• mempalace/searcher.py (hybrid BM25 + vector search; Lucene/BM25+ smoothed IDF)
• WebSearch: LongMemEval comparison context (Mem0 ~49%, Zep 63.8%, Letta ~83%, Mastra 94.87%, OMEGA 95.4%)
• KH local: ~/.claude/projects/-Users-liamj-Documents-development-knowledge-hub/ (103 memory files, 524 KB; 189 session JSONLs, 681 MB)
• Phase 0.7 context: 0.7-synthesis.md, 07-synthesis-feedback.md, graphify-evaluation-feedback.md, trpc-evaluation-feedback.md, kh-client-feedback.md (Item 3 verbatim)

Not reviewed (out of scope for source-only evaluation): grounded run on KH data, install footprint validation, performance characterisation, multi-language entity disambiguation, or v4-alpha PG backend.

---

End of MemPalace evaluation. 84% overall confidence. 7 open questions surfaced for parent ratification (MP1-MP7 in §7.4).