System Architecture

Runtime components

Each component can fail independently, so production readiness depends on explicit health checks and reconciliation jobs between indexes and durable storage.

• HTTP API: request validation and orchestration
• Temporal store: durable source of truth records
• Vector index: nearest-neighbor semantic recall
• Lexical index: BM25 exact-term recovery
• Graph store: provenance and supersession links
• Semantic models: bi-encoder and optional cross-encoder

Ingest flow

Durable write order matters. The source-of-truth store should be committed before secondary index updates are marked complete, otherwise reconciliation gets harder after crashes.

request -> normalize -> companion expansion -> embedding -> dedup
       -> write temporal store -> write vector/lexical/graph indexes

Query flow

Query requests gather candidates from both semantic and lexical paths. Candidate lists can be reranked and fused, then filtered by temporal policy before response serialization.

This design keeps both high recall and exact-term precision, even when the user asks for rare names, IDs, or dates.

semantic_topk + lexical_topk -> optional cross-rerank -> RRF fusion
-> temporal filters (TTL, superseded facts) -> final ranked hits