The Briefing: 0430, Al Udeid, and the Decision Architecture

It is 0430 and I am standing in front of a whiteboard at Al Udeid, drawing lines on a map that will become a C-17 flight plan in three hours. The crew is behind me. The weather officer has given me a window — a narrow one, between a sandstorm and a thunderstorm cell — and I have to thread a 285,000-pound aircraft through it with cargo that cannot be late and a fuel load that cannot be wrong.

I do not start with the airplane. I start with the constraint.

What is the latest arrival time? Work backward. What is the fuel burn at FL350 versus FL310? What if Balad closes and I have to divert to Ali Al Salem? What is my bingo fuel for that contingency? What does the threat picture look like along the southern corridor? Is there a NOTAM I missed?

I am not flying yet. I am not even close to flying. I am building a decision architecture — a layered set of instructions that accounts for what I know, what I don’t know, and what I need the aircraft to do when the plan falls apart.

Fifteen years later, I am sitting at a desk in my home office, building AI systems. And I am doing the exact same thing.

The Parallel Nobody in Silicon Valley Will Tell You About

The technology industry has a term for what I just described. They call it prompt engineering — the art of giving an AI model instructions that produce useful, accurate, reliable output. It is the hottest skill in tech right now. Companies are paying $200,000 a year for people who can do it well.

And here is what nobody in Silicon Valley will tell you: the best prompt engineers I have ever met are veterans who don’t know they’re prompt engineers.

This is not a metaphor. This is not a motivational speech about transferable skills. I am telling you that the cognitive architecture of military mission planning — the thing you did every day for four, eight, twenty years — is structurally identical to the cognitive architecture of AI prompt engineering. The same mental muscles. The same failure modes. The same solutions.

Let me show you.

Constraint-Based Planning: The Five-Paragraph Order as a System Prompt

Every military operation begins with constraints. Not goals — constraints. The goal is obvious: get the cargo there, hit the target, secure the perimeter. But the goal is useless without the constraints that shape how you achieve it.

  • You have X hours of darkness.
  • You have Y gallons of fuel.
  • The threat corridor is active between these coordinates.
  • The weather window closes at 0900.
  • You cannot fly above FL350 because of the RVSM waiver.
  • You must maintain radio silence inside this zone.

The plan is not “fly to Balad.” The plan is “fly to Balad given these constraints.” And a good mission planner knows that the constraints are more important than the objective, because the constraints are what keep you alive.

Prompt engineering works the same way. A bad prompt is: “Write me a report about defense spending.” A good prompt is:

  • You are a defense policy analyst writing for a congressional staffer.
  • Use only data from the FY2025 President’s Budget Request.
  • Limit the report to 1,500 words.
  • Focus on procurement line items over $1 billion.
  • Do not include classified programs.
  • Write in a formal but accessible tone — no jargon without definition.

The constraints are the prompt. The AI model, like the aircraft, will do whatever you tell it to do. If you give it vague instructions, it will give you vague output — the same way a flight plan with no fuel calculations will get you to the target, maybe, or into the side of a mountain. The precision of the constraint determines the quality of the result.

Every veteran who has ever written a five-paragraph operations order already knows this. You just didn’t know it had a Silicon Valley name and a six-figure salary attached to it.

Mission Decomposition: Chain-of-Thought Prompting Is a Pre-Mission Brief

In flight school, they teach you to break complex problems into sequential steps. Not because you’re too dumb to see the whole picture, but because in a dynamic environment, the whole picture is a lie. It is too complex to hold in your head while also flying an airplane, managing a crew, and talking to air traffic control.

So you decompose. You break the mission into phases: departure, en route, arrival, contingency. Each phase has its own decision points, its own go/no-go criteria, its own checklist. You don’t think about the arrival while you’re still in the departure phase. You think about what’s in front of you, execute it, and transition.

