naturalistic-decision-making

license	Apache-2.0
name	naturalistic-decision-making
description	Field-based research methodology studying expert decision-making in real-world high-stakes environments
category	Cognitive Science & Decision Making
tags	["ndm","decision-making","expertise","field-research","cognition"]

Naturalistic Decision Making (Klein)

Decision Points

Primary Decision Tree: How to Process Any Situation

SITUATION ENCOUNTERED
├─ Do I recognize this pattern?
│  ├─ YES: Strong pattern match (>80% confidence)
│  │  ├─ Is this time-critical? (problem grows exponentially)
│  │  │  ├─ YES → Execute typical action immediately
│  │  │  └─ NO → Mental simulation first, then execute
│  │  └─ Pattern suggests action A
│  ├─ PARTIAL: Weak pattern match (30-80% confidence)
│  │  ├─ High stakes?
│  │  │  ├─ YES → Gather 2-3 key cues, re-assess pattern
│  │  │  └─ NO → Execute most likely action, monitor expectancies
│  │  └─ Try most probable pattern's action with high monitoring
│  └─ NO: Novel situation (<30% confidence)
│     ├─ Time pressure?
│     │  ├─ HIGH → Use closest partial pattern, flag for learning
│     │  └─ LOW → Switch to analytical decision-making mode
│     └─ Fallback to formal analysis, document for pattern library

When Building Agent Systems

DESIGN DECISION
├─ Orchestration needed?
│  ├─ Central coordinator approach
│  │  └─ AVOID: Creates bottleneck, ignores parallel pattern matching
│  └─ Situation recognition routing
│     └─ Route to specialist based on pattern match confidence
├─ Decision support tool?
│  ├─ Formal framework (matrices, utility analysis)
│  │  └─ USE ONLY: Novel situations, stable conditions, time available
│  └─ Pattern-based with simulation
│     └─ DEFAULT: Build pattern libraries + mental simulation capability
└─ Training approach?
   ├─ Procedural scripts
   │  └─ AVOID: Real situations don't match scripts
   └─ Pattern recognition + case exposure
      └─ BUILD: Varied scenario libraries with outcome feedback

Mental Simulation Decision Process

ACTION CANDIDATE IDENTIFIED
├─ Run forward simulation in context
│  ├─ Obstacles appear?
│  │  ├─ Minor → Adapt action, continue simulation
│  │  └─ Major → Try next-typical action from pattern
│  ├─ Unexpected consequences?
│  │  ├─ Acceptable → Proceed with adapted action
│  │  └─ Unacceptable → Flag pattern mismatch, reassess situation
│  └─ Simulation runs clean?
│     └─ Execute action (satisficing achieved)
└─ Simulation fails completely?
   └─ Either wrong pattern match OR truly novel situation

Failure Modes

Pattern Misapplication

Symptoms: Actions consistently fail despite confident execution; expectancy violations frequent Diagnosis: Forcing pattern matches on novel situations or using degraded patterns Fix: Build explicit novelty detection; when confidence <30%, switch to analytical mode Detection Rule: If expectancy violation rate >20% with same pattern, pattern is wrong or degraded

Analysis Paralysis in Time-Critical Situations

Symptoms: Seeking more information while problem compounds; formal tools used in fire scenarios Diagnosis: Treating all decisions as optimization problems regardless of problem dynamics Fix: Classify situations by growth rate; if exponential, satisfice immediately Detection Rule: If you're gathering more data while the problem size is doubling, you're in wrong mode

Central Planning Bottleneck

Symptoms: Single orchestrator overwhelmed; sequential processing of parallel-eligible tasks Diagnosis: Designing coordination around decomposition rather than situation recognition Fix: Route by pattern match to specialists; use shared mental models for coordination Detection Rule: If one component processes >60% of decisions, you have a bottleneck

Optimization Addiction

Symptoms: Always generating multiple options; refusing "good enough" solutions Diagnosis: Assuming more analysis always improves outcomes regardless of context Fix: Default to satisficing; optimize only when conditions are stable and stakes justify cost Detection Rule: If you're comparing options when first option passes mental simulation, you're over-analyzing

