Re-evaluation Flow

At ingestion time, the intelligence gatekeeper assigns one of three states to a memory: immediate (process now), batched (process in the next sweep), or skipped (low-signal, deferred indefinitely). The skipped state is the right call for most low-importance writes — but a small fraction of skipped memories turn out to be critical days or weeks later. Without re-evaluation, those memories stay frozen at their initial score forever.

Every memory carries an intelligence state. It starts in one of two places at write time. skipped means the gatekeeper looked at the memory and judged it low-signal — do not score, do not include in snapshots. batched means worth scoring, but not urgent — pick it up on the next sweep.

Re-evaluation can move a memory up the ladder, never down. A skipped memory that starts attracting recall traffic crosses the batch threshold and becomes batched. A batched memory that keeps getting hot crosses the immediate threshold and becomes immediate — which schedules a one-off scoring pass right now instead of waiting for the next sweep. Once a memory reaches immediate it stays there; cooling off does not undo a promotion.

In short: recall heat is the only thing that promotes. The original importance, the source, the tags — none of that matters at this stage. The job watches who is being recalled and re-asks the gatekeeper if its earlier verdict still fits.

1. 1Pull the recent recall log, restricted to events newer than the last successful tick.
2. 2Aggregate per memory: count of recalls in the last hour, distinct user count, average rank position when returned.
3. 3Filter to candidates whose intelligence_state is skipped or batched.
4. 4Apply per-memory cooldown — a candidate evaluated within the last 5 minutes is skipped this tick.
5. 5Re-score each surviving candidate through the gatekeeper using its current recall signals (not its original ones).
6. 6Promote: skipped → batched if the new score crosses the batch threshold; batched → immediate if it crosses the immediate threshold.
7. 7Emit a structured log line with the counts (scanned, candidates, reevaluated, promoted).

• Per-tenant cap per run. No tenant can have more than ~100 candidates re-evaluated in a single tick — so a single noisy tenant does not starve others.
• Per-memory cooldown. A memory that was just re-evaluated will not be touched again for at least 5 minutes, no matter how much heat it accumulates.
• Bounded scan window. The recall log is only scanned for the most recent window; older heat is summarised, not re-litigated.

Every 10 minutes, by default. Tunable per deployment but the contract is "minutes, not hours" — long enough to amortise the database scan, short enough that a memory that just went hot gets noticed before the user finishes their session.

• To batched: the memory enters the next intelligence sweep and contributes to the next snapshot recompute.
• To immediate: the intelligence pipeline schedules a single-memory pass right now — no waiting for the sweep.
• Either promotion writes a memory_events row with event_type="reevaluation_promoted" and the previous and new states, so audit trails reflect the change.

• It does not change importance directly — only the gatekeeper's intelligence_state.
• It does not re-embed the memory; the vector stays as written.
• It does not demote — a memory promoted to immediate never falls back to batched based on cool-off.
• It does not run on tenants without intelligence enabled — the job no-ops cleanly for them.