brain@elora:~$memory/lifecycle

Cycle mémoire

La mémoire d'Elora n'est pas un simple historique de chat. Elle sépare capture brute, mémoire canonique, mémoire opérationnelle, mémoire relationnelle, retrieval et propositions d'apprentissage.

Décision actuelle: PostgreSQL + pgvector est le stockage canonique de Memory V2. Ollama fournit les embeddings locaux par défaut. Le fallback local est un spool append-only rejouable, pas une seconde vérité mémoire.

Ordre dur d'ingestion

1. Capture verbatim

Un message, document, ticket ou artefact est d'abord archivé tel qu'il existe, avec source, temps, surface et provenance. La capture doit réussir avant toute synthèse.

2. Archive ou spool

Si PostgreSQL est disponible, l'objet va dans l'archive locale. S'il est indisponible, Elora écrit dans un spool local append-only pour rejouer plus tard.

3. Découpage et indexation

Les contenus longs sont chunkés. Les embeddings locaux via Ollama améliorent le rappel sémantique, mais le texte original reste conservé.

4. Candidats mémoire

Elora peut proposer des entries canoniques: fait, préférence, décision, contrainte, événement, hypothèse, pattern ou expression. Une proposition n'est pas encore vérité durable.

5. Canonicalisation

Les entrées maintenues reçoivent canonical_text, embedding_text, truth_mode, scope, confiance, temporalité, sources et liens de provenance.

6. Contradictions

Une nouvelle information ne détruit pas l'ancienne. Elle peut la confirmer, la contredire, la remplacer, la déprécier ou la limiter dans le temps.

Quand la mémoire intervient dans une réponse

  1. La surface reçoit une demande: terminal, cockpit, Telegram ou futur avatar.
  2. Elora classe la demande et décide si le contexte mémoire est nécessaire.
  3. Le retrieval récupère d'abord les `memory.entries` maintenues, puis les `archive.chunks` comme preuves secondaires.
  4. Le contexte est assemblé en evidence pack limité: faits utiles, sources, dates, confiance, contradictions et limites.
  5. Le provider local ou le worker reçoit ce pack, pas toute la base mémoire.
  6. La réponse doit respecter les preuves injectées ou marquer explicitement l'incertitude.
  7. Après exécution, les logs, scores, feedbacks et propositions d'apprentissage restent inspectables avant promotion.

Les quatre couches de rappel

L0 identity wake-up

État minuscule toujours disponible: identité opérateur, mission, persona active, priorités, préférences stables.

L1 operational essentials

Faits et contraintes durables, projets en cours, définitions stables, open loops et préférences importantes.

L2 focused topic recall

Rappel ciblé pour un projet, une personne, un incident, un repo, une mission ou un sujet précis.

L3 deep search

Recherche plus coûteuse: sémantique large, lexical, graphe, temps, contradictions et preuves faibles.

Fallback mémoire

Le premier système historique était plus file-backed. Memory V2 garde la leçon de simplicité, mais ne garde pas un deuxième canon caché: la vérité durable vit dans PostgreSQL. Le fallback sert à ne pas perdre une capture ou une entrée quand la base n'est pas joignable.