Problem / Motivation
When a user asks a date-specific question (e.g., "did Market Wrap send on March 18?"), the plugin's recall returns the nearest semantic matches regardless of timestamp. This can lead to date confabulation — the LLM receives memories from March 8-9 and confidently answers about March 18 as if those are the same event.
Concrete example
Query: "What happened on March 18?"
Recall returns:
- "Market Wrap delivered on March 8" (67% vector match)
- "Morning Brief delivered on March 9" (67% vector match)
LLM output: "On March 18, the Market Wrap and Morning Brief were delivered..." ← hallucination
The memories are semantically close (both about newsletter delivery) but temporally wrong. The LLM has no signal that the results are from a different date than asked.
Proposed Solution
Add temporal awareness to the recall hook. Two levels of implementation:
Level 1: Post-filter warning (minimal change)
After vector search, if the query contains a date reference (ISO date, "yesterday", "last Tuesday", "March 18"):
- Extract the target date from the query
- Check if any returned memories have
timestamp within ±24h of the target date
- If no results match the target date, prepend a system note to the recall output:
⚠️ No memories found for [target date]. The results below are from other dates and may not be relevant to the specific date asked about.
This gives the LLM an explicit signal to say "I don't have information for that date" instead of confabulating.
Level 2: Optional temporal pre-filter (configurable)
Add a config option to enable hard date filtering:
{
"recall": {
"temporalAwareness": true,
"temporalWindowHours": 24,
"temporalFallback": "warn" // "warn" | "filter" | "off"
}
}
warn: Show all results but prepend the warning (Level 1)filter: Only return results within the temporal window, empty set if none matchoff: Current behavior (no temporal awareness)
Default: warn (non-breaking change)
Date extraction patterns to support
- ISO dates: "2026-03-18", "March 18, 2026", "March 18"
- Relative: "yesterday", "last Tuesday", "two days ago", "this morning"
- Ranges: "last week", "this month" (extract start/end)
Why this matters
In multi-system architectures (ours uses LanceDB-Pro + discrawl + LCM), the memory plugin is the default recall path. Date-specific operational questions should go to an audit log (discrawl), but the agent doesn't always route correctly. A temporal warning from the plugin itself acts as a safety net — the last line of defense before confabulation.
Alternatives Considered
- Router-level LLM classification: Adds latency + cost for every query. Overkill when keyword matching suffices.
- Mandatory
event_date schema field: Most memories are timeless (preferences, decisions, rules). A required date field would be null for ~80% of entries.
- Post-hoc validation by the agent: Relies on the LLM noticing the date mismatch in recalled memories. Unreliable — LLMs tend to use whatever context they're given.
Additional Context
Problem / Motivation
When a user asks a date-specific question (e.g., "did Market Wrap send on March 18?"), the plugin's recall returns the nearest semantic matches regardless of timestamp. This can lead to date confabulation — the LLM receives memories from March 8-9 and confidently answers about March 18 as if those are the same event.
Concrete example
Query: "What happened on March 18?"
Recall returns:
LLM output: "On March 18, the Market Wrap and Morning Brief were delivered..." ← hallucination
The memories are semantically close (both about newsletter delivery) but temporally wrong. The LLM has no signal that the results are from a different date than asked.
Proposed Solution
Add temporal awareness to the recall hook. Two levels of implementation:
Level 1: Post-filter warning (minimal change)
After vector search, if the query contains a date reference (ISO date, "yesterday", "last Tuesday", "March 18"):
timestampwithin ±24h of the target dateThis gives the LLM an explicit signal to say "I don't have information for that date" instead of confabulating.
Level 2: Optional temporal pre-filter (configurable)
Add a config option to enable hard date filtering:
{ "recall": { "temporalAwareness": true, "temporalWindowHours": 24, "temporalFallback": "warn" // "warn" | "filter" | "off" } }warn: Show all results but prepend the warning (Level 1)filter: Only return results within the temporal window, empty set if none matchoff: Current behavior (no temporal awareness)Default:
warn(non-breaking change)Date extraction patterns to support
Why this matters
In multi-system architectures (ours uses LanceDB-Pro + discrawl + LCM), the memory plugin is the default recall path. Date-specific operational questions should go to an audit log (discrawl), but the agent doesn't always route correctly. A temporal warning from the plugin itself acts as a safety net — the last line of defense before confabulation.
Alternatives Considered
event_dateschema field: Most memories are timeless (preferences, decisions, rules). A required date field would be null for ~80% of entries.Additional Context
timestampfield (Unix ms) — no schema change neededupgrade --forceto re-enrich memories that fell back to simpleEnrich #279 (--forceupgrade for re-enrichment)