jugripa’s MEM100 stores agent memories in two JSONL tiers, with Markdown dossiers for fuller context. Its retrieval code uses Jev to score a catalog of candidate memories and keeps a local keyword-based fallback.
Ask two kinds of relevance question
- Each memory receives a choice among directly relevant, related and irrelevant.
- A separate choice asks which memory is the strongest match, including a “none” option.
- Code combines those probabilities into a relevance score, then adds recency and importance.
- A low-relevance gate prevents recency alone from pushing an unrelated record over the threshold.
- Requests are chunked at 55 records, so the advertised single call does not hold for larger catalogs.
Preserve the fallback’s identity
If Jev is unavailable or offline mode is selected, the code uses BM25, a keyword-ranking algorithm, with recency and importance. The result includes the actual engine name and uses a different threshold. That makes the fallback visible, although its rankings need not agree with Jev’s.
The request sends the task and memory search surfaces to TypeSafe. Those surfaces may contain sensitive context; local storage does not make hosted retrieval private.
A typed relevance score is not proof that a memory is relevant or complete. The project’s latency claims and retrieval quality were not independently reproduced, and its experiment document describes proposed tests rather than measured results.
Verification: inspected the README and retrieval implementation. Neither the project nor live Jev was run; this was not a security audit.