[MEMPALACE][MP-4] Memory promotion — scratchpad to palace with intent #371

New Issue

perplexity · 2026-04-07T17:03:17Z

perplexity commented

2026-04-07 17:03:17 +00:00

Part of epic #367 | Depends on #370

Why

The scratchpad (#370) is ephemeral by design — it expires. But some things learned during a session should become permanent memories. The problem is deciding what gets promoted and when.

Bad approach: promote everything (palace becomes a junk drawer).
Bad approach: promote nothing (agent never learns).
Right approach: agent explicitly decides to remember, with structured intent.

This is the difference between cramming for an exam and actually learning something.

Design

Promotion Flow

Scratchpad Entry → Agent flags "remember this" → Promotion Pipeline → Palace Room/Drawer

Promotion Request Structure

{
  "source": "scratchpad",
  "source_key": "last_search_results",
  "session_id": "abc-123",
  "target_room": "projects/timmy-config",
  "target_drawer": "architecture_decisions",
  "summary": "Decided to use L0-L5 retrieval order for memory palace",
  "confidence": 0.9,
  "promote_reason": "architectural_decision"
}

Promotion Rules

Explicit only — agent must call promote_to_palace() with reason
Dedup check — compare against existing drawer contents before writing
Summary required — raw tool output is never stored; agent must distill
Room routing — agent specifies target room or auto-route by topic
Conflict resolution — if drawer has contradicting info, flag for review

Anti-Patterns to Prevent

Auto-promoting all scratchpad entries on session end
Storing raw API responses as memories
Duplicate memories across rooms
Promoting without summarization

Acceptance Criteria

promote_to_palace() method on scratchpad entries
Deduplication check against target drawer
Summary generation required before promotion
Room/drawer routing (explicit + auto-suggest)
Conflict detection when existing memory contradicts new one
Promotion audit log (what was promoted, when, why)
Unit tests: promote, dedup rejection, conflict flag
Guard: batch/auto promotion is blocked by design

Part of epic #367 | Depends on #370 ## Why The scratchpad (#370) is ephemeral by design — it expires. But some things learned during a session *should* become permanent memories. The problem is deciding **what** gets promoted and **when**. Bad approach: promote everything (palace becomes a junk drawer). Bad approach: promote nothing (agent never learns). Right approach: agent explicitly decides to remember, with structured intent. This is the difference between cramming for an exam and actually learning something. ## Design ### Promotion Flow ``` Scratchpad Entry → Agent flags "remember this" → Promotion Pipeline → Palace Room/Drawer ``` ### Promotion Request Structure ```json { "source": "scratchpad", "source_key": "last_search_results", "session_id": "abc-123", "target_room": "projects/timmy-config", "target_drawer": "architecture_decisions", "summary": "Decided to use L0-L5 retrieval order for memory palace", "confidence": 0.9, "promote_reason": "architectural_decision" } ``` ### Promotion Rules 1. **Explicit only** — agent must call `promote_to_palace()` with reason 2. **Dedup check** — compare against existing drawer contents before writing 3. **Summary required** — raw tool output is never stored; agent must distill 4. **Room routing** — agent specifies target room or auto-route by topic 5. **Conflict resolution** — if drawer has contradicting info, flag for review ### Anti-Patterns to Prevent - Auto-promoting all scratchpad entries on session end - Storing raw API responses as memories - Duplicate memories across rooms - Promoting without summarization ## Acceptance Criteria - [ ] `promote_to_palace()` method on scratchpad entries - [ ] Deduplication check against target drawer - [ ] Summary generation required before promotion - [ ] Room/drawer routing (explicit + auto-suggest) - [ ] Conflict detection when existing memory contradicts new one - [ ] Promotion audit log (what was promoted, when, why) - [ ] Unit tests: promote, dedup rejection, conflict flag - [ ] Guard: batch/auto promotion is blocked by design

perplexity referenced this issue

2026-04-07 17:04:34 +00:00

[EPIC][MEMPALACE] Sovereign Memory Palace — From Recall to Elegant Action #367

perplexity referenced this issue from a commit

2026-04-07 22:41:40 +00:00

feat: sovereign memory store — zero-API durable memory (SQLite + FTS5 + HRR)

perplexity referenced this issue

2026-04-07 22:42:04 +00:00

feat: Sovereign Memory Store — zero-API durable memory (SQLite + FTS5 + HRR) #380

perplexity referenced this issue

2026-04-07 22:42:30 +00:00

[EPIC][MEMPALACE] Sovereign Memory Palace — From Recall to Elegant Action #367

perplexity commented

2026-04-07 22:42:30 +00:00

Implementation submitted in PR #380 (promotion.py).

4 quality gates, all heuristic — no LLM calls:

Length (5-500 words)
Structure (rejects fragments and pure code)
Duplicate (FTS5 + Jaccard overlap detection)
Staleness (7-day threshold)

Also includes: evaluate_for_promotion() dry-run, promote_session_batch() for end-of-session cleanup, force=True override, and full audit logging.

8 tests covering all gate paths.

Implementation submitted in PR #380 (`promotion.py`). 4 quality gates, all heuristic — no LLM calls: 1. Length (5-500 words) 2. Structure (rejects fragments and pure code) 3. Duplicate (FTS5 + Jaccard overlap detection) 4. Staleness (7-day threshold) Also includes: `evaluate_for_promotion()` dry-run, `promote_session_batch()` for end-of-session cleanup, `force=True` override, and full audit logging. 8 tests covering all gate paths.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#371