Background memory consolidation and associative discovery. Like human sleep, but for AI — the EMM system lets your AI accumulate experience, discover hidden patterns, and build unique knowledge over time.
An LLM provides reasoning. EMM provides personal experience. Together they form something closer to a mind.
Large language models provide general intelligence, language understanding, and logical reasoning. They process text, follow instructions, and generate responses. But they have no personal experience — every session starts from zero.
Eldric Matrix Memory provides persistent, compressed experience that accumulates over time. It remembers patterns from past interactions, discovers hidden connections during idle periods, and builds a unique knowledge base that no other instance shares.
Information flows upward through the hierarchy only with human confirmation. Each layer serves a different temporal and organizational scope.
Six fundamental operations power the entire memory system.
Add key-value association from conversation. The matrix accumulates experience through outer product updates.
M = decay * M + importance * (v ⊗ k)
Query the matrix for stored associations. Returns a compressed representation of all related knowledge.
output = M * query
Query with injected noise (temperature) to explore adjacent regions of the association space and surface unexpected connections.
output = M * (query + T * noise)
Post-conversation scoring and selective transfer to long-term layers. High-importance patterns are promoted; low-value ones are left to decay naturally.
Background random key blending during idle periods. Discovers hidden connections between concepts that were never explicitly linked in conversation.
Scheduled exponential forgetting with configurable rates per layer. Ensures the matrix stays focused on relevant patterns and does not saturate.
Based on Sepp Hochreiter's xLSTM architecture — the matrix variant (mLSTM) that replaces scalar memory cells with full matrices.
Traditional vector databases store exact embeddings and retrieve nearest neighbors. Matrix memory takes a fundamentally different approach: it compresses associations into a d×d matrix through outer products. This means the matrix generalizes — it captures the pattern of relationships, not individual data points. Recall is O(1), storage is bounded, and the system degrades gracefully as it fills.
EMM operates alongside the existing Data Worker vector storage. The matrix provides fast compressed recall for pattern-matching and association. The vector store provides exact, lossless retrieval of specific documents. Both are queried simultaneously and results are merged — the matrix surfaces connections while vectors provide citations.
Background daemon that manages dream cycles, memory consolidation, and the full .emm storage lifecycle.
| Flag | Default | Description |
|---|---|---|
--port | 8899 | Listen port |
--controller | — | Controller URL |
--data-workers | — | Data worker URLs |
--inference-workers | — | Inference worker URLs |
--dream-interval | 300 | Seconds between dream cycles |
--max-dream-cycles | 10 | Max cycles per session |
--dream-temperature | 0.2 | Noise level for creative recall |
--consolidation-threshold | 0.6 | Min importance to consolidate |
--memory-dir | auto | Path to .emm files |
http://localhost:8899/dashboard to monitor dream cycles, view discovered patterns, inspect matrix saturation, and manage the memory hierarchy in real time.Dreams are hypotheses, never autonomous actions. Every safeguard is hardcoded, not configurable.
Hardcoded kill switch. Dreams can NEVER modify source code, configuration files, or system state. The guardian constraint is compiled into the binary and cannot be overridden at runtime.
No dream discovery is automatically promoted to a higher memory layer. Scientists and operators must review each discovery, evaluate its validity, and explicitly confirm or reject promotion.
The dream process runs in an isolated sandbox with restricted filesystem access. It can only read existing .emm matrix files and write new matrix data — nothing else.
Every dream cycle is logged with full provenance: input keys, blended outputs, confidence scores, timestamps, and the reasoning chain. Audit logs are immutable and stored separately from matrix data.
Eldric Matrix Memory v3 binary format — crash-safe, checksummed, and designed for concurrent access.
| Property | Value | Details |
|---|---|---|
| Version | v3 | Current format version |
| Header | 128 bytes | Magic bytes, version, dimension, rank, CRC-32, SHA-256 checksum |
| Block Size | 64 KB | Fixed-size blocks with individual CRC-32 integrity checks |
| Crash Safety | WAL | Write-ahead journal ensures atomic updates — no partial writes |
| Recovery | Checkpoint + Replay | Full disaster recovery from WAL journal replay |
| Integrity | SHA-256 + CRC-32 | Per-block CRC for fast checks, full-file SHA-256 for verification |
| Endianness | Little-endian | Native x86/ARM format, no conversion overhead |
| Mode | Description | Latency | Durability |
|---|---|---|---|
| None | Single copy on local disk | Lowest | Single point of failure |
| Async | Background replication to backup data workers | Low | Eventual consistency |
| Sync | Synchronous write to all replicas before ACK | Higher | Strong consistency |
| Quorum | Majority of replicas must ACK before write completes | Medium | Majority consensus |
| Domain | Initial Rank | Dimension | Use Case |
|---|---|---|---|
| chat | 64 | 768 | Conversation memory |
| code | 128 | 768 | Code patterns and idioms |
| particle_physics | 512 | 1024 | LHC experiment data |
| genomics | 256 | 1024 | DNA/protein sequences |
| seismic | 256 | 768 | Earthquake patterns |
| robotics | 128 | 512 | Motor control patterns |
| general | 64 | 768 | Default configuration |
Full REST API for dream management, memory operations, and system monitoring.
| Endpoint | Method | Description |
|---|---|---|
| /health | GET | Health check |
| /dashboard | GET | Web dashboard |
| /api/v1/dream/status | GET | Current dream cycle status |
| /api/v1/dream/trigger | POST | Manually trigger dream cycle |
| /api/v1/dream/stop | POST | Stop current dream cycle |
| /api/v1/dream/history | GET | Dream cycle history with discoveries |
| /api/v1/dream/config | GET / PUT | Dream configuration |
| /api/v1/memory/store | POST | Store key-value in matrix |
| /api/v1/memory/recall | POST | Matrix recall |
| /api/v1/memory/creative-recall | POST | Recall with temperature noise |
| /api/v1/memory/consolidate | POST | Trigger consolidation |
| /api/v1/memory/matrices | GET | List all matrices |
| /api/v1/memory/checkpoint | POST | Checkpoint all matrices |
| /api/v1/memory/verify | POST | Verify block integrity |
Feature availability by license level.
| Feature | Free | Standard | Professional | Enterprise |
|---|---|---|---|---|
| Dream cycles / day | 3 | 20 | Unlimited | Unlimited |
| Memory layers | 3 | 5 | 7 | 7 |
| Creative recall | — | ✓ | ✓ | ✓ |
| Cross-experiment dreaming | — | — | ✓ | ✓ |
| Federated dreaming | — | — | — | ✓ |
| Custom decay rates | — | ✓ | ✓ | ✓ |
| .emm replication | — | — | Sync | Quorum |
| Dream workers | 1 | 2 | 5 | Unlimited |
Cross-institute knowledge sharing with privacy-preserving boundaries. Enterprise tier only.
Instead of sharing raw matrix data, institutes exchange compressed fingerprints — low-dimensional signatures that describe the shape of discovered patterns without revealing the underlying data. A receiving institute can match its own discoveries against foreign fingerprints to find convergent research directions.
When two institutes independently discover similar patterns (high fingerprint cosine similarity), the federated layer flags this as a potential collaboration opportunity. No data is shared automatically — the system only surfaces that a match exists, leaving the decision to establish contact entirely to the researchers.