openclaw - 💡(How to fix) Fix MEMORY.md: Dreaming promotes content but has no mechanism to retire stale rules

Summary

Add a rule lifecycle mechanism so old rules in MEMORY.md can be identified, confidence-decayed, and retired — completing the full promote/evict cycle that Dreaming only half-implemented.

Problem to solve

OpenClaw's Dreaming system (introduced 2026.4.9) handles automatic promotion of valuable signals into MEMORY.md. There is no corresponding mechanism to identify or retire content that has become outdated or invalid over time. In practice, MEMORY.md accumulates rules without lifecycle management: Rules written months ago may no longer reflect current system behavior or user preferences Auto-promoted content and user-authored content coexist with no distinction of validity When rules conflict, there is no way to determine which is the current authoritative version Users are in a state of "不敢删" (afraid to delete): afraid of removing something still in use, but equally afraid of keeping something misleading The recent "Memory compaction deduplication" (v5.16-beta.4) addresses content deduplication but not temporal validity — it does not distinguish between a rule validated yesterday and one promoted 8 months ago.

Proposed solution

A minimal viable solution could involve: Timestamp entries at write time in MEMORY.md, distinguishing auto-promoted vs user-authored content Confidence decay during compaction: rules not reaffirmed within a threshold (e.g., 90 days) get progressively lower priority CLI visibility: a command like openclaw memory audit that lists rules with their last-affirmed date, so users can review and prune manually Eviction during compaction: when MEMORY.md reaches a size threshold, compaction can safely remove low-confidence expired rules rather than only deduplicating This complements Dreaming's promotion logic with a corresponding retirement mechanism.

Alternatives considered

Manual-only management: leave it entirely to users to track and delete old rules. This is the current state — and the reason this issue exists. It does not scale as MEMORY.md grows. Full rewrite on upgrade: clear MEMORY.md on major version upgrades. Too destructive; loses valuable user-authored context that should persist across versions. AI-managed deletion only: let the AI decide what to delete autonomously. Without explicit signals (timestamps, usage frequency), the AI cannot reliably distinguish old valid rules from stale ones.

Impact

Affected users: any user running OpenClaw with an active MEMORY.md over more than a few weeks Severity: annoying / blocks trust — not critical, but erodes confidence in the system's memory over time Frequency: continuous; worsens with every session that produces auto-promoted content Consequence: MEMORY.md grows unbounded, AI follows outdated rules, users lose visibility into what is actually authoritative

Evidence/examples

After several months of daily use, MEMORY.md has grown from v1 to v5.x with no natural retirement Dreaming's promotion logic was added (2026.4.9) but no corresponding eviction mechanism Community feedback (Simon Høiberg, OpenClaw co-founder): "OpenClaw does a TERRIBLE job at deciding what to store in long-term memory" — the team acknowledges this is a known problem

Additional information

This is written from the perspective of a daily production user who relies on MEMORY.md as the authoritative source of working rules for an AI research analyst persona. The goal is not to criticize the current system but to propose a complementary mechanism that completes the memory lifecycle — promote the good, retire the stale.