How RE-call works: build once, serve with a trust gate Diagram

1. Build once

Each manifest object is fetched, parsed, chunked and embedded; unchanged sources are reused
The result is an immutable generation; validate, then promote
In production, promote refuses a generation whose calibration is not certified

2. Serve against a pin

Every search pins one active generation for its whole run
Dense pgvector and Postgres full text are fused with RRF; a reranker is opt in
The query is embedded with the same model that built the generation

3. Trust gate

Each hit gets a verdict: ok, superseded, expired, not yet valid, low confidence
Valid hits rank first, so a successor outranks the stale memory it replaced
No ok hit means ABSTAIN with a reason, never the nearest match

Opt in paths (not drawn)

recall_reasoning_query and one hop graph expansion re-enter trusted search before the gate
recall_apply_fact goes through the provenance controller into an append only ledger
recall_ingest builds, validates and promotes a generation through the same manager