Foundation for the persistent, inspectable cognitive runtime: README, implementation plan with phases and risk register, architecture, security model, threat model, contributing guide, eight ADRs covering the global workspace, event immutability, memory representation, LLM abstraction, capability system, authentication, frontend and storage. Includes Makefile, env example, compose stack (pgvector) and Dockerfile skeleton, plus a record of the development environment assumptions.
1.8 KiB
1.8 KiB
ADR-0003: Memory representation
Date: 2026-09-14
Status: Accepted
Context
Noema needs episodic, semantic, procedural and autobiographical memory, working memory, decay without deletion, several retrieval mechanisms, provenance and relationships, and must not collapse epistemic categories.
Decision
- One
memoriestable with akinddiscriminator and shared columns (importance, salience, activation, retrieval stats, source, credibility, epistemic kind, timestamps) plus a typedcontentJSON document per kind. Go exposes distinct types; the shared table keeps relationships, search and retrieval uniform. epistemic_kindis a separate enum (observation, fact, memory, claim, hypothesis, belief, prediction, assumption, inference, opinion) present on memories, beliefs and evidence links.- Full-text search via a generated
tsvectorcolumn. Embeddings live inmemory_embeddings(memory_id, model, dims, embedding)created only if pgvector is available, so representations from different models are never mixed. - Relationships live in
memory_relationshipsand the generalentity_relationshipsgraph with confidence, provenance and timestamps. - Decay is a scheduled deterministic update of
activation; rows are never deleted by decay. - Working memory is an in-process bounded structure persisted in
workspace_statesafter each cycle.
Consequences
- Retrieval is a deterministic fusion of text, vector, recency, activation, importance and graph distance with per-component scores recorded.
- Loss of the embedding service degrades retrieval quality but never availability.
Alternatives considered
- Table per memory kind: cleaner typing but duplicated retrieval/relationship code and cross-kind queries become unions.
- Vector-only store: rejected by requirement; loses provenance and structure.