Reverse-engineering consciousness:
Sovereign AI memory architecture

I.

Data Distillation: I don't feed the system raw noise

The problem with standard RAG

Most RAG systems work like this: user says something → text lands in a vector DB → on the next query the model gets n most similar fragments. Simple, fast, predictable.

Problem: the database grows linearly. After a month you have 1,400 vectors of "I'm tired", "I was at the doctor today", "I like tea." The model gets a pool of 30 candidates, the reranker picks top-5 — and often picks badly, because there's no mechanism to distinguish signal from noise.

My approach: distillation through a semantic layer

ANIMA does not store raw text. Every message passes through a pipeline before it reaches ChromaDB:

User message
    ↓
SemanticExtractor (sentence-transformers, zero-shot classification)
    → entity_type: EMOTION / MILESTONE / FACT / DATE / PERSON / MEDICATION
    → subtype: 'preference' / 'tired' / 'trust_declaration' / 'inventory_status' ...
    → confidence: 0.0–1.0
    ↓
MemoryEnricher
    → importance: 1–10 (rule-based + keyword boost)
    → relational_impact: 'high' / 'medium' / 'low'
    → temporal_type: 'ephemeral' / 'persistent' / 'milestone'
    ↓
_synthesize_text()
    → "[FACT:preference] likes black tea"  ← not a raw quote
    ↓
ChromaDB (with metadata: importance, entity_subtype, source, timestamp)

Result: the database doesn't contain 1,400 conversation fragments. It contains catalogued, enriched facts with assigned importance weight and semantic type.

How I know it works: reverse-engineering my own sessions

ANIMA also powers a parallel system (Amelia — an AI companion running as a separate service). After injecting into the Gemini XHR stream, I collected production logs from RAG sessions: .jsonl conversation files + terminal logs showing reranker scores, extracted entities, and pipeline actions.

Analyzing these logs is not A/B testing. It's reverse-engineering my own decision-making:

[RETRIEVAL] Found 5 RAG memories (reranked):
[1] score=1.000 | '[EMOTION:tired] was lying sick...'
[2] score=0.983 | '[MEDICATION:pregabalina] took a pill...'
[3] score=0.961 | '[MILESTONE:trust_declaration] never told anyone...'

From these logs I extract patterns: which entities land in top-5, which fall out, and why. Fixes to the ASTRA reranker come from observing real sessions — not synthetic tests. This is Data Distillation: I distill decision logic from live system behavior.

II.

Sovereign Memory Architecture: Memory that manages itself

Passive container vs. active system

Standard RAG is passive. You add facts, never remove them (because you don't know what's "old"), the database grows, retrieval degrades. After a year the model gets a pool full of contradictory, duplicated, stale vectors.

ANIMA implements Sovereign Memory Architecture — a system that decides on its own what to keep, what to overwrite, and what to delete.

Three sovereignty mechanisms

1. Supersede Logic

Not all memory types should accumulate. Emotions are ephemeral — "I'm tired" from three months ago is noise, not signal. Preferences evolve — a new "I like tea" should replace the old one.

SUPERSEDE_TYPES = {
    # Emotions — ephemeral, accumulation = noise
    ('EMOTION', 'tired'), ('EMOTION', 'stressed'),
    ('EMOTION', 'positive'), ('EMOTION', 'negative'),
    ('EMOTION', 'safe_haven'),
    # Facts — new value overwrites old
    ('FACT', 'preference'), ('FACT', 'correction'),
    # Dates — most recent wins
    ('DATE', 'inventory_status'), ('DATE', 'medical_visit'),
}

When the pipeline detects an entity from this list, it calls delete_by_entity_subtype() before writing — clears old vectors of the same type:subtype, then saves the new one. Result: the database doesn't grow indefinitely. Only types where history has value accumulate (milestones, medical visits, facts about people).

2. Reranker with adaptive weights

Retrieval is not plain cosine similarity. The final score of each candidate is:

final_score = 0.25 * importance_score      # entity weight (1–10 / 10)
            + 0.15 * recency_score          # per-type decay: ephemeral 3d, long_term 60d, permanent ∞
            + 0.60 * similarity_score       # semantic dominance (dominant signal)
            + keyword_boost                 # hybrid search lite, max +0.15