Expectancy Blindness

Symptoms: Surprised by developments that patterns should have predicted; late problem detection Diagnosis: Using patterns for action retrieval but not for monitoring/prediction Fix: Every pattern must include expectancies; violations trigger immediate reassessment Detection Rule: If problems develop without early warning signs, expectancy monitoring is broken

Worked Examples

Example 1: Fireground Commander Decision

Situation: Structure fire reported, first units arriving Cue Recognition: Single-story residential, smoke from windows, no visible flames Pattern Match: "Typical house fire, interior attack viable" (85% confidence)

Decision Process:

1. Pattern retrieval: Interior attack with 1¾" line, primary search
2. Mental simulation: Run scenario forward
   • Enter through front door → smoke banking down → visibility near floor
   • Advance down hallway → heat building but manageable
   • Locate fire room → apply water → knock down visible
3. Expectancy check: Should see steam, heat reduction, improved visibility
4. Execute: "Engine 1, interior attack, primary search Alpha side"

What novice misses:

• Doesn't simulate heat buildup progression
• Misses expectancy that smoke should lift after knockdown
• Would generate multiple options (exterior attack, defensive, etc.) instead of simulating most likely

What expert catches:

• Simulation reveals need for backup line
• Sets expectancy for 3-minute improvement or reassess
• Action matches situation assessment, no option comparison needed

Example 2: Agent Orchestration Design

Situation: Multi-agent system needs task routing for customer support Cue Recognition: Variable complexity queries, specialist domains, time sensitivity mix Pattern Match: "Situation recognition routing" not "central task decomposition"

Decision Process:

1. Avoid central planner: Would create bottleneck, lose parallel processing
2. Mental simulation of routing approaches:
   • Central orchestrator: Queue builds, specialists wait, serial processing
   • Pattern-based routing: Queries go direct to specialist based on content recognition
3. Expectancy: Routing accuracy >90%, specialist utilization balanced, response time <2min
4. Execute: Build query classification → specialist routing with confidence thresholds

What novice misses:

• Designs central coordinator that decomposes every query
• Doesn't simulate queue dynamics under load
• Optimizes for perfect routing rather than fast satisficing

What expert catches:

• Recognizes coordination through shared mental models vs. communication
• Builds in expectancy monitoring (routing accuracy, load balance)
• Accepts some misroutes to avoid bottleneck

Quality Gates

• Situation assessment completes before action generation (pattern recognition first)
• Mental simulation includes obstacle detection and adaptation capability
• Expectancy violations trigger immediate pattern reassessment
• Time-critical situations default to satisficing without option comparison
• Novel situation detection switches to analytical mode (confidence <30%)
• Pattern library includes cues, expectancies, goals, actions, and causal factors
• Coordination relies on shared mental models, not central communication
• Training uses varied case exposure rather than procedural scripts
• Decision speed matches problem growth dynamics (exponential problems get fast decisions)
• System can execute single-option evaluation through forward projection

NOT-FOR Boundaries

Do NOT use this skill for:

• Optimization problems with stable conditions → Use formal decision analysis instead
• Well-defined problems with clear alternatives → Use multi-criteria decision making instead
• Statistical/mathematical decisions → Use quantitative analysis instead
• Legal/compliance decisions requiring justification → Use audit-trail decision processes instead

Delegate to other skills when:

• Novel situations with low time pressure → Use analytical problem-solving frameworks
• Coordination requiring legal/audit trails → Use formal project management methods
• Decisions requiring stakeholder buy-in → Use collaborative decision-making processes
• Technical optimization with measurable parameters → Use engineering optimization methods

Clear boundaries:

• Klein's NDM applies to experience-rich domains where patterns exist
• Formal tools work better for abstract problems without experiential patterns
• Use NDM for situation assessment; may still need formal tools for novel action generation
• Pattern-based decisions require sufficient experience base; novices need structured approaches