Construct a cognitive map before deliberation begins.
Version: 2.1 (Protocol v8.0) Position: Sub-phase of POPULATE (steps 2b-2e) Inspired by: Benny Cheung's "Abstraction of Thought Makes AI Better Reasoners"
Humans think in abstractions: we decompose complexity into diagrams, mental maps, and conceptual relationships before processing details. LLMs default to linear, left-to-right token generation. ABSTRACT forces structured abstraction before detailed reasoning, improving synthesis quality by ~40% in validated experiments.
"Abstraction is the GPS for cognition: it answers 'Where am I?' and 'Where do I want to go?' BEFORE calculating the route."
1. SCOPE (+ NOOL) β 2. POPULATE [β
AoT: ABSTRACT] β 3. ANNOUNCE β 4. RUMBLE β 5. KNIT β 6. INTERROGATE β 7. TRANSMIT
ABSTRACT sits inside POPULATE (steps 2b-2e), between agent selection and ANNOUNCE. Personas are selected but have not yet begun debating. The abstraction map gives all participants a shared cognitive scaffold.
Break the decision into 3-5 key dimensions with sub-factors:
DECISION: "Should we pivot from B2B to B2C?"
DECOMPOSITION:
βββ Revenue implications
β βββ Current B2B revenue at risk
β βββ Projected B2C revenue potential
βββ Capability implications
β βββ Skills we have
β βββ Skills we'd need
βββ Timeline implications
β βββ Runway remaining
β βββ Time to B2C traction
βββ Identity implications
βββ Brand perception shift
βββ Team culture impact
Constraints: Max 4 branches, 2 levels deep. Broader is better than deeper.
Map the connections between dimensions:
Revenue βββββββ Timeline
β β
βΌ βΌ
Capability βββββ Identity
Relation types:
ENABLES/BLOCKSCONTRADICTS/SUPPORTSREQUIRES/UNLOCKSAMPLIFIES/DAMPENS
Constraints: Max 6 edges. Name each relation type explicitly.
Reframe the problem to prevent false-frame debates:
"This is a [PROBLEM TYPE] decision, not a [FALSE FRAME] decision." "The real question is: [REFRAME]."
Problem types: SEQUENCING | TRADEOFF | RESOURCE_ALLOCATION | ROOT_CAUSE | DESIGN | PREDICTION
decision: "Should we adopt Kubernetes for our infrastructure?"
decomposition:
- branch: Technical Fit
leaves: [Current stack compatibility, Team expertise, Migration effort]
- branch: Business Value
leaves: [Scalability needs, Cost impact, Time to value]
- branch: Risk Profile
leaves: [Operational complexity, Vendor lock-in, Security posture]
- branch: Strategic Alignment
leaves: [Cloud-native vision, Hiring implications, Partner ecosystem]
relations:
- Technical Fit β Risk Profile (complexity)
- Business Value β Technical Fit (ROI)
- Strategic Alignment β Business Value (justification)
- Risk Profile β Strategic Alignment (constraints)
abstraction_level: "Infrastructure platform selection (not implementation details)"
abstraction_statement: >
This is a DESIGN decision, not a RESOURCE_ALLOCATION decision.
The real question is: Does Kubernetes align with our 3-year infrastructure vision,
or are we solving a scaling problem that doesn't exist yet?| Depth Mode | AoT Required? | Types Applied |
|---|---|---|
| π Show Me | β No | Skip |
| β‘ Quick | π‘ Optional | Type 1 only |
| βοΈ Basic | β Yes | Types 1-2 |
| π£ Stress Test | β Yes | Types 1-3 |
| π§ Deep | β Yes | Types 1-3, multi-level |
| π€― Ultra | β Yes | Full + recursive iteration |
Without ABSTRACT: Personas argue from their own frames. North talks vision, South talks constraints, but they never share a map. The debate feels productive but misses structural connections.
With ABSTRACT: All personas receive the decomposition tree and relation map. Arguments reference shared dimensions. Clashes happen at the relation level ("You say Revenue ENABLES Timeline, I say it BLOCKS it"), producing sharper, more actionable synthesis.
ABSTRACT Phase Checklist:
[ ] Decomposition tree: 3-5 branches, max 2 levels
[ ] Relation map: max 6 edges, named types
[ ] Abstraction statement: problem type + reframe
[ ] All personas receive the map before ANNOUNCE
See also: PROTOCOL.md | DEPTH_MODES.md | TESSERACT.md