Memory

Memories in Mneva are append-only records of things that happened in your project — a decision, a fix, a fact about how the codebase works. They are written by remember and surfaced by recall.

Memories

Each memory is one row in your tenant's memories table:

memories (
  id          INTEGER PRIMARY KEY,
  project     TEXT,
  text        TEXT,
  embedding   BLOB,            -- 1024-d mxbai-embed-large vector
  caution     REAL DEFAULT 0,  -- 0..1, written by flag()
  created_at  TEXT
)

Memories are append-only. They are never deleted, never edited. If a fact changes, write a new memory; the old one stays in the record so a recall against the situation at the time still works. If a belief changes, that's what revise is for — different shape, different table.

Recall

recall(query) is semantic by default. The query is embedded against the same mxbai-embed-large model (1024-d, MIT-licensed, top-of-class English retrieval per MTEB) that embedded each stored memory; results are ranked by cosine similarity to the query vector.

That means a recall finds memories by meaning, not by words. A memory that says "we use Postgres for the user database" surfaces in response to "where does user data live" — zero word overlap, score ~0.59 in our test brains.

Output shape:

{
  "mode": "semantic",
  "results": [
    { "id": 12, "text": "...", "created_at": "...", "score": 0.71 },
    { "id": 7,  "text": "...", "created_at": "...", "score": 0.62 }
  ],
  "keyword_extra": []
}

score is raw cosine, not normalized to 0..1. Higher = closer. Anything above ~0.6 for a short query is genuinely topical; ~0.4-0.55 is "shares register"; below ~0.4 is noise.

When semantic falls back

If the local Ollama embedding service is unreachable when you call recall, Mneva degrades to keyword match (case-insensitive LIKE) and returns:

{ "mode": "keyword", "results": [...] }

The mode field tells you which path served the result. Semantic recall is an upgrade, never a hard requirement — the engine does not break because embeddings happen to be down.

Memories stored before embeddings existed (rare; only for old self-hosted installs) are still findable by keyword and appear under keyword_extra in semantic-mode responses.