Memory System Subsystem

Version: 1.0.0 Last Updated: 2026-03-13

The Memory System provides OmegA with persistent, provenance-tracked knowledge across sessions. Canonical rules for the memory system are defined in omega/MEMORY_CONSTITUTION.md.

What It Is

A multi-tier storage and retrieval system that spans:

• In-process RAM (L1 working memory)
• Session-scoped SQLite/Brain DB (L2 session memory)
• Long-term SQLite via Rust omega-memory crate (L3/L4 local)
• Supabase PostgreSQL + pgvector (L4/L5 cloud)
• Version-controlled Phylactery files (L6 identity kernel)

Why It Exists

Stateless LLMs forget everything between requests. OmegA's value proposition is persistent longitudinal memory — the ability to remember past conversations, decisions, project history, and operator preferences across sessions, provider swaps, and system restarts.

Primary Components

omega-memory Crate (Rust)

Location: rust/omega-rust/crates/omega-memory/ Database: SQLite via sqlx Features:

• SqliteMemoryStore — write/read/search/delete operations
• fastembed-rs embeddings (all-MiniLM-L6-v2) stored in SQLite/PG BLOBs
• Semantic LIKE search (Week 3 production); fastembed semantic search is Week 4 work
• Memory CRUD routes exposed via Gateway: GET /memory, POST /memory/upsert, DELETE /memory/:id
• Importance decay background task (hourly tokio task — Week 4 implementation)

Brain Memory Layer (Node.js)

Location: services/packages/brain/src/core/memory-layer.js Features:

• Working memory (L1) — in-process
• Session memory (L2) — Brain DB
• Hybrid RAG: local fastembed + Mem0 cloud integration for deep cross-session retrieval

Supabase (Cloud)

Project: tssfdlodjgtedsssfpfc (OmegA-Sovereign — omega_memory, omega_events) Project: sgvitxezqrjgjmduoool (Primary — chat_messages, files)

• pgvector extension for semantic search (Week 4: PgMemoryStore implementation)
• omega_memory table, omega_events table

Retrieval Logic

1. L1 (current context) — always available, no retrieval needed
2. L6 (Phylactery) — identity anchors, injected at context start
3. L2 (session) — last N messages and session facts
4. L4 (semantic) — vector similarity search against query embedding
5. L3 (episodic) — temporal search for relevant past events
6. L5 (relational) — SQL/graph lookup for structured facts

Retrieval timeout: if semantic search exceeds 2s, fall back to keyword search and log RETRIEVAL failure.

Retrieval Telemetry

Every retrieval should emit evidence that can drive memory utility decisions, not proxy scores.

Required Fields (in-memory and persistent layers)

• retrieval_count: incremented on every successful retrieval of a node.
• last_retrieved_at: Unix timestamp of the most recent retrieval.

Usage

• Memory pruning uses retrieval evidence before importance scores.
• Entries with no retrieval activity over a defined window are eligible for decay or demotion.

Write Path

Write request → provenance check (source, timestamp, confidence required)
             → probation queue (if not explicitly promoted)
             → [promotion trigger] → L3/L4/L5 storage
             → contradiction detection → conflict flag if match found

Current Implementation Status

Failure Modes