Series: From Chess Heuristics to MOSAIC Intelligence
Author: Billy P
Contact: rqmeo@pm.me
Site: https://www.gcf-framework.com
THE MISSING PIECE
MOSAIC gave us deterministic compute allocation.
But every execution started from scratch.
No learning. No optimization. No memory.
The system was making the same allocation decisions repeatedly, even when past executions provided clear signals about what works.
We needed the system to remember.
More importantly: We needed it to learn.
THE TESSERACT CONCEPT
Before diving into memory, we need to understand the complete architecture.
GCF is a tesseract — a four-dimensional cognitive structure.
The Two Cubes
┌─────────────────────────────────────┐
│ OUTER CUBE (COMPUTE) │
│ │
│ → MOSAIC allocation │
│ → How much to think │
│ → Depth × Breadth × Mode │
│ │
│ ┌─────────────────────────────┐ │
│ │ INNER CUBE (COGNITION) │ │
│ │ │ │
│ │ → Face selection │ │
│ │ → How to think │ │
│ │ → Analytical / Procedural │ │
│ │ │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
The Separation
| Layer | Responsibility | Examples |
|---|---|---|
| Outer Cube | Compute allocation | 4 cells, Medium depth, Wide breadth |
| Inner Cube | Cognitive style | Analytical reasoning, Procedural execution |
Critical rule: These cubes are independent.
Outer doesn’t dictate Inner.
Inner doesn’t request from Outer.
They coordinate, but never couple.
WHY SEPARATION MATTERS
In the chess system, everything was mixed:
"Bishop" meant:
- More cells? (compute)
- Deeper reasoning? (cognition)
- More structure? (strategy)
- Analytical approach? (style)
→ Undefined behavior
With Tesseract architecture:
Outer: "Use 4 cells, Medium depth"
Inner: "Apply Analytical reasoning"
→ Defined behavior
Clean boundaries = Predictable system.
THE MEMORY PROBLEM
Even with perfect allocation logic, the system was inefficient.
Example Execution
Task: "Debug authentication error"
First time:
→ Allocate: Medium × Wide = 4 cells
→ Face: Procedural
→ Result: Success
Second time (same type of task):
→ Allocate: Medium × Wide = 4 cells ← Same decision
→ Face: Procedural ← Same decision
→ Result: Success ← Same result
The system kept reinventing the wheel.
We needed:
- Pattern recognition: “I’ve seen this before”
- Optimization: “This allocation worked best”
- Adaptation: “Update strategy based on results”
We needed memory.
OLD SYSTEM: SINGLE-LAYER MEMORY
The first attempt was simple:
Memory = Map<TaskType, Allocation>
Problems:
- Volatile: Everything reset on restart
- No validation: Bad patterns persisted forever
- No promotion: Couldn’t distinguish proven patterns from noise
- No optimization loop: Couldn’t improve over time
It was a cache, not a memory system.
NEW SYSTEM: TWO-TIER ARCHITECTURE
The solution: Separate working memory from long-term storage.
Architecture Diagram
┌──────────────────────────────┐
│ HOT CACHE │
│ (Recent Tasks) │
│ │
│ → Fast lookup │
│ → Volatile │
│ → Unproven patterns │
└──────────────┬───────────────┘
↓
Promotion
(>5 successes)
↓
┌──────────────────────────────┐
│ LONG-TERM STORAGE │
│ (Proven Patterns) │
│ │
│ → Persistent │
│ → Validated │
│ → Optimized │
└──────────────────────────────┘
Flow
1. Task execution
2. Store result in Hot Cache
3. Pattern detection (same task type)
4. After N successes → Promotion
5. Long-term storage (persistent)
HOT CACHE: WORKING MEMORY
Purpose
Temporary storage for recent executions.
Characteristics
- Fast access: O(1) lookup
- Volatile: Clears on restart
- Unfiltered: All executions recorded
Structure
{
task_signature: {
allocations: [
{ grid: "Medium×Wide", face: "Procedural", success: true },
{ grid: "Shallow×Narrow", face: "Analytical", success: false },
{ grid: "Medium×Wide", face: "Procedural", success: true }
],
success_count: 2,
failure_count: 1
}
}
Why It Matters
Not every execution produces a pattern.
Hot Cache lets us observe trends before committing.
LONG-TERM STORAGE: PROVEN PATTERNS
Purpose
Persistent storage for validated allocations.
Promotion Criteria
A pattern gets promoted when:
Success count ≥ 5
AND
Success rate ≥ 80%
AND
Consistent allocation (same grid + face)
Structure
{
task_signature: {
optimal_allocation: {
grid: "Medium×Wide",
face: "Procedural",
mode: "Standard"
},
confidence: 0.95,
execution_count: 47,
last_updated: "2024-01-15"
}
}
Why It Matters
Long-term storage is expensive (disk I/O, persistence).
We only store proven, high-confidence patterns.
Filter noise. Keep signal.
MEMORY FLOW: COMPLETE EXAMPLE
Let’s trace how memory evolves.
Execution 1
Task: "Refactor authentication module"
No memory → Use default allocation
Allocate: Medium × Wide (4 cells)
Face: Procedural
Result: Success
→ Store in Hot Cache
Execution 2 (Similar Task)
Task: "Refactor login handler"
Hot Cache: 1 similar success
→ Use same allocation
Allocate: Medium × Wide
Face: Procedural
Result: Success
→ Update Hot Cache (2 successes)
Execution 5 (Similar Task)
Task: "Refactor session management"
Hot Cache: 4 similar successes
→ Use same allocation
Result: Success
→ Promotion triggered!
→ Move to Long-Term Storage
→ Mark as "proven pattern"
Execution 20 (Similar Task)
Task: "Refactor API authentication"
Long-Term Storage hit!
→ Immediate allocation
→ Skip decision logic
→ O(1) lookup
Result: Success (as expected)
The system learned.
BENEFITS OF TWO-TIER MEMORY
1. Noise Filtering
Not every success is a pattern.
Hot Cache: Try, observe, validate
Long-Term: Only proven patterns
Result: No false patterns persist.
2. Fast Lookup
Lookup order:
1. Long-Term (proven) → O(1)
2. Hot Cache (recent) → O(1)
3. Default logic (new) → O(n)
Result: Fastest path for repeated tasks.
3. Self-Optimization
More executions → Better patterns
Better patterns → Faster decisions
Faster decisions → More throughput
Positive feedback loop.
4. Persistence
Long-term storage survives restarts.
Result: System gets smarter over time, not per-session.
MEMORY + MOSAIC: THE COMPLETE SYSTEM
Now we can see the full picture.
Integrated Flow
Task Input
↓
Memory Lookup (Long-Term)
↓
Hit? → Use stored allocation
↓
Miss? → MOSAIC decision
↓
Memory Lookup (Hot Cache)
↓
Hit? → Bias toward recent success
↓
Miss? → Full classification
↓
MOSAIC Allocation
↓
Face Selection (Inner Cube)
↓
Execution
↓
Validation
↓
Memory Recording
↓
Pattern Detection
↓
Promotion (if criteria met)
Memory informs MOSAIC. MOSAIC updates memory.
PERFORMANCE IMPACT
Before Memory System
Every task: Full classification + allocation
Latency: ~200ms per decision
No learning between executions
Cold start on every restart
After Memory System
Known tasks: Memory lookup only
Latency: ~5ms for proven patterns
Learning accumulates
Patterns persist across restarts
Proven patterns: 40× faster decision time.
THE ADAPTATION LOOP
Memory enables something powerful: continuous optimization.
┌─────────────────────────────────┐
│ │
│ Execution │
│ ↓ │
│ Outcome │
│ ↓ │
│ Memory Recording │
│ ↓ │
│ Pattern Detection │
│ ↓ │
│ Better Allocation │
│ ↓ │
│ Better Execution ←──────────┘
The system improves with every task.
EXAMPLE: OPTIMIZATION IN ACTION
Track how allocations evolve:
Week 1
Task: "Debug API errors"
Allocation: Deep × Wide (6 cells)
Success rate: 60%
Week 2
Task: "Debug API errors"
Memory: Try Medium × Wide (4 cells)
Success rate: 85%
Week 3
Task: "Debug API errors"
Promotion: Medium × Wide is proven
Success rate: 95%
Latency: -50% (fewer cells)
The system found a better allocation through experience.
Nobody programmed this optimization. It emerged.
THE TESSERACT IN FULL
Now we can see the complete four-dimensional architecture:
┌─────────────────────────────────────────────┐
│ TIME (Memory Layer) │
│ │
│ Hot Cache ←→ Long-Term Storage │
│ ↓ ↓ │
│ ┌───────────────────────────────┐ │
│ │ OUTER CUBE (MOSAIC) │ │
│ │ │ │
│ │ Depth × Breadth × Mode │ │
│ │ │ │
│ │ ┌───────────────────────┐ │ │
│ │ │ INNER CUBE (Faces) │ │ │
│ │ │ │ │ │
│ │ │ Analytical │ │ │
│ │ │ Procedural │ │ │
│ │ │ Synthesis │ │ │
│ │ │ │ │ │
│ │ └───────────────────────┘ │ │
│ └───────────────────────────────┘ │
└─────────────────────────────────────────────┘
Four dimensions:
- Space (Depth × Breadth)
- Strategy (Mode)
- Cognition (Face)
- Time (Memory)
A true four-dimensional reasoning system.
WHY THIS MATTERS
Other AI systems are stateless.
Every execution is independent.
No learning between calls.
No optimization over time.
GCF is stateful.
Execution N → Memory
Memory → Execution N+1
The past informs the future.
WHAT’S NEXT
We have:
- ✅ Compute allocation (MOSAIC)
- ✅ Cognitive control (Faces)
- ✅ Memory and learning (Two-tier)
But how does it all come together in practice?
What does performance look like?
What’s coming next in the roadmap?
The final piece: Integration and future evolution.
NEXT IN SERIES
Part 4: The Complete System & Future Roadmap
How everything fits together, and where we’re going next.
Read time: 11 minutes
Series: GCF Architecture Evolution (Part 3 of 4)