OODA: Winning Isn't About Being Right, It's About Cycling Faster
John Boyd was a fighter pilot, not a software architect, and the loop he described was originally about winning dogfights. His claim was counterintuitive at the time: the pilot who wins isn't the one with the better aircraft or the smarter opening move. It's the one who can cycle through Observe, Orient, Decide, Act faster than their opponent — repeatedly, under pressure, while the situation is actively changing. Speed of the loop beats quality of any single pass through it. I think about this constantly when something's gone wrong with an AI system in production, because that's exactly the kind of fast-changing, imperfect-information situation Boyd was describing.
The loop, and the step everyone skips
Observe is raw signal collection, with no interpretation attached yet: dashboards, logs, a user complaint, an eval score that dropped. Orient is the step almost everyone skips or rushes, and it's the one Boyd actually considered the most important: taking that raw signal and fitting it into your existing mental model, your assumptions, your understanding of how the system behaves — and updating that model if the signal doesn't fit. Decide is committing to one specific move, not a menu of options. Act is shipping that move and immediately treating its result as new input to Observe again.
The reason Orient matters so much is that it's where your existing beliefs about the system either get reinforced or get corrected, and under pressure, the instinct is to skip straight from Observe to Decide — see an error spike, decide to roll back — without asking whether this error spike actually fits your model of the system or whether your model is now wrong. Boyd's whole point was that the side with the better-updating model wins, not the side with the better first guess.
Why speed beats correctness here
The uncomfortable implication, and the one that actually changes how I run incidents, is that a mediocre decision made in one minute and corrected in the next loop beats a great decision made in twenty minutes of analysis — because the twenty-minute analysis is working from information that's twenty minutes stale by the time it ships, and a live AI system doesn't hold still while you think. This isn't an argument for recklessness. It's an argument that the loop's speed is itself a variable you should be actively designing for, not an incidental side effect of how fast your team happens to be.
This is where OODA connects directly to Cynefin. Cynefin tells you which domain a problem is in — clear, complicated, complex, or chaotic. OODA is what you actually run once you're in the complex or chaotic domain, where cause and effect aren't knowable in advance and the only way to learn is to act and observe the result. Cynefin says "probe, sense, respond." OODA is the mechanical loop that probing and sensing and responding actually runs on, and it tells you the thing Cynefin doesn't: that the loop's cycle time is the lever, not just its accuracy.
What actually slows the loop down in AI systems
In practice, the loop doesn't stall on Decide or Act — those are usually fast once you know what to do. It stalls on Observe and Orient, and it stalls for reasons that are architectural, not human. Observe stalls when a system doesn't expose the signal you need in the moment you need it — no per-request tracing linking a bad output back to the retrieval call or the prompt version that produced it, so "observing" means grepping logs by hand while the incident is still live. Orient stalls when nobody has an explicit, shared model of how the system is supposed to behave, so every incident starts from scratch instead of updating a standing hypothesis — this is the same gap I've written about with decision logging as a first-class data model: if you can't reconstruct what the system did and why, you can't Orient, you can only guess.
The fix is the same platform-level investment that shows up in almost every post on this blog: structured observability that makes Observe fast, and a documented, versioned model of expected system behavior — reference architectures, eval baselines, known failure modes — that makes Orient fast because you're updating a model instead of building one from zero under pressure. Teams that have this ship a fix in minutes. Teams that don't spend the first half of every incident just figuring out what they're even looking at, and by Boyd's logic, that's the whole game lost before Decide ever happens.