thinking-map-territory
Map-Territory Thinking
Overview
Map-Territory thinking, originated by Alfred Korzybski and popularized in general semantics, reminds us that "the map is not the territory." Every representation—mental model, diagram, metric, specification, or abstraction—is a simplified view that necessarily loses information. Confusing the map with the territory leads to flawed decisions, debugging dead-ends, and misaligned expectations.
Core Principle: All models are wrong; some are useful. The question is: how wrong, and useful for what?
When to Use
- Debugging when behavior doesn't match expectations
- Evaluating whether documentation/specs match implementation
- Questioning metrics that seem to tell the "full story"
- Architecture decisions based on diagrams or models
- When a "perfect plan" meets messy reality
- Resolving disagreements where parties hold different mental models
- Analyzing why estimates consistently miss reality
Decision flow:
More from tjboudreaux/cc-thinking-skills
thinking-scientific-method
Hypothesis → Prediction → Test → Revise with explicit falsification. Use for debugging, feature experimentation, performance investigation, and A/B testing design.
29thinking-model-router
Route to the right mental model based on your domain and problem type. The single entry point for all thinking skills.
29thinking-socratic
Systematic questioning framework to deepen understanding, challenge assumptions, and uncover hidden beliefs. Use for requirements gathering, debugging, coaching, and critical analysis.
29thinking-inversion
Approach problems backward by identifying paths to failure, then systematically avoiding them. Use for risk identification, planning, and avoiding obvious mistakes.
28thinking-probabilistic
Express confidence in ranges, update predictions with new information, and track calibration over time. Use for project estimation, risk assessment, and decision making under uncertainty.
27thinking-red-team
Deliberately attack your own plans, systems, and assumptions to find weaknesses before adversaries or reality does. Use for security review, architecture validation, plan stress-testing, and pre-launch preparation.
27