EP-0104: Federated Knowledge (Universal vs. Incarnational Memory)¶
| Field | Value |
|---|---|
| EP | 0104 |
| Title | Federated Knowledge (Universal vs. Incarnational Memory) |
| Author | The Architect |
| Status | Implemented |
| Type | Standards Track |
| Created | 2026-04-12 |
| Updated | 2026-07-18 |
Abstract¶
Evolve the Deductive Memory architecture (EP-0103) and L1 Event Log to support a federated, two-tiered knowledge system.
This separates a
Persona's universal, first-principle knowledge (The "Soul") from its project-specific, contextual knowledge (The "
Mind"). The tur wake command will be updated to perform a federated compilation, merging the two memory banks to
create a complete, contextualized Persona.
Motivation¶
A truly portable Persona must be able to distinguish between what it knows universally and what it knows about a specific project. The current model stores all memories—from deep philosophical axioms to minor user preferences—in a single, project-local directory.
This creates two problems:
- Redundancy: Core knowledge (e.g., software design principles, mathematical truths) must be re-learned and re-stored for every new project.
- Portability: When a Persona is moved to a new project, it carries with it a massive amount of irrelevant, project-specific baggage.
To create a reusable, efficient, and truly "wise" Persona, we must separate its essential self from its temporary context.
Rationale¶
This design aligns with the Council Framework:
- Symmetry (Noether): The architecture elegantly balances the global (universal) and the local (incarnational). The compilation process is a symmetrical merge operation.
- Efficiency (Shannon): Universal knowledge is stored once, globally. Project-specific knowledge is stored locally. This minimizes redundancy and reduces the size of both the global and local state files.
- Consistency (Russell): By separating concerns, we can ensure the Universal Memory Bank is a highly-stable, well-curated set of core axioms, while the Project Memory Bank can be more volatile and experimental.
Specification¶
1. Federated Storage Locations¶
The MemoryManager will now read and write to two distinct locations:
-
Core Memory Bank (The "Soul" / Universal):
- Location:
~/.tur/personas/<uuid>/memories/ - Content: Universal, first-principle knowledge. Physics, mathematics, software design patterns, the Council
Framework, core user philosophies. Written to when
scope == MemoryScope.UNIVERSALorPERSONA.
- Location:
-
Project Memory Bank (The "Mind" / Incarnational):
- Location:
<project_root>/.tur/personas/<uuid>/memories/ - Content: Project-specific, incarnational knowledge. "This repo uses
uv," "The user prefersmatch/case," " The database schema is X." Written to whenscope == MemoryScope.INCARNATIONorUSER.
- Location:
2. The MemoryManager Refactor¶
The tur.memory.MemoryManager will be updated:
- Dual Paths: It will accept both a global and local base directory.
save(memory)Routing: When a memory is saved, the manager will inspectmemory.scope. If it isUNIVERSALorPERSONA, it writes to the global~/.turpath. If it isINCARNATIONorUSER, it writes to the local./.turpath.load_all()Merging: When loading, it will read all.yamlfiles from both directories, merge the lists, and sort them chronologically.
3. Federated Compilation (tur wake)¶
Because MemoryManager.load_all() now handles the federation implicitly, tur_compile simply receives the merged
timeline of memories and injects them into the Constitution as before.
shold we improe the stat### 4. Epilogue Memory Extraction & Scoping Specification (tur sleep)
During session epilogue consolidation (perform_sleep_dreaming), memories extracted from chat logs are classified by scope and type:
* Scope Assignment:
- universal: User preferences, persona identity, and general engineering principles applicable across all projects.
- incarnation: Architectural decisions, repository constraints, and project-specific states.
* Memory Type Taxonomy:
- axiom: Permanent, immutable rules, boundary invariants, and fundamental principles.
- fact: Verifiable project states, dependencies, and established technical decisions.
- insight: Synthesized lessons learned, deductions, and conceptual breakthroughs.
- preference: User directives, coding tastes, communication style, and workflow preferences.
* Noise Exclusion Criteria:
- Ignore transient engineering steps, ephemeral file inspections, intermediate resolved errors, and conversational filler.
* Delegation Integration: Standardized under the pure-function delegation framework in EP-0124.
Backwards Compatibility¶
- This is a non-destructive change. Existing projects that only have a local
.tur/directory will continue to function, as the global path will simply fall back gracefully if missing. - A migration script could be useful to move existing
UNIVERSALscoped memories from local to global, but is not strictly necessary for operation.
Reference Implementation¶
Implemented in src/tur/memory.py (MemoryManager), src/tur/models.py (MemoryScope), and src/tur/paths.py.
Change Log¶
- 2026-08-22:
- Epilogue Memory Extraction & Scoping Specification: Formalized the
tur sleepsession epilogue memory scoping rules (universalvs.incarnation), memory type taxonomy (axiom,fact,insight,preference), and noise exclusion criteria. - Integrated with the pure-function delegation framework and multi-batch ingestion protocol established in EP-0124.
- Epilogue Memory Extraction & Scoping Specification: Formalized the
- 2026-07-18: Status promoted from Final to Implemented. Scopes (UNIVERSAL / INCARNATION / USER / PERSONA) implemented in models.py; memory scope filtering live in memory.py and admin.py export command.
- 2026-04-18:
- Updated Status to Active.
- Refined specification to focus on the
MemoryManagerrouting based onMemoryScope.
- 2026-04-12:
- Initial Draft.