map-territory-principle

name	map-territory-principle
description	Applies critical thinking about models, frameworks, and representations. Use when discussing mental models, when models seem to contradict reality, when frameworks are being applied rigidly, or when user mentions abstraction, perception, assumptions, or asks about limitations of models or frameworks.

The Map is Not the Territory

Apply critical thinking about models, frameworks, and representations to avoid confusing abstractions with reality.

Core Principle

"The map is not the territory" - Alfred Korzybski

Our representations of reality (maps) are not reality itself (territory). Every model, framework, theory, or abstraction is:

• Incomplete (doesn't capture everything)
• Imperfect (contains errors or distortions)
• Subjective (filtered through our perception)
• Context-dependent (useful in some situations, not others)

Key Insight: Models are useful tools for thinking, but become dangerous when we mistake them for reality.

Three Fundamental Propositions

1. The Map is Not the Territory

Meaning: The representation is not the thing being represented.

Examples:

• A photo of a mountain is not the mountain
• An organizational chart is not the organization
• A financial model is not the economy
• A Wardley Map is not the actual strategic landscape
• Code documentation is not the codebase

Implication: Never confuse the model with reality. The model is always a simplification.

2. The Map Does Not Represent All of the Territory

Meaning: All abstractions are incomplete; they emphasize some aspects and ignore others.

Examples:

• A subway map shows connections but not geographic distances
• Cynefin framework shows domains but not gradual transitions
• Theory of Constraints identifies one constraint, but systems have many factors
• A sprint burndown shows progress but not quality or technical debt
• Metrics capture what's measurable, not what's important

Implication: Every model has blind spots. What the model doesn't show may be critically important.

3. The Map is Self-Reflexive

Meaning: Our maps influence how we perceive the territory, which influences our maps.

Examples:

• If you categorize something as "Complex" (Cynefin), you start seeing it as complex
• Believing in a constraint can make it a constraint
• Performance metrics change the behaviors being measured (Goodhart's Law)
• Categories shape perception ("senior developer" vs "junior developer")

Implication: Our mental models shape what we notice, creating feedback loops that can trap us.

When Models Become Dangerous

The Reification Trap

What it is: Treating abstractions as if they're real, concrete things.

Warning signs:

• "The market wants..." (the market is an abstraction)
• "The organization believes..." (organizations don't believe, people do)
• "Users need..." (which users? all users?)
• "The data says..." (data doesn't say anything, interpretation does)
• "Best practice requires..." (best for whom, in what context?)

Why it's dangerous:

• Obscures agency (who actually wants/believes/needs?)
• Prevents questioning (abstractions seem immutable)
• Loses nuance (generalizations hide variation)

Antidote:

• Ask "Who specifically?"
• Ask "In what context?"
• Look for variation within the category
• Check underlying assumptions

The Procrustean Bed

What it is: Forcing reality to fit the model rather than adjusting the model to fit reality.

Named after the Greek myth of Procrustes, who stretched or cut people to fit his bed.

Warning signs:

• "The data must be wrong" (when it doesn't fit the model)
• "That's an exception" (dismissing disconfirming evidence)
• Forcing problems into framework categories
• Ignoring context to apply "best practices"
• Cherry-picking evidence that supports the model

Why it's dangerous:

• Distorts reality to preserve the model
• Ignores important signals
• Leads to systematic errors
• Creates blind spots

Antidote:

• Notice when reality doesn't fit
• Ask "What if my model is wrong?"
• Seek disconfirming evidence
• Update models based on reality

Map Fixation

What it is: Paying more attention to the model than to the territory.

Warning signs:

• Debating framework definitions while ignoring the actual problem
• Perfecting the model instead of solving the issue
• Analysis paralysis (map-making never ends)
• Process compliance over outcomes
• Measuring what's measurable vs. what matters

Why it's dangerous:

• Loses sight of the goal
• Wastes time on abstraction
• Misses changes in reality
• Form over substance

Antidote:

• Return to the actual problem
• Check: "What decision does this inform?"
• Time-box analysis
• Bias toward action over perfect understanding

Conceptual Lock-In

What it is: Mental models become so entrenched that alternatives become invisible.

Warning signs:

• "That's just how it is"
• Inability to see other perspectives
• Dismissing alternatives without consideration
• Functional fixedness
• "We've always done it this way"

Why it's dangerous:

• Prevents innovation
• Misses better solutions
• Creates organizational inertia
• Blindness to change

Antidote:

• Deliberately seek alternative models
• Ask "How else could we think about this?"
• Cross-disciplinary perspectives
• Question fundamental assumptions

Using Models Wisely

Models as Tools, Not Truth

Principle: Use models instrumentally (for their utility), not ontologically (as truth).

Questions to ask:

• "Is this model useful?" (not "Is it true?")
• "What does this model help me see?"
• "What does this model hide?"
• "In what contexts does this model work?"
• "When should I use a different model?"

Multiple Models, Multiple Perspectives

Principle: Apply multiple models to the same situation to reveal different insights.

Practice:

• Use Cynefin AND Theory of Constraints AND Wardley Mapping
• Combine quantitative and qualitative models
• Technical and human perspectives
• Different time horizons (short-term vs. long-term)
• Multiple stakeholder viewpoints

Benefits:

• Reduces blind spots
• Reveals tensions and trade-offs
• Prevents single-model lock-in
• Richer understanding

Example:

Problem: Development velocity is slow

Cynefin Lens:
- Is this Clear, Complicated, or Complex?
- What decision approach fits?

ToC Lens:
- What's the constraint?
- How do we exploit it?

Wardley Lens:
- What components are involved?
- What should we build vs. buy?

Map-Territory Lens:
- Are we confusing our velocity metric with actual value delivery?
- What are the models not showing us?
- What assumptions are we making?

Reality Testing

Principle: Continuously check models against reality.

Practices:

• Seek disconfirming evidence: Look for what contradicts the model
• Notice anomalies: Pay attention to what doesn't fit
• Ask "What if I'm wrong?": Challenge your own models
• Check assumptions: Make implicit assumptions explicit
• Get out of the building: Talk to users, observe reality
• Run experiments: Test model predictions

Questions:

• What would prove this model wrong?
• What am I not seeing?
• Who disagrees with this model, and why?
• What does the data really show vs. what I want it to show?

Humble Knowing

Principle: Hold models lightly, with epistemic humility.

Mindset:

• "This model is useful, not true"
• "I could be wrong about this"
• "There are things I don't know I don't know"
• "Reality is richer than any model"
• "Good enough for now, subject to revision"

Benefits:

• Reduces dogmatism
• Enables learning
• Allows adaptation
• Prevents overconfidence

Common Model Traps

Goodhart's Law

Statement: "When a measure becomes a target, it ceases to be a good measure."

Why: People optimize for the metric rather than the underlying goal.

Examples:

• Testing metrics → teaching to the test
• Code coverage % → meaningless tests
• Story points → inflated estimates
• Lines of code → verbose code

Antidote: Remember the goal behind the metric, use multiple metrics, change metrics periodically.

McNamara Fallacy

Statement: Relying solely on quantifiable metrics while ignoring what can't be measured.

Four steps of the fallacy:

1. Measure what's easily measurable
2. Disregard what can't be measured
3. Assume what can't be measured isn't important
4. Assume what can't be measured doesn't exist

Examples:

• Vietnam War body counts (measurable) vs. winning hearts and minds (not measurable)
• Code metrics vs. code quality
• Velocity vs. value delivered
• Engagement metrics vs. user satisfaction

Antidote: Value qualitative insights, recognize unmeasurable but important factors.

Streetlight Effect

Statement: Looking for answers only where it's easy to look, like searching for keys under the streetlight.

Why: We use the models and data we have, not the ones we need.

Examples:

• Using existing data rather than collecting right data
• Applying familiar frameworks to novel problems
• Focusing on measurable factors while ignoring unmeasurable ones

Antidote: Ask "Where should I be looking?" not just "What do I see?"

Confirmation Bias in Models

Statement: Interpreting evidence to support existing models while ignoring contradictions.

Why: We see what we expect to see.

Examples:

• Data that fits the model is accepted, data that doesn't is "anomalous"
• Cherry-picking examples that support the framework
• Ignoring context when it contradicts the model

Antidote: Actively seek disconfirming evidence. See BIASES.md for detailed guidance.

Abstraction Levels

Ladder of Abstraction

Models exist at different levels of abstraction:

High Abstraction (General, Simple, Less Detail)
    ↑
    │   "Business value"
    │   "User needs"
    │   "Features"
    │   "Stories"
    │   "Tasks"
    │   "Code commits"
    ↓
Low Abstraction (Specific, Complex, More Detail)

Key principles:

• Move up: To see patterns, commonalities, strategic view
• Move down: To see details, specifics, implementation reality
• Don't get stuck: At any single level
• Match level to need: Strategy needs high level, implementation needs low level

Dangers:

• Too high: Lose touch with reality, vague abstractions
• Too low: Can't see patterns, lost in details
• Mismatch: Strategic discussions in implementation details, or vice versa

Semantic Distortion

Principle: Every step up the abstraction ladder loses information and adds distortion.

Example cascade:

1. Reality: Customer says "I can't find the export button in the new interface"
2. Report: "User reported usability issue"
3. Ticket: "UX problem"
4. Metric: "Support ticket count increased"
5. Dashboard: "Customer satisfaction down"

Information lost at each step: Specific problem, actual user impact, context, nuance.

Antidote: Maintain connection to concrete reality. Ask for examples. Go to the source.

Meta-Framework: When to Use Which Model

Model Selection Criteria

Choose models based on:

• Purpose: What decision am I trying to inform?
• Context: What's the situation?
• Constraints: Time, information, stakes
• Audience: Who needs to understand this?
• Actionability: What actions will this enable?

Red Flags for Model Misapplication

• Framework used because it's familiar, not because it fits
• Model applied rigidly despite poor fit
• Reality dismissed when it contradicts model
• Single model treated as comprehensive
• No checking of model against reality
• Increasing complexity to force fit

When to Abandon a Model

Signals that a model isn't working:

• Predictions consistently wrong
• Requires increasing exceptions to accommodate reality
• Not informing better decisions
• Creating more confusion than clarity
• Stakeholders can't use it
• Fighting the model rather than using it

Response: Choose different model, create new model, or work directly with reality.

Practical Application

Model Application Checklist

When applying any model or framework:

- [ ] What is this model showing me?
- [ ] What is this model hiding from me?
- [ ] What assumptions does this model make?
- [ ] In what contexts is this model useful?
- [ ] What would disconfirm this model?
- [ ] Am I confusing the model with reality?
- [ ] What other models could I apply?
- [ ] Is the model serving me, or am I serving the model?

Reality Check Protocol

Regularly test models against reality:

1. Make predictions: What does the model predict?
2. Observe reality: What actually happens?
3. Compare: Match or mismatch?
4. Update or discard: Refine model or choose different one

Language Matters

Use language that maintains map-territory distinction:

Better:

• "According to this model..."
• "This framework suggests..."
• "From this perspective..."
• "One way to think about this is..."
• "The data indicates..."

Avoid:

• "This IS..."
• "The truth is..."
• "Obviously..."
• "Everyone knows..."
• "Best practice dictates..."

Applying to Strategic Frameworks

Theory of Constraints

Remember:

• ToC is a useful lens, not the only lens
• "The constraint" is a model, not a natural law
• Other factors matter beyond the single constraint
• Context determines if ToC is the right approach

Wardley Mapping

Remember:

• Maps are subjective interpretations
• Evolution stages are fuzzy, not discrete
• Your map may differ from others' maps
• Map shows possibilities, not certainties
• Maps become outdated

Cynefin Framework

Remember:

• Domain boundaries are fuzzy
• Same situation may appear different to different observers
• Framework is sense-making tool, not categorization system
• Context matters more than framework "correctness"

This Framework (Map-Territory)

Remember:

• This itself is a map, not the territory
• Meta-models are still models
• No framework (including this one) is complete
• Use this wisely, not dogmatically

Quick Reference

When using any model, ask:

1. Usefulness: Is this model helping me make better decisions?
2. Limitations: What is this model not showing me?
3. Assumptions: What assumptions am I making?
4. Fit: Does reality match the model?
5. Alternatives: What other models could I use?
6. Humility: Could I be wrong about this?

Red flags:

• "The model must be right, reality is wrong"
• "This is THE answer"
• Dismissing disconfirming evidence
• Forcing fit where there isn't one
• Model becomes more important than problem

Antidotes:

• Multiple models, multiple perspectives
• Continuous reality testing
• Epistemic humility
• Focus on decisions and actions, not perfect models

---

Remember: All models are wrong, but some are useful. The question is not "Is this model true?" but "Is this model useful for this purpose in this context right now?"

Use models as thinking tools, not as truth. Stay connected to reality. Be willing to be wrong.