In AI, this is called chain-of-thought prompting — and it is one of the most powerful techniques in modern prompt engineering. Instead of asking the AI to solve a complex problem in one shot, you break the problem into steps and walk the model through each one:

  • Step 1: Identify the top five defense contractors by FY2025 revenue.
  • Step 2: For each contractor, list their three largest active DoD contracts.
  • Step 3: Calculate the percentage of each contractor’s revenue that comes from DoD.
  • Step 4: Rank them by DoD dependency.
  • Step 5: Write a one-paragraph analysis of the strategic risk for each.

Each step feeds the next. Each output becomes the input for the following phase. The AI doesn’t get confused because you didn’t ask it to do everything at once. You decomposed the mission.

This is not some advanced technique that requires a computer science degree. This is a Tuesday morning brief at squadron ops. You have been doing this your entire career. The only difference is that instead of a flight crew executing the phases, it is a language model. The cognitive skill is the same.

Contingency Thinking: Why Veterans Build Better AI Systems Than Engineers

Here is where veterans separate from the civilian tech world, and it is the gap that matters most.

In the military, you plan for failure. Not as an afterthought — as the primary activity. The main plan is the easy part. The contingencies are where the real planning lives. What if the primary target is obscured? What if comms go down? What if the tanker doesn’t show up at the air refueling track? What if the runway at the destination is closed?

You plan for each of these. You assign decision points — “if X happens by this time, we execute contingency Alpha.” You brief the crew on the contingencies before you brief them on the primary plan, because the primary plan will not survive first contact with reality.

In prompt engineering, this is called fallback prompting and guardrails. You build the AI system to handle failure gracefully:

  • If the model returns a response without a source citation, re-prompt: “You must cite a specific document for every factual claim.”
  • If the model exceeds the word limit, re-prompt with a compression instruction.
  • If the model hallucinates a statistic, run a verification chain that checks the claim against the source database before passing it to the user.
  • If the primary model is down, route to the backup model with adjusted parameters.

Every one of these is a contingency branch. Every one follows the same logic as “if Balad closes, divert to Ali Al Salem with X fuel remaining.” The structure is identical. The stakes are different — nobody dies if an AI prompt fails — but the cognitive discipline is the same discipline you built on a flight line at 0430 in the desert.

The civilian tech world does not train this way. Software engineers are taught to build for the happy path — the scenario where everything works. Veterans plan for the failure before it happens. In AI systems, where a single hallucinated answer can destroy user trust, that difference is worth more than a Stanford degree.

The After-Action Review Is a Feedback Loop: How Veterans Iterate Better

After every mission, we sat in a room and tore the plan apart. Not to assign blame — to learn. What worked? What didn’t? What did we miss? What would we change for next time?

The AAR is sacred in the military because it is the mechanism by which institutional knowledge compounds. You don’t just learn from your own missions. You learn from every mission the unit has ever flown, because the AARs are documented, shared, and incorporated into the next planning cycle.

In AI, this is the evaluation and refinement loop — the process by which you test a prompt, measure the output quality, identify failure modes, and iterate. The best AI systems are not built by writing one perfect prompt. They are built by running the prompt a hundred times, reviewing the outputs, finding the patterns of failure, and adjusting the constraints until the model consistently delivers what you need.

  • Run the prompt. Read the output.
  • Identify where the model deviated from the intent.
  • Adjust the constraint that allowed the deviation.
  • Run it again. Compare.
  • Document what changed and why.

This is an AAR. The format is different — you’re reviewing text outputs instead of flight data recorder tapes — but the discipline is identical. Hypothesis, execution, evaluation, adaptation. The OODA loop. Whatever you want to call it, you’ve been doing it since your first day in uniform.

The tech industry is just now discovering that iterative evaluation is the key to reliable AI systems. Veterans have been doing iterative evaluation under life-and-death conditions for decades. The muscle is already built. You just need to point it at a different target.

The Briefing Mindset: Calibrating Altitude for Every Audience

There is one more skill that veterans carry and the tech world desperately needs: the ability to communicate a complex plan to a diverse audience under time pressure.

In the military, you brief up and you brief down. You take the same mission — the same complexity, the same constraints, the same contingencies — and you deliver it to a one-star general in five minutes and to your crew in thirty. You adjust the resolution. You know what the general needs to hear and what the crew needs to hear, and they are not the same things.

