Problem
mempalace_search ranks results purely by ChromaDB vector similarity. A tech-stack decision from six months ago and a discussion from yesterday are treated with equal weight.
In practice, recent memories are almost always more relevant. The knowledge graph already has valid_from / valid_to on triples, but the drawer search layer has no concept of time at all.
This gap was partially noted in #224 (stale drawer retrieval), but that issue focuses on KG–drawer consistency. This proposal addresses a different angle: incorporating time as a scoring signal in search ranking itself.
Proposed solution
Add an optional time-decay factor to the search score:
final_score = similarity * decay(age)
Where decay(age) is a configurable function (e.g., exponential or linear) that down-weights older drawers. The mined_at or created_at timestamp already stored in drawer metadata can serve as the time anchor.
Behavior
- Default: decay enabled with a sensible default half-life (e.g., 90 days)
- Override:
mempalace_search("query", time_decay=False) to disable for historical research
- Tunable: configurable half-life via
~/.mempalace/config.json ("time_decay_half_life_days": 90)
- No data loss: this only affects ranking order, not what is stored or deleted
Example
| Drawer |
Similarity |
Age |
Decay (90d half-life) |
Final score |
| "Use Clerk for auth" (yesterday) |
0.82 |
1d |
0.99 |
0.81 |
| "Use Auth0 for auth" (6 months ago) |
0.85 |
180d |
0.25 |
0.21 |
Without decay, the older drawer wins. With decay, the recent decision surfaces first — which is almost always what the user wants.
Implementation scope
searcher.py: apply decay multiplier after ChromaDB returns raw results
mcp_server.py: expose time_decay parameter on mempalace_search
config.py: add time_decay_half_life_days setting
- Tests: verify ranking order changes with decay on/off
Why this matters
AI agents that retrieve outdated decisions as top results can act on stale context without realizing it. Time-decay is a lightweight, non-destructive way to make recency a first-class signal — complementing the KG's temporal model with equivalent awareness on the search side.
Related: #332 (soft-archive wings — the other half of time-aware memory management)
Problem
mempalace_searchranks results purely by ChromaDB vector similarity. A tech-stack decision from six months ago and a discussion from yesterday are treated with equal weight.In practice, recent memories are almost always more relevant. The knowledge graph already has
valid_from/valid_toon triples, but the drawer search layer has no concept of time at all.This gap was partially noted in #224 (stale drawer retrieval), but that issue focuses on KG–drawer consistency. This proposal addresses a different angle: incorporating time as a scoring signal in search ranking itself.
Proposed solution
Add an optional time-decay factor to the search score:
final_score = similarity * decay(age)
Where
decay(age)is a configurable function (e.g., exponential or linear) that down-weights older drawers. Themined_atorcreated_attimestamp already stored in drawer metadata can serve as the time anchor.Behavior
mempalace_search("query", time_decay=False)to disable for historical research~/.mempalace/config.json("time_decay_half_life_days": 90)Example
Without decay, the older drawer wins. With decay, the recent decision surfaces first — which is almost always what the user wants.
Implementation scope
searcher.py: apply decay multiplier after ChromaDB returns raw resultsmcp_server.py: exposetime_decayparameter onmempalace_searchconfig.py: addtime_decay_half_life_dayssettingWhy this matters
AI agents that retrieve outdated decisions as top results can act on stale context without realizing it. Time-decay is a lightweight, non-destructive way to make recency a first-class signal — complementing the KG's temporal model with equivalent awareness on the search side.
Related: #332 (soft-archive wings — the other half of time-aware memory management)