openclaw - 💡(How to fix) Fix Short-term promotion: signalCount mixes daily/session signals with real recalls [1 comments, 2 participants]

Bug description

Short-term memory promotion (rankShortTermPromotionCandidates) uses totalSignalCountForEntry to gate minRecallCount, but that function sums recallCount + dailyCount + groundedCount. Daily and session signals (from ingestDailyMemorySignals / ingestSessionTranscriptSignals) are counted equally with real user search recalls. This produces:

1. False candidates promoted: entries with recallCount=0 but dailyCount=3 pass the minRecallCount=3 filter
2. Real candidates hidden: entries with recallCount=3 score 0.64-0.68, below the minScore=0.80 threshold, because the scoring weights were tuned to work with the inflated signal counts

Root cause chain

1. Signal type mixing

function totalSignalCountForEntry(entry) {
  return (entry.recallCount ?? 0) + (entry.dailyCount ?? 0) + (entry.groundedCount ?? 0);
}

The dailyCount comes from ingestDailyMemorySignals which scans past 30 days of memory files and stamps every matching entry as a daily signal. These are NOT user search recalls but are counted the same way.

2. Score inflation from combined signals

avgScore = totalScore / signalCount. When signalCount is inflated by daily signals, avgScore rises. An entry with recallCount=3 and dailyCount=3 has signalCount=6, giving avgScore higher than a real recall-only entry with signalCount=3.

3. Real entries fail minScore

Verified data from short-term-recall.json:

{
  "key": "memory:memory/2026-04-16.md:407:425",
  "recallCount": 3,
  "dailyCount": 0,
  "queryHashes": 3,
  "recallDays": 4,
  "totalScore": 1.367,
  "computedPromotionScore": 0.645
}

With minScore=0.80, this entry is filtered out. The entry IS actively recalled by user search, but unreachable with current scoring.

Environment

• OpenClaw: 2026.4.24
• short-term-recall.json: 10,429 entries, 8 with recallCount >= 3, 2 with recallCount >= 3 AND queries >= 3 AND not promoted
• minRecallCount=3, minScore=0.80, minUniqueQueries=3

Existing workaround

Three patches applied to compiled JS:

1. Light dreaming sort: prioritize recallCount over lastRecalledAt
2. Rehydration span: widen from +3/+8 to +15/+20
3. Make totalSignalCountForEntry only count recallCount

After these, the system honestly reports applied=0 - no noise promoted, but legitimate entries still cannot pass minScore.

Suggestion

recordShortTermRecalls should weight recall signals differently from daily/session signals when aggregating totalScore. Or alternatively: separate the minRecallCount gate to use only recallCount (not combined signals) while keeping the combined signalCount for totalScore calculation.