David F GliddenandClaude Opus 5
ef6fa94dcd
The record is updated where information ARRIVES and never where a reader LOOKS.
Three instances found the same day, each with the correct information already
written down elsewhere:
REVIEWED-81 (AUTHORIZED 07-28) -> PENDING-81 still reads open
the ARC open-work register, which -> those 6 trackers still read live
says in its own description that
it supersedes them, with a
per-file verified verdict
register entry A2: "the content -> register entry B3, one page below:
half (B3) is now unblocked + "[OPEN - gated on A2]"
started" (06-17)
The third is the sharpest: both halves sit in the SAME document, so no tooling
gap explains it. ~/CLAUDE.md already rules this under Memory Discipline
("mark the superseded record as superseded"); the rule is being applied to facts
and not to trackers, PENDING items or register entries, which are also facts
about state.
Executed under steward authorization, arrears only:
- 16 trackers stamped `superseded_by:` + `superseded_on:` AND a visible in-body
banner. The banner is the point — metadata alone repeats the defect, since the
finding is about what a reader sees. 9 obsoleted by the 2026-07-07 MemPalace
wind-down; 7 already carrying the register's own verified `DONE-retire`.
- B3's label corrected, with the two-month error left visible rather than
silently amended.
- Nothing moved, renamed or deleted: 381 pointers resolve, 0 dead, 0 mis-authored.
HARVESTED BEFORE STAMPING, and this is why the harvest came first:
`project-mempalace-library-incremental-remine-strategy` carried a steward-verbatim
rule that is instrument-independent — never run a single multi-day index; order by
criticality; gate each tranche on READBACK, not on write-success (933,576 drawers
once stored successfully and could not be read back at all). It lived only inside
a MemPalace tracker, so retiring the instrument would have retired the rule with
it. ~/CLAUDE.md names that exact hazard: "state the obligation first and the
instrument second, or the next retired tool takes a rule down with it." Now
`feedback-bulk-indexing-runs-incrementally-with-readback.md`, and it applies to
studium-engine corpus work.
Held back deliberately: 2 correctly-parked files with named dependencies, 2 named
nowhere (returned to the steward), and 39 trackers unread — recorded as a gap,
not as a finding.
Measurement note: every earlier estimate of tracker staleness was wrong, because
both mtime and git-last-commit were reset across 283 files by the 2026-06-06
normalization sweep. The honest figure excludes it: median 90 days.
Filed as PENDING-142 ADDENDUM 2 per steward direction (fold, do not file anew).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4
8.3 KiB
name, description, metadata, permalink, superseded_by, superseded_on
| name | description | metadata | permalink | superseded_by | superseded_on | ||||
|---|---|---|---|---|---|---|---|---|---|
| mempalace-operational-stance-post-1526 | Operational stance toward MemPalace going forward — proper-scope use for AI session continuity (diary + KG + handoffs), not corpus reading. Currently on local fork v3.3.5 + 3 PR |
|
claude-memory/project-mempalace-operational-stance-2026-05-16 | project-mempalace-winddown.md + studium-engine docs/seed-brief.md | 2026-08-17 |
SUPERSEDED 2026-08-17. The MemPalace half is retired. The live half — the two-layer split between session continuity and voice-attributed corpus consultation — is carried more fully in the studium-engine seed-brief §3.2–3.3, which states it as one architecture asked to do two jobs.
Current record: project-mempalace-winddown.md + studium-engine docs/seed-brief.md. Kept for detail and provenance — do not read the status below as live.
MemPalace operational stance (post-issue-#1526)
The two-layer architecture
After 2026-05-15's Studium Engine recompose, the operational division is explicit:
- MemPalace = substrate of AI session continuity. Diary entries, KG facts, session handoffs, working memory accumulated across sessions. The verbatim guarantee at its core is the right primitive for this scope. Design center: USER + TIME.
- Studium Engine (in design at
~/_Dev/studium-engine/) = substrate of voice-attributed scholarly corpus consultation. The dialogical reading work that MemPalace was being asked to do but couldn't. Design center: VOICE + ARGUMENT.
They don't compete; they handle different work. MemPalace's failure mode last week was being asked to do the Engine's job. With the Engine on the way, MemPalace can return to its proper scope.
The two layers are not in tension; they are the answer to a single architectural confusion that resolved 2026-05-15.
Current install state
- MemPalace version:
v3.3.5 + 3 local commitson branchlocal/bge-m3-on-3.3.5 git describe:v3.3.5-3-g604df3b-dirty- Local commits atop tag:
975acba— swap embedding to BAAI/bge-m3 on MPS (3.3.5 base)5458b77— stamp embedding_model into collection metadata (#442 contract)604df3b— raise MAX_CHUNKS_PER_FILE 500→50_000 for full-text scholarly corpora
- chromadb: 1.5.8 · sentence-transformers: 5.4.1 · torch: 2.11.0 with MPS available
- Active palace:
~/.mempalace/palace-chamber-typography/(40,924 drawers; MCP wired here per~/.claude.json) - Failed-palace tarballs preserved at
/Volumes/Temp storage 2020/mempalace failed palaces/(built 2026-05-16) — for diagnostic reference; not in active use
Hooks (state 2026-05-16, restored)
The Stop + PreCompact hooks were disabled 2026-05-14 ("until mine completes") and silently never restored — surfaced 2026-05-16, fixed same session. Now active in ~/.claude/settings.json under hooks.Stop and hooks.PreCompact:
- Stop hook →
~/_Dev/mempalace/hooks/mempal_save_hook.sh(timeout 30s). Fires every Stop event; internally counts human messages viaSAVE_INTERVAL=15in the script body — only triggers a save when ≥15 human messages have accumulated since the last save. This IS the "every 15 messages" behavior. - PreCompact hook →
~/_Dev/mempalace/hooks/mempal_precompact_hook.sh(timeout 30s). Fires before context compression; emergency save mining the transcript + forcing diary write before state is lost. - Other hooks (BMF, unrelated to MemPalace): SessionStart, UserPromptSubmit, PostToolUse all run
node ~/_Dev/BetterMemories.io/hooks/cm-hook.mjs— these are BetterMemories L1 work and are independent. Stay enabled.
Backup of pre-restore state: ~/.claude/settings.json.backup-2026-05-16-100737-pre-hook-restore.
Why the local fork is operationally fine for working-memory scope
The two failure modes named in issue #1526 — Mode 1 (cascade) and Mode 2 (silent-empty-index) — are scale-and-corpus-shape-specific. Neither fires on working-memory use:
- Mode 1 (cascade) triggers only when a single source's embed time exceeds 300s. Diary entries are ~1KB; KG facts are tinier; session handoffs are at most a few KB. Each embeds in milliseconds. Cascade conditions are structurally impossible at this scale.
- Mode 2 (silent-empty-index) matters when a palace grows past brute-force tolerance without ever reaching the 50k-drawer batch threshold. A working-memory palace might reach 50k within a year or two of regular use; before that, brute-force vector search is fine. If queries start feeling slow, manual
mempalace repair --mode from-sqliterebuilds the index. Not auto-prompted, but easy.
The "not the official build" worry is real for production systems where divergence is costly — multi-developer teams, deployed services, compliance contexts. For a personal working-memory substrate where the steward owns all the failure modes and can fix them in place, the fork is just this build — a small, traced patch series on a known base. The discipline already in place (issue #1526 filed, PR #442 informed, environment block documented, tarballs preserved) is the right discipline for living on a personal fork responsibly.
Decision triggers — when to revisit
The stance is "keep as-is" until one of the following fires:
- PR #442 merges upstream → consider upgrading to the official release that includes it. Local fork can retire; the three patches above are now in the official build.
- Issue #1526 gets a fix in a release → upgrade to that release. Cascade-mode protection is welcome at any scale.
- Adding 10–20 new books to the working memory → safe as long as no single source crosses the cascade trigger (>5 MB plain text combined with multi-hour embed). Most modern EPUBs after
pdf-text-layercleaning come in well under that. - Queries start feeling slow → run
mempalace repair --mode from-sqlitemanually. Or checklink_lists.binsize and themax_seq_idparity directly if curious about state. - A maintainer responds to #1526 or to the PR #442 comment → action depends on their response (acknowledgment / fix in flight / hold-for-major-release / reject).
The /wake-up procedure's existing mempalace upgrade check (step 2.e) surfaces upstream activity each session. So triggers 1 and 2 are already monitored automatically.
What to avoid
- Rolling back to pure v3.3.5 just for cleanliness — you'd lose multilingual bge-m3 retrieval (daily work mixes EN/FR/ES across diary entries) for a non-problem.
- Waiting for #1526 to be fixed before further MemPalace use — failure modes don't apply to the workload pattern. Use it.
- Re-mining anything from chamber-library into a MemPalace palace — the Studium Engine is the right tool for that work. Don't conflate.
Cross-references
- Forensic preserving the failure evidence:
~/_Dev/studium-engine/docs/origin-evidence/2026-05-16-chamber-mine-hnsw-failure.md - Architectural lessons folded into Engine design:
~/_Dev/studium-engine/docs/origin-evidence/2026-05-16-studium-engine-architectural-implications.md - Upstream issue draft (before posting):
~/_Dev/studium-engine/docs/origin-evidence/2026-05-16-upstream-issue-draft.md→ filed as #1526 - PR #442 follow-up comment: filed at https://github.com/MemPalace/mempalace/pull/442#issuecomment-4466225623 (2026-05-16)
- Failed-palace tarballs:
/Volumes/Temp storage 2020/mempalace failed palaces/(4 palaces, ~21 GB source, building 2026-05-16) - Hook restoration audit + fix: this file. Backup of pre-restore settings at
~/.claude/settings.json.backup-2026-05-16-100737-pre-hook-restore.
Framing for future sessions
The strategic question — "what to do about MemPalace going forward?" — is settled. MemPalace is the steward's working-memory layer; the Studium Engine handles corpus. The local fork is operational and adequate for working memory; failure modes don't apply at that scale; upgrade when a trigger fires. The discipline is named conditions for action, not ambient anxiety about non-officialness.
If future-Claude finds the steward anxious again about the "non-official build," the right move is to re-state the decision-trigger framing, not to relitigate the strategic question.