Timmy_Foundation/the-nexus
15
1
Fork 2
Code Issues 89 Pull Requests 33 Actions Packages Projects Releases Wiki Activity

[Mnemosyne] Memory Decay — living vitality score for archive entries #1258

New Issue
Closed
opened 2026-04-12 05:39:54 +00:00 by Rockachopa · 1 comment
Rockachopa commented 2026-04-12 05:39:54 +00:00
Owner
Copy Link

Problem

Archive entries currently have no notion of "liveliness." Old memories and fresh ones look identical. The holographic archive needs a vitality system where:

  • Memories fade with neglect (time since last access)
  • Memories brighten with use (access frequency)
  • The system can surface fading memories and vibrant ones

Requirements

  1. Entry model: Add vitality (float 0.0–1.0) and last_accessed (ISO datetime) fields to ArchiveEntry
  2. touch(entry_id): Record an access — bumps vitality and updates last_accessed
  3. vitality(entry_id): Compute current vitality (decayed from last_accessed, boosted by access recency)
  4. fading(limit): Return entries with lowest vitality (most neglected)
  5. vibrant(limit): Return entries with highest vitality (most alive)
  6. apply_decay(): Decay all entries' vitality based on elapsed time, persist
  7. Stats integration: Add vitality summary to stats() output
  8. Tests: Cover decay math, touch boost, fading/vibrant queries, persistence

Design

Vitality formula: v = base_vitality * decay_rate ^ (hours_since_access / half_life) — exponential decay with configurable half-life (default: 30 days). Touch adds a boost of 0.1 * (1 - current_vitality) — diminishing returns as vitality approaches 1.0.

Parent

Part of Mnemosyne living archive. FEATURES.yaml memory_decay entry.

## Problem Archive entries currently have no notion of "liveliness." Old memories and fresh ones look identical. The holographic archive needs a vitality system where: - Memories **fade** with neglect (time since last access) - Memories **brighten** with use (access frequency) - The system can surface fading memories and vibrant ones ## Requirements 1. **Entry model**: Add `vitality` (float 0.0–1.0) and `last_accessed` (ISO datetime) fields to `ArchiveEntry` 2. **`touch(entry_id)`**: Record an access — bumps vitality and updates `last_accessed` 3. **`vitality(entry_id)`**: Compute current vitality (decayed from last_accessed, boosted by access recency) 4. **`fading(limit)`**: Return entries with lowest vitality (most neglected) 5. **`vibrant(limit)`**: Return entries with highest vitality (most alive) 6. **`apply_decay()`**: Decay all entries' vitality based on elapsed time, persist 7. **Stats integration**: Add vitality summary to `stats()` output 8. **Tests**: Cover decay math, touch boost, fading/vibrant queries, persistence ## Design Vitality formula: `v = base_vitality * decay_rate ^ (hours_since_access / half_life)` — exponential decay with configurable half-life (default: 30 days). Touch adds a boost of `0.1 * (1 - current_vitality)` — diminishing returns as vitality approaches 1.0. ## Parent Part of Mnemosyne living archive. FEATURES.yaml `memory_decay` entry.
Timmy was assigned by Rockachopa 2026-04-12 05:39:54 +00:00
Rockachopa commented 2026-04-12 05:44:52 +00:00
Author
Owner
Copy Link

Implementation submitted

PR: #1259

Memory decay system implemented with:

  • vitality and last_accessed fields on ArchiveEntry
  • touch(), get_vitality(), fading(), vibrant(), apply_decay() on MnemosyneArchive
  • 20+ tests
  • Exponential decay (30-day half-life) + diminishing-return touch boost
## Implementation submitted PR: #1259 Memory decay system implemented with: - `vitality` and `last_accessed` fields on ArchiveEntry - `touch()`, `get_vitality()`, `fading()`, `vibrant()`, `apply_decay()` on MnemosyneArchive - 20+ tests - Exponential decay (30-day half-life) + diminishing-return touch boost
Timmy closed this issue 2026-04-12 06:08:52 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
222-epic
3d-world
CI
Continuous integration, runners, workflow issues
 QA
Quality assurance, testing, and production audit
 actionable
agent-presence
aistudio-ready
assigned-aistudio
assigned-claude
assigned-claw-code
Queued for Code Claw (qwen/openrouter)
 assigned-gemini
assigned-groq
assigned-kimi
assigned-kimi
Dispatched to Kimi via OpenClaw
 assigned-perplexity
assigned-sonnet
blocked
Blocked by external dependency or merge conflict
 claude-ready
claw-code-done
Code Claw completed this task
 claw-code-in-progress
Code Claw is actively working
 deprioritized
duplicate
epic
Epic / umbrella issue
 gemini-api
Gemini API integration
 gemini-review
google-ai-ultra
Google AI Ultra integration work
 groq-ready
harness
identity
Timmy identity and branding
 infrastructure
kimi-done
Kimi completed this task
 kimi-in-progress
Kimi is actively working on this
 kimi-ready
lazzyPit
Lazarus Pit — automated agent resurrection and health recovery
 media-gen
AI media generation (image/video/audio)
 mnemosyne
Project Mnemosyne — The Living Holographic Archive
 modularization
needs-design
nostr
p0-critical
p1-important
p2-backlog
performance
perplexity-ready
portal
research
Deep research and planning tasks
 security
Security hardening, vulnerability fixes, access control
 sonnet-ready
sovereignty
velocity-engine
Auto-generated by velocity engine
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
KimiClaw Rockachopa Timmy allegro antigravity bezalel claude claw-code codex-agent ezra gemini google grok hermes kimi manus perplexity sonnet
No Assignees Timmy
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/the-nexus#1258
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?