-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Trustworthy retrieval for an AI agent's own memory. Every hit comes back with a verdict, a calibrated confidence, validity metadata, tenant scope and provenance, or the honest answer is "I don't know."
Most RAG hands back the closest vector match. For an agent retrieving over memory it wrote itself, that is the wrong answer more often than you'd expect: when a decision has been reversed, the stale memory of it is frequently the highest-cosine hit in the whole result. Similarity search serves it, confidently, and the agent builds on a fact that is no longer true.
RE-call is a retrieval engine that judges each hit before it reaches the agent — demoting memories that were superseded or have fallen outside their validity window, and preferring an explicit abstention over confident noise.
→ Evaluating this as a work sample. Read The-Problem for the failure modes it targets, then Evidence-Map — a routing table from each published claim to where it was measured, the command that reproduces it, and the limit it carries. The-Trust-Layer is the conceptual core and the most load-bearing design work in the project.
→ Using it. Installation-and-Setup → CLI-Reference or Python-API-and-MCP. Then Configuration-Reference when you need to tune something, and Tenancy-and-Auth before you expose it over a socket.
→ Working on it. Architecture for the module map and dependency direction, Contributing-and-Testing for setup and the testing conventions, The-Trust-Layer and Retrieval-Pipeline for how the two halves of the engine actually behave.
This wiki explains why: what each component is for, what it deliberately refuses to do, and what breaks when you get it wrong.
It is not the source of truth for any number. Measured results, configuration defaults and CLI flags all live in the repository, versioned alongside the code that produced them, and this wiki links to them rather than copying them. A claims table that drifts is worse than no claims table, and a wiki has no CI to catch drift.
So: figures go to results/FINDINGS.md,
results/RESULTS.md and
the README. Deployment roles and
schema state go to docs/MIGRATIONS.md.
Defaults go to .env.example.
Flags go to --help.
A query is embedded and run against dense pgvector search, Postgres full-text search, and, when configured, a learned sparse SPLADE leg. Reciprocal Rank Fusion merges them, an optional cross-encoder reranks the candidate pool before truncation, and then the trust layer judges every surviving hit: is it superseded, is it inside its validity window, does its calibrated confidence clear the abstention boundary, and, in strict production mode, is the calibration bound to the active generation. Valid hits are ordered first, so a retrieved successor outranks the stale memory it replaced. If nothing earns a clean verdict, the result is an explicit abstention with a reason.
Validity is authored, not inferred: plain frontmatter in the memory itself. A claim honoured as written is safe; a claim guessed at is not. See The-Trust-Layer for why that distinction survived every attempt to automate around it.
This wiki explains design and intent. Measured figures, deployment defaults and CLI flag values
live in the repository, versioned with the code that produced them:
FINDINGS ·
RESULTS ·
MIGRATIONS ·
.env.example · --help.
If a page here disagrees with the repo, the repo is right.
Concepts
Using it
- Installation-and-Setup
- Embedders-and-Rerankers
- Configuration-Reference
- CLI-Reference
- Python-API-and-MCP
- Tenancy-and-Auth
Evidence
Contributing
In the repo