thinking-map-territorylisted

# 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: ``` Expectation ≠ Reality? → yes → Are you trusting a model/abstraction? → yes → CHECK MAP-TERRITORY FIT ↘ no → Model exists but isn't explicit ↘ no → Model may be accurate (verify anyway) ``` ## Key Concepts ### 1. Maps Are Abstractions Every representation omits details: | Territory (Reality) | Map (Representation) | What's Lost | |---------------------|----------------------|-------------| | Running code | Architecture diagram | Ti