thinking-ooda

What this skill does

# OODA Loop

## Overview
The OODA Loop (Observe, Orient, Decide, Act) is a framework for acting in fast-moving, uncertain situations. The core decision rule: don't wait for certainty—act on the best current understanding, then immediately observe the result and loop again. Speed through the loop beats a perfect plan that arrives too late.

**Core Principle:** Act on ~70% confidence for reversible moves, then re-observe. Cycle faster than the situation changes.

## When to Use
- Incident response and outages
- Debugging a moving target (intermittent failure, ongoing degradation)
- Any time-sensitive decision where the situation is still changing

```
Situation changing rapidly AND need to act before certainty? → yes → APPLY OODA
                                                              → no  → use deliberate analysis / a hypothesis differential
```

## When NOT to Use
- The situation is static and you have time → deliberate analysis beats fast looping.
- The action is irreversible/high-blast-radius → gather more information before acting; 70% confidence isn't enough.
- You can cheaply and directly localize the cause (read the diff/log) → use `thinking-scientific-method` (hypothesis differential) instead of looping in the dark.

## Trigger Card

When under time pressure (incident, outage, debugging a moving target) and you must act before certainty:

1. **Observe** — what is happening right now? Gather the cheapest, highest-signal data available.
2. **Orient** — what does it mean given your mental model? Update the model if the data contradicts it.
3. **Decide** — pick an action on ~70% confidence. Don't wait for 100%.
4. **Act** — execute, then immediately re-observe. The loop is the point; speed beats precision.

If the action is irreversible or high-blast-radius, gather more information before acting. If you can cheaply localize the cause (read the diff/log), use `thinking-scientific-method` instead.

## The Four Phases

### 1. OBSERVE — gather current state fast
- Current metrics, logs, alerts, error rates
- What changed recently (deploys, config, traffic)
- Feedback from your last action
- Cast wide, then narrow as a pattern emerges. Time-box it—don't observe forever.

```
Incident: error rate 10x normal; affects API gateway + user service;
started 5 min ago; a deploy went out 15 min ago; users report login failures.
```

### 2. ORIENT — make sense of it (the critical phase)
Match the observations to a pattern and form a hypothesis. This is where most loops go wrong: don't lock onto the first framing. Hold ≥2 candidate explanations and let new evidence shift you.

```
Pattern resembles last month's connection-pool exhaustion, BUT no DB anomaly this time.
The deploy touched auth rate-limiting.
Hypothesis: rate-limit config is too aggressive.
```

### 3. DECIDE — pick an action under uncertainty
- State the action and the hypothesis it tests.
- 70% confidence now beats 90% too late, for a reversible action.
- Decide what you'll observe next to confirm or refute.

```
Decision: roll back the auth deploy.
Hypothesis: this restores normal error rates.
Will watch: error rate for 2 minutes; fallback = investigate DB connections.
```

### 4. ACT — execute, then immediately re-observe
Execute decisively and go straight back to OBSERVE. The action creates new information; don't wait blindly for it to "settle."

```
Action: roll back deployment/auth-service.
Immediate observe: error rate, response times, 2-minute window.
```

The loop restarts until the system is stable.

## What Speeds the Loop
| Speeds it up | Stalls it |
|--------------|-----------|
| Pre-planned responses for known scenarios | Waiting for certainty (stuck at Observe/Decide) |
| Good observability (fast, trustworthy signals) | Information overload (Observe never ends) |
| Clear hypotheses (fast Orient) | Locking onto one hypothesis (Orient lock) |
| Reversible actions you can undo | Seeking the perfect fix (Decide never ends) |

## Application Patterns

### Incident Response
```
OBSERVE: metrics, logs, alerts, recent changes
ORIENT:  match pattern, form ≥2 hypotheses, assess blast radius
DECIDE:  mitigation (rollback, scale, disable feature)
ACT:     execute, immediately observe results
LOOP:    continue until stable
```

### Debugging Under Pressure
```
OBSERVE: errors, stack traces, recent changes
ORIENT:  form a hypothesis about the cause
DECIDE:  test the most likely hypothesis first
ACT:     add logging / try the fix / eliminate the possibility
LOOP:    update the hypothesis from the result
```

## Common Failure Modes
| Failure | Symptom | Fix |
|---------|---------|-----|
| Observation overload | Can't process all data | Filter to key indicators |
| Orientation lock | Stuck on one hypothesis | Force a second framing |
| Decision paralysis | Waiting for certainty | Set a decision deadline; act on 70% |
| Action without observation | Blind execution | Mandate observe-after-act |
| Not actually looping | Stuck in one phase | Time-box each phase |

## Key Questions
- "What do I observe RIGHT NOW?" (not 5 minutes ago)
- "What pattern does this match—and what's my second hypothesis?"
- "What's my best reversible action given current understanding?"
- "How will I know in the next 2 minutes whether it worked?"
- "Am I cycling, or stuck in one phase?"

## Boyd's Insight
"He who can handle the quickest rate of change survives." The goal isn't just making decisions—it's making and revising them faster than the situation compounds. Speed creates options; delay eliminates them.