La mémoire

La mémoire de CoeOS repose sur une distinction nette :

Écriture = mémoire = Vault (wiki Karpathy) — ce que l’assistant retient de vous, évolutif, personnel, par utilisateur.
Lecture = connaissance = RAG — les corpus de référence qu’on interroge (droit du travail, jurisprudence, un gros dossier), partagés et statiques.

Cette séparation résout le problème central : une mémoire personnelle ne peut pas vivre dans un RAG partagé sans fuite entre utilisateurs. La mémoire va donc au Vault (isolé par utilisateur), la connaissance au RAG (référence commune, en lecture).

1. Les niveaux de mémoire

Niveau	Contenu	Où	Mécanisme
Utilisateur	ce que l’assistant retient de vous, compilé de vos conversations	Vault (wiki Karpathy), par utilisateur	écriture
Projet	notes durables d’un dossier	Vault (à venir, en injection manuelle — pour ne pas mélanger du perso dans un projet)	écriture
Company / connaissance	corpus de référence (droit du travail, jurisprudence, dossiers)	RAG (LightRAG)	lecture

Le niveau utilisateur est actif ; le niveau projet en écriture est volontairement laissé en injection manuelle (décision produit) pour éviter que du personnel se retrouve dans un projet partagé.

2. Le Vault — le wiki Karpathy (écriture)

Le Vault est un wiki personnel que le système compile automatiquement à partir de vos conversations.

Par utilisateur, sans fuite : chaque note est rattachée à l’utilisateur ; l’isolation est garantie au niveau des données. Personne ne voit la mémoire d’un autre.
Compilé, pas brut : on n’ingère pas les messages tels quels — un modèle compilateur distille les conversations en entrées de wiki durables (« ce qu’il faut retenir »). Ça évite de dupliquer les transcripts et de gonfler la mémoire.
Injecté dans le contexte : à chaque conversation, le wiki de l’utilisateur est injecté dans le prompt système (« ce que je sais de vous »), pour rester cohérent d’une session à l’autre.
Synchronisation : automatique 2×/jour (+ à l’inactivité d’un chat, + bouton « Remember now » à la demande). La compilation balaie toutes les nouvelles conversations depuis la dernière passe.
Modèle compilateur : un modèle cloud cheap et éditable (par défaut z-ai/glm-5.3-flash via OpenRouter), changeable sans redéployer le code.
Surveillé : un point de santé (/api/admin/memory/status) + une alerte signalent si la compilation s’arrête — pour ne jamais se retrouver « sans mémoire » sans le savoir.

Techniquement, le Vault est servi par un sidecar dédié (thecompai-memory, le compilateur Karpathy) qui partage la base de l’application et lit les conversations pour les distiller — l’application ne lui envoie que des identifiants, jamais le contenu en clair par le réseau.

3. Le RAG — les corpus de référence (lecture)

Le RAG (LightRAG) sert la connaissance partagée, en lecture.

Multi-bases : un registre de bases RAG (Paramètres → RAG databases) — on en déclare autant qu’on veut (droit du travail, jurisprudence pénale, un dossier volumineux…), chacune activable, testable (santé), avec un label de confidentialité (open / confidential).
Recherche sémantique : un embedder (bge-m3, dimension 1024) transforme la question et les documents en vecteurs pour retrouver les passages pertinents. L’embedder utilisé à l’interrogation doit être le même qu’à la construction de la base (sinon la recherche est incohérente).
Attaché à un projet, en lecture : on associe une base RAG à un projet (le picker dans la page Projet). Les conversations de ce projet interrogent cette base. Exemple : rattacher « jurisprudence pénale » à un dossier, ou injecter un gros dossier partagé et le mettre en lecture sur le projet des collaborateurs.
Confidentialité (D25) : une base = un seul label. Le Guardian empêche de mélanger du confidentiel et de l’ouvert dans une même recherche.

Contrairement au Vault (que le système écrit tout seul), une base RAG se peuple par injection d’un corpus (via OdyRAG / l’ingestion LightRAG), puis se lit. CoeOS peut aussi écrire dans une base company plus tard — pour l’instant c’est un corpus qu’on injecte, surtout de la lecture.

4. Comment ça se compose à l’usage

À chaque tour de conversation, CoeOS assemble le contexte en combinant :

le wiki de l’utilisateur (Vault) — « ce que je sais de vous » ;
le RAG company / la base liée au projet — les passages de référence pertinents pour la question.

Le modèle de chat reçoit ces deux apports en plus de la question, puis répond. Le Vault le rend cohérent dans le temps ; le RAG lui donne la matière documentaire.

5. Confidentialité

La mémoire (Vault) n’est pas dans le périmètre de confidentialité : elle est isolée par utilisateur et sert de contexte injecté. Le filtrage de confidentialité s’applique aux inférences et aux prompts utilisateur (via le Guardian), pas à la mémoire stockée. C’est ce qui la rend gérable.
Les bases RAG portent un label (open / confidential) et le Guardian garantit qu’une base confidentielle n’est pas mélangée à une base ouverte.
Pour un cabinet exigeant, l’embedder peut rester local (même modèle bge-m3 → bases portables), afin qu’aucun texte de document ne sorte à l’indexation.

En une phrase

Le Vault retient (par utilisateur, wiki compilé de vos conversations, injecté au fil des sessions) ; le RAG documente (corpus de référence, recherche sémantique, attaché à un projet en lecture). Deux mécanismes, deux rôles — et une mémoire qui, si elle casse, le signale au lieu de disparaître en silence.