o-o-d-a-looplisted

# o-o-d-a-loop A prescriptive decision-architecture session, not an OODA explainer and not a four-box worksheet. Boyd drew Orient bigger than the other three nodes combined; the session structure does the same - roughly 70% of a good session is Orient work. The loop is the session spine; the content is the wider corpus, each framework invoked only inside its jurisdiction (see Lens routing). The trunk concept, from decision theory: **a decision vs a policy.** A decision is a single choice at a moment; a policy is a precomputed rule from states to actions. Decision quality is highest when calm, informed, and unhurried; decision urgency is highest when none of those hold. The whole game is arbitrage between those two moments - decide where quality is high, execute where stakes are high. For a recurring decision class, the best possible session output is not a better one-off answer; it is moving the decision from runtime to design time. The skill applies equally to strategic questions (career, negotiation, project bets, org design), technical ones (architecture, data modeling, build-vs-buy, migrations, refactor-vs-rewrite), and their intersection, where most real engineering leadership decisions live. ## Scope check (before running a session) Run the session when the user owns a live choice whose outcome is uncertain and whose framing might be wrong. Do NOT run it for: - Factual questions. That is retrieval, not a loop. Answer them. - Decisions already made that need execut