Series: From Chess Heuristics to MOSAIC Intelligence
Author: Billy P
Contact: rqmeo@pm.me
Site: https://www.gcf-framework.com
THE BEGINNING
The Guided Cognitive Framework (GCF) started with what seemed like an elegant idea: use chess pieces to represent different levels of reasoning intensity.
Pawn for simple tasks. Queen for complex ones. King for strategic control.
It made perfect sense. Chess is about strategy, escalation, and hierarchical thinking. What could be more appropriate for an AI reasoning system?
Turns out: almost anything else.
This is the story of how a beautiful metaphor became an architectural nightmare, and why we had to tear it all down and start over.
THE CHESS MODEL
The original system looked like this:
[ KING ]
↑
[ QUEEN ]
↑
[ BISHOP ]
↑
[ ROOK ]
↑
[ PAWN ]
Each piece represented an escalation:
| Piece | Intended Meaning |
|---|---|
| Pawn | Minimal effort, quick response |
| Rook | Moderate reasoning depth |
| Bishop | Deep structured thinking |
| Queen | Maximum exploration |
| King | Strategic control |
The logic was simple: start with Pawn. If it fails, escalate to Rook. If that fails, go to Bishop. And so on.
Clean. Intuitive. Wrong.
WHY IT FELT RIGHT
In the early days, the chess model had real advantages:
1. Clear Mental Model
Everyone understands chess pieces. “This task needs Queen-level reasoning” is immediately clear.
2. Simple Debugging
When something failed, you could see the escalation path. “Failed at Rook, succeeded at Bishop.”
3. Easy to Code
A single enum. A single escalation function. Straightforward control flow.
For prototyping, it was perfect.
For production? Disaster.
THE FIRST CRACK: AMBIGUITY
Here’s where things started breaking down.
What does “Bishop” actually mean?
- More reasoning steps?
- More retries?
- More structured thinking?
- Broader search space?
All of the above? None of the above?
The chess pieces tried to encode multiple variables into a single dimension:
- Compute depth
- Execution strategy
- Retry behavior
- Confidence thresholds
Single-axis control for multi-dimensional problems.
This is like trying to represent a 3D shape with a single number. You lose information. You create ambiguity. You break things.
THE ARCHITECTURAL VIOLATION
The GCF has two core components:
OUTER CUBE = Compute allocation
INNER CUBE = Cognitive style (Analytical, Procedural, etc.)
These are supposed to be independent.
But the chess model violated this separation:
┌─────────────────────────────┐
│ OUTER CUBE (How much) │
│ │
│ Mixed with │
│ │
│ INNER CUBE (How to think) │
└─────────────────────────────┘
Faces started influencing compute.
Compute started influencing cognitive style.
The boundaries dissolved. The system became coupled. Changes in one part broke the other.
This was a design failure, not a feature.
THE BREADTH PROBLEM
Real tasks have two dimensions:
DEPTH: How deeply should I reason?
BREADTH: How widely should I search?
You need different combinations:
- Deep + Narrow: Solve one complex problem
- Shallow + Wide: Check many simple things
- Deep + Expansive: Explore all angles thoroughly
The chess model only had one axis:
Pawn → Rook → Bishop → Queen
↑ ↑ ↑ ↑
Simple → → → → Complex
Missing: Breadth control.
You couldn’t say “shallow but wide.” You couldn’t say “narrow but deep.”
One-dimensional control for two-dimensional problems.
THE PAWN BOTTLENECK
Every task started at Pawn.
Even tasks that clearly needed more resources.
The execution pattern looked like this:
1. Try Pawn
2. Fail
3. Escalate to Rook
4. Fail
5. Escalate to Bishop
6. Finally succeed
Result:
- Wasted computation on Pawn (guaranteed to fail)
- Increased latency (multiple retries)
- Poor first-pass success rate
- Unnecessary API calls
We were deliberately starting every task with insufficient resources.
It’s like trying to lift a 100kg weight by first attempting it with one hand, failing, trying with two hands, failing, then finally getting a forklift.
Just use the forklift from the start.
THE RESOURCE MAPPING FAILURE
Chess pieces were symbolic.
They described reasoning metaphorically, not structurally.
What does “Queen” actually allocate?
- How many cells?
- How much time?
- How many retries?
- What budget limits?
Answer: Who knows?
The chess model had no direct mapping to actual resources.
This made:
- Performance tuning impossible
- Budget control broken
- Scaling unpredictable
- Optimization futile
You can’t optimize what you can’t measure.
THE BREAKING POINT
The system hit a wall when we tried to add:
- Parallel processing (can’t encode parallelism in a linear hierarchy)
- Resource budgets (no way to map pieces to actual costs)
- Adaptive allocation (pieces are static, tasks are dynamic)
- Multi-objective optimization (chess pieces optimize for… what?)
The metaphor that enabled early progress became the constraint blocking further evolution.
WHAT WE LEARNED
Chess pieces were a narrative tool, not an execution model.
They helped us think about the problem.
They didn’t help us solve the problem.
The failure wasn’t in the idea. It was in mistaking the map for the territory.
We built a system around a metaphor.
We should have built a system around mathematics.
WHAT CAME NEXT
The chess system had to die.
But what would replace it?
We needed:
- Multi-dimensional control
- Direct resource mapping
- Deterministic behavior
- Clean separation from cognition
- Scalable architecture
We needed: MOSAIC.
NEXT IN SERIES
Part 2: MOSAIC – The Allocation Engine
How we replaced symbolic control with explicit, layered resource allocation.
Read time: 8 minutes
Series: GCF Architecture Evolution (Part 1 of 4)