Step 6: Forgetting service — decay scoring, contradiction detection, and autonomous pruning

[Atharva-Kanherkar]

Summary

Add a forgetting service that:

• detects semantically related candidates when a new semantic memory is stored
• lets the host LLM or operator decide whether a contradiction actually exists
• periodically scores semantic, episodic, and procedural memories for keep / fade / prune
• safely prunes records and owned media without introducing broken references

This issue body supersedes the previous plan where they conflict.

Validated conclusions

1. Exponential decay is still the right default

Keep an exponential half-life model for memory retention. This is consistent with MemoryBank, FadeMem, and the broader forgetting literature.

2. Generic embedding similarity is candidate retrieval only

The current repo uses generic semantic embeddings. Those embeddings are suitable for recalling topically related memories, but they must not be treated as contradiction judges.

The safe design is still two-phase:

1. embeddings recall candidates
2. the host LLM or operator judges the logical relationship

3. Forgetting needs mutation primitives, not just scan + delete

The current stores can read, write, retrieve, and update access metadata, but they cannot yet:

• scan all records through the public interface
• delete arbitrary records through the public interface
• replace or mutate an existing record through the public interface

Fade and supersession both require mutation support.

4. Duplicate handling must happen before final bucket assignment

The forgetting cycle cannot:

1. score
2. bucket
3. then flag likely duplicates

That ordering leaves stale buckets. Duplicate or superseded records must either:

• be forced into the prune path before bucketing, or
• trigger a second bucketing pass

5. Prune order should be DB first, media second

Delete the ChromaDB record first, then delete owned media. If media deletion fails, log the orphan and continue. That leaves no live record pointing at a missing file.

6. CLI should call the API for forgetting operations

The forgetting cycle should run inside the API service rather than through a second local CLI process opening the same persistent Chroma database. There are open Chroma reports where get() and vector query() diverge across processes on the same persistent store.

7. Reuse the existing event surface

The repo already has an in-memory event recorder and /api/events. Forgetting should extend that surface rather than introduce a parallel history subsystem in v1.

Store capabilities required first

Before any forgetting logic, the store layer needs:

• get_all_records(include_embeddings: bool = False) -> list[MemoryRecord]
• delete(record_id: str) -> None
• replace(record: MemoryRecord) -> None or update_record(record)

This is a hard dependency for the rest of Step 6.

Updated architecture

flowchart TD
    subgraph "Real-time semantic store path"
        A[Store semantic memory] --> B[Use stored embedding to find related candidates]
        B --> C[Return potential_contradictions to caller]
        C --> D[Host LLM or operator judges]
        D -->|Confirmed replacement| E[Resolve supersession]
        D -->|No contradiction| F[No mutation]
    end

    subgraph "Batch forgetting cycle"
        G[Scan all stores] --> H[Find likely duplicate semantic pairs]
        H --> I[Build forced-prune / forced-zero-importance set]
        I --> J[Compute decay score with one snapshot time]
        J --> K[Bucket keep / fade / prune]
        K --> L[Execute writes and deletes]
        L --> M[Emit events and return report]
    end

Loading

Updated sub-issue map

• 6A: Store interface extensions — scan, delete, and record mutation #41 — store scan, delete, and mutation primitives
• 6B: Decay scoring function #42 — pure decay-scoring helper
• 6C: Contradiction detection — similarity candidates and supersession flagging #43 — contradiction candidate retrieval and supersession resolution
• 6D: Pruning cycle — scan, score, fade/prune, media cleanup #44 — forgetting cycle, likely-duplicate handling, fade/prune, media cleanup
• 6E: API endpoints, events, CLI, UI, and full integration test #45 — API, events, CLI-as-client, UI, and deterministic integration coverage

Updated delivery order

