06-consolidation-version-history-management
Dec 7, 2025
Version History Management
Improvement: #4 of 4 Parent Doc: Experiment Improvements Status: Design Phase
Problem Statement
When UPDATE operations occur, previous memory information is lost. This creates several issues:
No Audit Trail: Cannot track what changed and when
No Rollback: Cannot revert to previous versions if mistake occurs
Lost Context: Historical information provides valuable context
Compliance Risk: Some domains require change history (legal, compliance)
Example: Lost Information
Design Goals
Primary Goals
History Preservation: Track all versions of a memory
Source Traceability: Link each version to source (email, user input, etc.)
Storage Efficiency: Minimize storage cost (don't duplicate full content)
Recoverability: Able to reconstruct previous versions
Auditability: Clear trail of what changed, when, why
Non-Goals
Full Content Retention: Not keeping full text of all versions (storage cost)
Automatic Conflict Resolution: Not implementing merge strategies (v1)
Branching: Not supporting multiple version branches (linear history only)
Core Concepts
Version vs Snapshot
Version: Lightweight reference to a point in time
Metadata about change
Source link (email thread, messageId)
Change summary (what changed)
Optional: diff or full content (recent versions only)
Snapshot: Full content at a specific version
Used for latest N versions only
Older versions pruned to save storage
Storage Strategy: Hybrid Approach
Data Structures
MemoryVersion
VersionedMemoryNode
Version Manager Implementation
Core API
Storage Schema
Graph Storage (FalkorDB)
Querying Version History
User-Facing Features
Version History UI
Rollback Operation
Testing Strategy
Unit Tests
Integration Tests
Performance Considerations
Storage Cost
Reconstruction Performance
Implementation Plan
Step 1: Types and Storage Schema (Day 7, Morning)
Tasks:
Define
MemoryVersiontypeDefine
VersionedMemoryNodetypeDefine
VersionPolicytypeCreate Cypher schema for version nodes
Deliverable: lib/types/memory-version.ts, schema migrations
Step 2: VersionManager Core (Day 7, Afternoon)
Tasks:
Implement
VersionManagerclassImplement
createVersion()Implement
applyPruningPolicy()Implement change summary generation
Deliverable: lib/storage/version-manager.ts
Step 3: Reconstruction Logic (Day 8, Morning)
Tasks:
Implement
reconstructVersion()Implement
reconstructFromEmailSource()Implement diff calculation and application
Add fallback strategies
Deliverable: Updated version-manager.ts with reconstruction
Step 4: Integration and Testing (Day 8, Afternoon)
Tasks:
Integrate with
DecisionTreeEngineUPDATE logicCreate unit tests (15+ test cases)
Create integration tests (5+ scenarios)
Test pruning and reconstruction
Deliverable: Tests + integrated version management
Success Criteria
Phase 4 Success Metrics
Versions created for all UPDATE operations
Pruning works correctly (old content deleted, metadata preserved)
Reconstruction success rate > 95%
Storage overhead < 3x original content size
Reconstruction latency < 2 seconds (from source)
All tests passing
Production Readiness
Version history queryable via API
UI can display version timeline
Rollback functionality works
Audit logs complete
Related Documentation
Experiment Improvements - Parent overview
UPDATE vs LINK Distinction - Previous phase
Decision Tree Logic - Integration point
Memory Node Types - Base memory schema
Change Log
Date | Author | Change |
|---|---|---|
2025-12-06 | Claude | Initial version history management design |