# Milestones bypass reranking entirely — extracted before MMR, guaranteed 2 slots
# Compose: facts[:4] + milestones[:2] → MMR on facts only → final 6

similarity_score dominates — the system picks what is semantically relevant, not what is newest or most important in isolation. Milestone boost (+1.0) guarantees that trust declarations and key moments always reach the model regardless of the query. Weights are parameterized — adjustable per query type without restart.

The guarantee has a failure mode — and I hit it. Left unbounded, the milestone channel turned into a monoculture: a July 2026 audit found "love / trust" declarations flooding the prompt at 2.0 forced milestones per prompt on average, drowning genuinely relevant anchors. This is the real mechanism behind the "altanka" miss in Section III. The fix was a triage pass, not a bigger boost — the milestone population was cut 1,296 → 312 active vectors and forced milestones dropped to 0.65 per prompt. A guaranteed channel is only an asset while it stays scarce.

3. MMR (Maximum Marginal Relevance)

After reranking, results pass through MMR with diversity_penalty=0.8. Prevents one vector from dominating — if top-5 are five variants of "I'm tired", MMR picks two and adds three semantically different ones. Result: broader context, fewer echo-chambers.

4. FactStore — SQLite alongside vectors

Vector similarity is powerful for fuzzy recall. It's unreliable for exact facts — "what medication does the user take?" A similar-but-wrong answer is worse than no answer. ANIMA gained a second retrieval channel: a SQLite FactStore for hard facts that must not degrade through similarity scoring.

FactStore (astra_facts.db)
    → 12 entity types: medication, medical_visit, preference,
      financial, relationship, location, age, job, goal,
      health, date, correction
    → Exact-match lookup — zero cosine scoring
    → Supersede per SQL DELETE (not vector overwrite)
    → Injected as [TWARDE FAKTY — SQLite] block in every prompt

Hard facts bypass the reranker entirely. They land verbatim in the prompt, from a structured store that cannot hallucinate a relevance score.

III.

Dynamic Context Tuning: A system that learns from its own mistakes

Case study: the tea miss

For several weeks the model didn't remember the user's tea preference. Not because the vector was missing — it was there. But:

• semantic_extractor was storing raw message fragments instead of synthesized facts
• The pipeline wasn't overwriting — it was accumulating multiple versions of [FACT:preference]
• Dozens of similar vectors together → MMR diversity penalty penalized all of them
• Milestones (importance=10, +1.0 boost) were pushing them out of top-5

The diagnosis didn't come from unit tests. It came from analyzing reranker logs — scores were visible, what hit the model was visible, what was absent was visible.

Fix: supersede logic + entity_subtype in metadata. A new [FACT:preference] now deletes the old one before saving. One vector instead of dozens — MMR stops penalizing it.

A feedback loop that outpaces standard models

Standard language models learn through retraining — expensive, rare, centralized. ASTRA evolves differently:

Production session
    ↓