This is exactly what you do when you design an AI system for different users. The CEO needs a dashboard. The analyst needs the raw data. The customer needs a plain-English summary. The system prompt that drives each of these outputs must be calibrated to the audience — the same way a mission brief is calibrated to the rank and role of the person receiving it.

The ability to adjust the resolution of communication — to move between strategic and tactical — is one of the rarest skills in the tech industry. Engineers build for engineers. Veterans know how to translate because they have spent their careers translating between people who make decisions and people who execute them.

The Gap: Why Military-to-Tech Translation Is Still Broken

So why don’t more veterans know this?

Because the military-to-civilian transition industry is broken. It is built around resume translation — turning “led a 12-person fire team” into “managed a cross-functional team of 12.” It takes the most interesting, hard-won cognitive skills a veteran has and flattens them into corporate jargon that makes a hiring manager’s eyes glaze over.

Nobody is telling the infantry sergeant who spent ten years planning room-clearing operations that she has been practicing constraint-based decomposition — the single most valuable skill in AI system design. Nobody is telling the logistics officer who managed supply chains across three continents that he has been building the mental model for retrieval-augmented generation. Nobody is telling the intelligence analyst who fused data from six different sources into a single actionable brief that she has been doing what AI engineers call “multi-source synthesis” since before the term existed.

The skills are there. The translation is not. And the result is that thousands of veterans are leaving the military every year with exactly the cognitive toolkit the AI industry needs — and nobody is making the connection.

What I Did With It: Four GPUs, Two Million Documents, Zero CS Degree

I am not writing this from theory. I built a four-GPU AI server in my home. I run open-source language models, a vector database with nearly two million embedded documents, and a retrieval-augmented generation pipeline that lets me ask questions of congressional legislation, defense acquisition regulations, Supreme Court opinions, and 50 books on rhetoric, strategy, and leadership.

I did not learn to do this in a computer science program. I learned the architecture in a mission planning room, the evaluation discipline in after-action reviews, and the constraint-based thinking on a flight line where getting the constraints wrong meant not coming home.

The technical skills — Python, databases, APIs — I learned as I went. They are the easiest part. Anybody can learn to code. Not everybody can learn to think in constraints, decompose problems under pressure, plan for failure before success, and iterate with the discipline of someone who has done it when lives were on the line. That is the veteran’s advantage, and it is real.

What This Means for You

If you’re a veteran who just separated and someone told you to “learn to code,” they gave you half the answer. The other half — the hard half, the half that takes years to build — you already have. Constraint-based planning. Mission decomposition. Contingency architecture. Iterative evaluation. Audience-calibrated communication. These are not soft skills. These are the core competencies of AI system design, and you earned them in the hardest classroom on earth.

If you’re a hiring manager in tech, stop looking for veterans who already have the technical keywords on their resume. Look for the ones who can describe how they planned a complex operation under uncertainty. That is your AI architect. Teach them the tools. The thinking is already there.

If you’re a veteran founder — if you’re building something and you feel like an imposter because you don’t have a CS degree — stop. You have something better. You have a cognitive framework forged under conditions that no bootcamp, no graduate program, and no Silicon Valley incubator can replicate. The mission planning room was your training ground. The AI industry is your next area of operations.

Grab the controls. You already know how to fly.

About the Author

Michael Komorous is the host of Voice for Valor, a podcast dedicated to sharing the stories of military veterans, first responders, and their families. A combat-rated Air Force officer, Mike served as a nuclear missile operator, C-17 pilot, and MQ-1 Predator pilot before managing rated personnel across the Air National Guard. His policy career spans legislative affairs, defense acquisitions, and geopolitical strategy at OSD Policy, including analysis of the war in Ukraine.

Today Mike builds AI systems and leads Alpha Zulu Solutions, a service-disabled veteran-owned small business focused on defense technology and government contracting. He holds advanced analytics training from George Mason University’s Innovation Lab.

Watch the podcast on YouTube | Visit voiceforvalor.com | Connect on Facebook