Feature Request: Personal Memory Views and Memory Consolidation Layer

[unfall103-debug]

Background

SLM already provides a strong technical foundation: memory storage, retrieval, knowledge graph, lifecycle management, and structured fact extraction. However, from a user’s perspective, memory value depends not only on what the system stores, but also on how memories are organized and presented for each individual.

Different users have different priorities:

· A programmer may have 80% of memories about coding, projects, debugging, and technical decisions.
· A designer may care about design references, inspiration, and creative direction.
· A traveler may want travel plans, places, and experiences organized.
· A content creator may focus on topics, audience feedback, and ideas.

A universal importance score cannot fully represent every user’s personal priorities.

---

Proposed Feature 1: Personal Memory Views

Instead of forcing all memories into fixed categories, SLM could provide customizable memory views. The underlying memory system (events → facts, entities, skills, relations) remains unchanged; a user-defined layer generates different perspectives:

Memory Database
      |
      +-- Work Log
      |     +-- Projects
      |     +-- Coding
      |     +-- Decisions
      |
      +-- Personal Journal
      |     +-- Life Context
      |     +-- Plans
      |     +-- Preferences
      |
      +-- Interests
            +-- Games
            +-- Travel
            +-- Hobbies

Users could create custom profiles with a prompt.
Example:

Profile: Architecture Research
Prompt: Extract information related to architecture, design concepts, materials, references, and personal design preferences.

Profile: Gaming Memory
Prompt: Track games discussed by the user, including preferred genres, gameplay styles, favorite mechanics, and unfinished games.

---

Proposed Feature 2: Memory Consolidation / Reflection

Add a human-readable summary layer on top of existing memory. Instead of only storing individual facts, SLM could periodically generate:

· Session Summary (after a conversation)
“Today: analyzed SLM memory architecture, identified potential improvements, discussed personal AI workflow.”
· Daily Reflection (daily consolidation, similar to human memory consolidation)
“Main topics: local AI deployment, memory system design. Important progress: tested reranker endpoint, identified HTTP trust validation issue. New ideas: personal memory views, work/life memory separation.”
· Project Work Log (for coding and technical workflows)
“Project: SuperLocalMemory. Completed: tested OpenAI-compatible endpoints, configured local embedding model. Issues: HTTP security validation blocks LAN reranker. Next step: wait for upstream fix.”

---

Why This Matters

Current knowledge graphs and memory retrieval are powerful for machines, but not always intuitive for humans. Users usually don’t want to manually browse nodes and relationships. They want answers like:

· “What have I been working on recently?”
· “What changed in this project?”
· “What are my current interests?”
· “What decisions did I make last month?”

The goal is not to replace the existing graph memory system, but to add a user-facing interpretation layer.

---

Suggested Architecture

Keep the current memory engine:

Raw Events
    │
    ▼
Memory Processing
    │
    ├── Facts
    ├── Graph
    └── Skills

Add an optional consolidation layer:

Processed Memory
        │
        ▼
Personal Memory Views
        │
        ├── Daily Journal
        ├── Work Logs
        ├── Project Summaries
        └── Custom User-defined Views

---

Final Thought

The long-term goal of personal AI memory should not only be “remember more information” — it should become “understand what information matters to this specific person.” A customizable memory view system would allow SLM to evolve from a memory database into a true personal AI memory assistant.

[varun369]

Thank you — this is a strong direction and it aligns with the product work underway around making a personal memory system understandable, not merely searchable.

V4 already has useful foundations: isolated profiles, thematic scenes and cluster views, session summaries, and cognitive consolidation. We are working on the user-facing layer that can turn those primitives into intentional personal views and bounded work, project, and reflection summaries.

The important design constraint is user control: views must be customizable, profile-scoped, privacy-aware, and traceable back to the underlying memories rather than becoming opaque generic summaries. We are keeping this issue open as the design thread while we shape the model, scheduling, and interaction flow. The examples here are valuable input for that work.

[varun369]

4.0.6 landed part of Feature 2. Being exact about which part, because the changelog was not.

Running for you now — entity-level consolidation. Repeated facts about the same entity are merged during maintenance, and the originals are archived rather than deleted, so a merge stays reversible and traceable.

Written but not reachable — the three summaries you specified. Session Summary, Daily Reflection and Project Work Log are implemented and tested. Each result carries the fact ids it was built from, the profile it belongs to, and an explicit coverage figure, so a thin summary says it is thin instead of reading as complete. What 4.0.6 does not have is any way for you to ask for one: no command, no MCP tool, no route. The engine shipped; the surface did not. That is a miss on our side, the changelog entry is being corrected, and 4.0.7 exposes it.

One number from building it, because it shapes what Session Summary can honestly claim: only about 4% of facts on a real store carry a session id. So Session Summary reports its coverage rather than presenting a summary of 4% of a session as a summary of the session. Project Work Log is scoped by tool-event project path for the same reason — the obvious field to scope by turned out to hold a single distinct value across the whole store.

Feature 1 — prompt-driven custom views: not started. Worth saying why rather than leaving it implied. A user-supplied prompt running over your own memories is non-deterministic, hard to trace back to specific facts, and is an injection surface pointed straight at the store. Traceability is the constraint I am not willing to drop, so this needs a design where a custom view is still explainable — which is what the profile examples in your issue are useful for.

Staying open as the thread for that.

[varun369]

Thanks for this — it is a well-argued design proposal, so a straight answer rather than a queue.

Not in 4.1.0, and not planned as specified. Leaving it open as a design discussion rather than closing it.

Where I agree: a single global importance score cannot represent what any particular person cares about. That premise is right, and 4.1.0 moves toward it from a different direction — recall now records which memories it actually returned for a query, and an outcome reported against an answer is matched to that exact answer rather than guessed at from overlap in a time window. That gives per-memory usefulness a real signal for the first time. It learns your priorities from what you use instead of asking you to declare them up front.

Where I am unconvinced by the proposal as written: Personal Memory Views as user-declared categories moves curation work onto the person, and the failure mode is that the categories go stale while the memories keep arriving. The programmer/designer/traveller split is a good illustration of the problem but I do not think it is the shape of the solution — those are labels a system should infer, not a form to fill in.

What I would want before building anything here:

1. What does a view do that a saved query does not? If the answer is "it persists and it ranks", that is a smaller feature with a clearer contract.
2. Is the consolidation layer you describe distinct from what runs today? There is already a consolidation pass — is your ask that it be visible and steerable, rather than that it exist?

If you can sharpen it to those two, I will treat it as a concrete proposal. Concretely: what would you type, and what would come back?

Genuinely appreciate the thought that went into this. It is a better issue than most feature requests.

[neurons-me]

Hi — I'm the author of .me. Your proposal for personal views over a shared underlying memory graph overlaps with something I've been building: a reactive semantic kernel with structural pointers, selectors, derived values, and path-bound encrypted scopes.

The potential fit is the view layer: referencing existing facts and deriving contextual views, with explain() exposing the dependency chain behind derived values.

This isn't a drop-in SLM integration — .me doesn't do prompt-based extraction or narrative consolidation itself. But it could work as a projection layer over a small set of SLM facts, without touching your memory engine.

Published benchmarks: Architecture docs — 1M nodes at ~380MB, 100k reactive recomputations from a single write in 6.3s.

Two write-ups worth a look for this specific proposal: Robots That Understand Context (same facts, different meaning depending on who's looking — the "personal views" case directly) and Social Graph (derived, reactive views over one shared graph, with structural privacy).

Would a minimal example — the same facts mapped into two different views — be useful here?