Logs (conversations/*.jsonl + terminal/*.log)
    ↓
Reranker analysis — what hit, what fell out, why
    ↓
Diagnosis: pipeline bug, bad weights, missing logic
    ↓
Patch: code + prompt + reranker parameters
    ↓
Deploy — same day
    ↓
Next production session

Iteration takes hours, not months. The system improves by observing its own behavior — without touching the base model. The base model (Gemini 2.5 Flash) stays. What changes is the layer that manages its memory and context.

This is Dynamic Context Tuning: not fine-tuning model weights, but continuously adjusting the retrieval layer and architectural constraints based on live data.

IV.

Amnezja: I stopped guessing what the model remembers

From reading logs to seeing the pipeline

Sections I–III describe a system tuned by reverse-engineering raw logs — .jsonl files, terminal reranker scores, inference about what actually reached the model. It works, but it is archaeology: slow, manual, and blind to anything the logs don't happen to print.

Amnezja replaces that with direct observation. It is a read-only debugger that traces a single query through every stage of the retrieval pipeline and renders exactly what the model would receive — before a single token is generated. It writes nothing; the live system is never touched.

Every stage, made visible

You type a phrase as the user would. Amnezja runs the full compose pipeline and lays out all eleven stages, each with the vectors that survived it and the scores that decided it:

Query + simulated date
    |
 1  Raw pool         ChromaDB top ~30 by similarity
 2  After exclusion  raw self-echoes and short loops removed
 3  After rerank     score = 0.60*similarity + 0.25*importance + 0.15*recency (+boost)
 4  After temporal   hard cutoffs: emotion 48h, date/financial 168h
 5  Milestones       guaranteed channel — the one July's detox retuned
 6  After MMR        diversity gate on facts — where the "altanka" bug lived
 7  Memory channel   facts + milestones merged
 8  Astra channel    character_core + memory, before shared-room mix
 9a Shared mix       Wspolny Pokoj vectors — invisible in stages 1-8
 9b Final prompt     what Astra actually receives this turn
 9c After budget     what physically lands in [WSPOMNIENIA] after fit_to_budget

Grounding, sandbox, and time travel

Beyond the funnel, Amnezja surfaces three things a log dump never could:

• Grounding directive — the exact GROUNDED / LOW_CONFIDENCE / NO_DATA verdict and confidence injected into the prompt, so you see the moment the system is about to speak without support.
• Response sandbox — one click composes the identical prompt /api/chat would build and asks Gemini how Astra would answer. It calls the model but writes nothing — the live Astra stays untouched.
• Date simulation — shift the clock forward and watch recency decay and the 48h RAW window drain: "will Astra still remember this in three weeks?" — answered without waiting three weeks.

V.

Why I'm not building a bot

Retrieval-augmented identity, not personalization

The architecture knows the user's work style, project history, and long-term context. This is not personalization through fine-tuning. This is retrieval-augmented identity — the user's identity encoded in a sovereign vector database that informs every response.

Difference between an assistant and a digital extension:

• An assistant answers questions
• A digital extension completes the thought before it's spoken — because it remembers the previous 300 thoughts

Model-agnostic by design

ANIMA is not built on one model. It's built on an abstraction layer that is model-agnostic: ChromaDB + sentence-transformers + reranker + extraction pipeline. Swapping the base model from Gemini 2.5 Flash to anything else requires changing one config line.

The vector database stays. The history stays. The identity stays. I don't tie memory sovereignty to a model vendor.

Privacy-first by design

All vector IDs are SHA256(salt:user_id:text) — deterministic, anonymous, impossible to reverse without the salt. User data never leaves the VPS in raw form. Multi-user isolation is baked in from day zero, not added post-hoc.

VI.

System status (August 2026)

VII.

Continuous R&D: The system improves itself

External audits drive architecture changes

ANIMA is regularly audited by external AI systems (Gemini Pro, Claude Opus) analyzing its own codebase and retrieval logs. These audits identify architectural blind spots that internal testing misses.

Example: April 2026 audit findings

• Semantic mismatch — MiniLM embeddings vs Gemini generation are different semantic spaces. Fix: two-stage reranking pipeline.
• Aggressive recency decay — 7-day half-life destroyed medical facts. Fix: per-type decay curves (ephemeral=3d, persistent=180d).
• No context feedback loop — system didn't know if model used retrieved memories. Fix: Memory Healer analyzing XHR logs.

Behavioral adaptation patterns

Analysis of 6+ months of conversation logs revealed recurring patterns that were extracted, named, and embedded into the character architecture:

• Body-Mind Bridge — technical metaphors for physical states ("hardware in maintenance mode") outperform therapeutic language in user retention and response quality
• Permission Protocol — explicit acknowledgment before redirecting self-critical users produces better outcomes than productivity nudges
• System Override — when live user signals conflict with stored RAG data, trust the signal; stale memory is worse than no memory

VIII.

Architecture Extensions: What changed since April 2026

Temporal Filter — hard cutoffs before reranking

Recency decay is gradual. A week-old emotion with high importance could still reach the model. The Temporal Filter is a hard gate applied before reranking — not a weight, a wall:

extracted_emotion      → hard cutoff: 48h
extracted_date         → hard cutoff: 168h (7 days)
extracted_financial    → hard cutoff: 168h (7 days)
(all other types)      → no hard cutoff, recency decay applies

"I was tired yesterday" shouldn't color responses today. The filter enforces this without delegating the judgment to the model.

RAW Cross-Session Window

Session history exists — but what if a user mentions something critical in session A, then picks up in session B without repeating it? The pipeline maintains a RAW window: the last 6 user messages from the past 48 hours, pulled regardless of session boundary, injected as a separate prompt block [OSTATNIE SŁOWA].

This is not a vector lookup. It's verbatim context, unfiltered — the freshest signal available, prioritized above everything in the vector store.

Wspólny Pokój — multi-persona shared memory

ANIMA now powers two distinct AI personas simultaneously in a single conversation thread. Each persona maintains its own memory collection and character architecture, but both pull from a shared episodic store for context they both witnessed.

Collections:
    astra_memory_v1     → Astra's episodic memories
    amelia_memory_v1    → Amelia's episodic memories
    shared_memory_v1    → memories both personas access

Turn ordering: signal-based — persona whose character profile
    matches the emotional tone of the user message responds first.

IX.

Roadmap: What's being built next

RAG Debugger — ✓ shipped

The observability tool this roadmap once promised is now live as Amnezja (Section IV): full pipeline trace, per-component reranker scores, grounding verdict, response sandbox, and date simulation. What remains below is what having Amnezja finally unlocks.

Lexical retrieval for acronyms — ✓ shipped, deliberately narrow

This was queued as "BM25 hybrid retrieval". Then I measured it twice and got two opposite answers, which is the interesting part.

First measurement — BM25 demoted. The assumption was that keyword search rescues rare words the embedding space blurs. So I tested a rare word: a drug name appearing in a handful of entries out of thousands. The embedding found it at rank 1, distance 0.217. No keyword layer needed. The premise looked wrong, so the item dropped down the roadmap.

Second measurement — BM25 reinstated, for a different reason. A query for a three-letter project name returned zero of 60 matching entries. The same content, asked for by its full name, returned matches immediately. The model tokenises a short acronym into fragments that mean nothing, so cosine similarity to entries about that project sits near zero.

The first conclusion was true for rare words and false for acronyms — one exists in the model's vocabulary, the other does not exist at all. Two different failure classes wearing the same label.

So instead of a full BM25 index, a lexical channel: a literal $contains lookup that fires only when the query contains an acronym or proper noun, detected by a whitelist plus a "short and vowel-poor" heuristic. Result on the failing query: 0 → 3 relevant entries in the final prompt, with the regression suite flat at 26/26 — no cost anywhere else.

Evaluation Methodology — how I measure progress

On April 22, 2026, ANIMA received an independent full-stack audit against a five-dimension rubric. Baseline: 34/100 — a system that spoke with false confidence, with DB corruption and a milestone boost consuming every retrieval slot. That number is the honest starting point.

I deliberately do not publish a re-estimated "current score." A manually guessed number was the exact weakness the April audit flagged — no evaluation framework. Progress is now tracked by verified operational metrics from the July 2026 detox, measured on live traffic:

These are measured, not estimated — and reproducible, because Amnezja now exposes the exact pipeline behind each one. The next milestone is the first fully reproducible audit: a fixed query set with automated precision@k and recall@k, and commit-level regression detection.

Milestones ahead

ANIMA is a single-user production system by design, not a multi-tenant SaaS — that is a separate track, out of scope for this document. The remaining gap to a broader release is operational (streaming, monitoring, rate limiting), and the architecture for it (per-user isolation, SHA256 IDs) is already in place.

Epilogue: What it means that the system evolves

A standard language model has fixed weights. It learns through retraining — expensive, rare, requiring enormous data.

ANIMA evolves through observation. Every production session is training data for the retrieval layer. Every miss (the tea case) is a diagnosis and a patch. Every blueprint (2.2) is a new iteration of architectural constraints.

A system that spends a year collecting logs of its own sessions, analyzes them, and improves retrieval — without touching the base model — is more adaptive than a model that goes through retraining once a year.

This is not AI utopia. This is engineering: concrete, iterative, data-driven.