Memory Lifecycle

When raw data enters Memuron it isn’t chunked and dumped. It runs a nine-stage evolutionary pipeline that decides what to keep, merge, and connect.

The Guardian pipeline

Nine stages

1. 1

   Ingest queueing

   The raw payload is written to the Postgres memuron_ingest_jobs table as queued. Zero data loss; you get a job ID.

2. 2

   Worker claiming

   A background worker locks the row, flips it to processing, and begins.

3. 3

   Space contextualization

   The worker resolves the target Space and loads its guardian_prompt — the rules for the LLM.

4. 4

   Candidate retrieval (hybrid)

   A pgvector/HNSW cosine leg is fused with a Postgres full-text/BM25 leg via Reciprocal Rank Fusion to find existing candidates.

5. 5

   Guardian evaluation

   The Guardian decides action: create or update and emits a strict GuardianWritePlan.

6. 6

   Graph evolution

   On update, the target node is patched in place (same ID, new vector). On create, a new MemoryValue is generated.

7. 7

   Semantic linking

   Guided by the plan’s connections, Memuron draws memory_link edges stamped with natural-language relationships.

8. 8

   Commit & completion

   Typed events (memory.created, memory.updated, …) flush to the append-only ledger with actor/tenant/scope metadata. The job is marked completed.

9. 9

   Projection updates

   Four read models — memuron_memories, memuron_links, memuron_placements, memuron_fs — plus the vector and FTS indices refresh. All are rebuildable from the ledger.