1. 6A: Store interface extensions — scan, delete, and record mutation #41 — store primitives
2. 6B: Decay scoring function #42 — decay scoring
3. 6C: Contradiction detection — similarity candidates and supersession flagging #43 — candidate retrieval + supersession resolution
4. 6D: Pruning cycle — scan, score, fade/prune, media cleanup #44 — forgetting cycle
5. 6E: API endpoints, events, CLI, UI, and full integration test #45 — API/UI/CLI wiring and end-to-end tests

Decisions locked for v1

Decision	Why
Exponential decay	Supported by the cited memory systems and forgetting literature
Generic embeddings only recall candidates	Safe with the current embedding stack
No auto-delete from semantic similarity alone	Similarity is not contradiction judgment
Importance floor for critical memories	Preserves durable facts
DB delete before media delete	Safer failure mode
Batch deletes	Reduces long lock windows
CLI calls API for forgetting	Avoids multi-process Chroma consistency risk
Reuse /api/events	Existing surface already exists in the repo

References checked during research

• DeepMind AGI framework PDF, Section 7.5.5
• MemoryBank: https://arxiv.org/abs/2305.10250
• FadeMem: https://arxiv.org/abs/2601.18642
• The Semantic Illusion: https://arxiv.org/abs/2512.15068
• SparseCL: https://arxiv.org/abs/2406.10746
• Chroma tombstone issue: [Feature Request]: HNSW index pruning chroma-core/chroma#2594
• Chroma multi-process inconsistency issue: [Bug]: Query does not match Get on persistent DB accessed by two processes. chroma-core/chroma#3792

[m13v]

the two-phase design (embeddings recall candidates, LLM judges contradiction) is the only approach that actually works at scale. we tried skipping the LLM judgment step and using embedding similarity alone for contradiction detection, and it was a disaster. 'I prefer dark mode' and 'I prefer light mode' have high similarity but opposite meaning. the embedding step correctly surfaces them as candidates, but only the LLM can tell they contradict.

for the decay scoring, one nuance: not all memory types should decay at the same rate. factual preferences ('user lives in SF') should have near-zero decay, while behavioral patterns ('user usually writes code at night') should decay faster because habits change. we solved this by storing a decay_rate_override per memory category. semantic memories default to slow decay, episodic memories decay faster, and procedural memories (how-to knowledge) sit in between.

the prune order (DB first, media second) is correct. we hit the exact opposite bug early on, deleted media first, then the DB delete failed, and we had dangling references that broke retrieval for a week before someone noticed.

[m13v]

our memory storage layer with category-based decay rates and confidence tracking: https://github.com/m13v/ai-browser-profile/blob/main/ai_browser_profile/db.py - handles the per-category eviction and structured metadata. and the embedding search used for candidate retrieval before LLM judgment: https://github.com/m13v/ai-browser-profile/blob/main/ai_browser_profile/embeddings.py

[stellanoxUN]

对遗忘服务（Forgetting Service）设计原则的一些反馈：

1. 指数衰减是正确的默认选择

同意。但我认为衰减应该发生在两个层面：全局衰减（所有记忆统一的半衰期）和关联衰减（被引用的记忆因活跃度而延长半衰期）。后者比 importance 阈值更接近记忆的自然行为。

2. 嵌入相似度只作为候选检索

完全同意。嵌入相似度是检索的必要但不充分条件。两段语义相似的文本可能在逻辑上是矛盾的（"Python is great" vs "Python is slow"）。把判断权留给 LLM 是正确的分界。

3. 变异原语

这里有一个设计选择值得讨论：遗忘是被动（扫描→淘汰）还是主动（写入时检查和合并）。你的方案偏被动，这适合周期性维护。但如果在写入时就做轻量级的冲突检测和合并预告，遗忘的粒度可以更细，不需要大扫除。

4. 去重在 bucket 分配前

这一点有一个边际情况：如果两条高度相似的记忆属于不同的 episode，它们是去重还是保留为独立记录？这取决于你更看重跨 session 的知识覆盖，还是单 session 的准确上下文。