Wargaming for military doctrine development: methods and software

Military doctrine is expensive to get wrong. A procedural gap or a flawed concept of employment only reveals itself clearly when units attempt to execute it under operational conditions — at which point the cost of discovery is measured in time, resources, and mission failure. Wargaming offers a lower-cost alternative: a structured, adversarial game in which draft doctrine is applied by real players against a resisting opponent, and the outcomes are systematically analysed before the doctrine is codified.

This is distinct from the more widely discussed use of wargaming in operational planning. Doctrine wargaming is not rehearsing a plan — it is stress-testing a concept. The question is not "will this operation succeed?" but "is this procedure sound, and where does it break?" That distinction drives almost every design decision in how a doctrine wargame is structured, who participates, and what software needs to support it.

Doctrine wargaming versus operational wargaming

The two types share surface characteristics — players representing opposing forces, adjudicators resolving interactions, structured turn sequences — but their fidelity requirements and participant roles diverge substantially.

In an operational wargame, fidelity to the specific physical environment matters. Terrain, weather, unit positions, and force ratios must represent the actual operational situation with enough accuracy that the plan can be meaningfully tested. The players are the commanders who will execute the plan. The purpose is to identify synchronisation failures, anticipate adversary responses, and validate timing assumptions.

In a doctrine wargame, the scenario is purpose-built to create the decision conditions the doctrine is meant to address — not to represent a specific operation. The participants are often a mix of doctrine writers, subject-matter experts, and experienced operators who can recognise when the draft procedures produce unrealistic or unworkable outcomes. Critically, the rules of the game are themselves under examination. The adjudicators are not neutral arbiters of a fixed model; they are participants in a structured debate about which rules produce better military outcomes.

This has a direct software implication. The platforms used for operational wargaming are often high-fidelity constructive simulations with fixed physics models. These are generally unsuitable for doctrine wargaming because their resolution mechanisms cannot be modified to reflect the draft doctrine under test. A doctrine wargaming platform must support editable rule sets, structured data capture, and variant management — features that fixed training simulators were not designed to provide.

Questions doctrine wargaming can answer

Before designing a doctrine wargame, the team must define the specific questions the game is intended to answer. Vague questions produce vague results. The most productive categories of doctrine question for wargaming are the following.

Performance under friction and fog of war. A draft procedure may look coherent in a flowchart but fail when communications are degraded, when units are not where the procedure assumes they are, or when the timeline runs late due to delays in one node of the process. Wargaming forces players to apply the procedure in real time against an adaptive opponent, revealing these failure modes systematically rather than incidentally.

Procedural gaps. Draft doctrine often contains areas of ambiguity where two units are both responsible for the same task, or where neither unit's doctrine covers the handoff between phases. These gaps are extremely difficult to identify through document review alone because the author's mental model fills in the gaps without recognising them. Players encountering an undefined situation during a wargame will make it visible immediately — the game stops, and the gap is identified. A well-instrumented doctrine wargame treats these stoppages as data.

TTP refinement thresholds. Some Tactics, Techniques, and Procedures need refinement rather than wholesale revision. Wargaming can test variants — slightly different reporting formats, modified request-and-release procedures, adjusted task organisation — and compare outcomes across multiple game runs to identify which variant produces the best results under the scenario conditions.

Second-order effects. Doctrinal changes rarely affect only the process they directly address. Modifying fire support coordination procedures also affects communications load on the tactical operations centre, the workload of fire direction officers, and the timeline for adjacent units. Wargaming reveals these second-order effects by requiring the doctrine to be applied by a complete player set — not just the specialists who wrote it.

Wargame design for doctrine

Scenario selection

The scenario must create the specific conditions under which the doctrine under test will be exercised. This sounds obvious but is frequently violated. Teams build large, operationally realistic scenarios that generate interesting play but diffuse the doctrine question across too many competing variables. A doctrine wargame designed to test a new fire support coordination procedure should place the player cells in exactly the tactical situation where that procedure will matter most — not in a general combined-arms operation where fire support is one of many concurrent tasks competing for attention.

Narrow, purpose-built scenarios are almost always more productive than realistic large-scale scenarios for doctrine wargaming. The scenario is a test instrument, not a training exercise. Its job is to generate the conditions under which the doctrine will be stressed, as efficiently as possible.

Player and adjudicator structure

Doctrine wargames typically run with two to four player cells — Blue, Red, and optionally a White or Neutral cell representing civilian authorities, host-nation forces, or interagency partners. An adjudicator cell applies the rule set to player submissions and resolves outcomes. A control cell manages the session, injects scenario complications, and monitors whether the doctrine question is being actively tested.

One structural feature that distinguishes effective doctrine wargames from less effective ones is the use of dedicated observer-recorders assigned exclusively to documentation. These participants do not play. Their role is to record every instance where the draft doctrine produced an unclear outcome, where players improvised because the doctrine did not cover the situation, or where players disagreed about what the doctrine required. These observer records are often the most valuable output of the entire session.

Turn resolution rules and data capture

Turn resolution in a doctrine wargame must be designed around the questions the game is meant to answer. If the doctrine question concerns decision latency, the turn structure must create time pressure and log decision timestamps. If the question concerns information sharing, the game must restrict what each cell sees and log the communications between cells.

Data capture requirements must be defined before the game, not during or after. The analysis that will follow the game depends entirely on what was logged during play. Retroactively reconstructing decision sequences from participant memory is unreliable. The game design should specify: which events are automatically logged by the software, which are recorded by observer-recorders, and which are captured through structured player submissions at each turn.

Software requirements for doctrine wargaming

The software requirements for a doctrine wargaming platform are substantially different from those for an operational training simulation. The following features are non-negotiable for effective doctrine wargaming.

Editable rule sets. Every resolution mechanism — how long a request takes to process, what conditions cause a unit to become combat-ineffective, how supply consumption is calculated — must be a configurable parameter, not a compiled constant. The adjudicator cell must be able to modify these parameters between turns without restarting the session. The platform should maintain a change log recording every rule modification with its turn number, the parameter changed, the old value, the new value, and the rationale. This log is essential for post-game analysis: the team must be able to separate outcomes caused by player decisions from outcomes caused by rule changes.

Outcome logging for after-action review. Every player action, adjudicator decision, and outcome must be logged with sufficient detail to reconstruct the decision sequence in the after-action review. This means not just the final state of the game but the sequence of decisions that produced it — who submitted what, when, under what information conditions, and what the adjudicator determined. Structured logging also enables statistical comparison across multiple game runs, which is how doctrine conclusions achieve any statistical validity.

Scenario variant branching. Doctrine wargaming frequently requires comparing multiple rule variants against the same scenario. The platform must support rapid scenario reset and branch management so the same initial conditions can be run multiple times with different rule sets. The team should be able to complete multiple comparison runs within a working day rather than having to schedule separate exercise sessions weeks apart.

AI-assisted adjudication

Human adjudication is the bottleneck of most wargame sessions. A cell of adjudicators applying a complex rule set to simultaneous submissions from multiple player cells will slow the game to a pace that frustrates participants and reduces the number of turns that can be completed in a session. Fewer turns means less data. Less data means weaker conclusions.

AI-assisted adjudication addresses this by applying the configured rule set automatically to routine submissions — unit movement, supply requests, reconnaissance outcomes, standard engagement resolutions — and escalating only the edge cases to human adjudicators. The AI does not replace the adjudicator cell; it handles the volume of routine resolution so the human adjudicators can focus on the doctrinally ambiguous decisions that are the primary object of interest in a doctrine wargame.

There is a second function specific to doctrine wargaming that AI adjudication can perform: flagging rule inconsistencies during play. When the AI encounters a player action for which the current rule set produces contradictory or undefined outcomes, it should flag the event for the control cell rather than silently applying a default resolution. These flags are precisely the procedural gaps the wargame is designed to find. An AI adjudicator that surfaces them in real time rather than burying them in an end-of-day analysis significantly improves the quality of the doctrine output.

Building effective AI adjudication requires the rule set to be expressed in a machine-readable form — structured parameters and conditional logic, not prose. This is a design requirement that has implications for how doctrine itself is drafted. Doctrine that can be accurately encoded as structured rules tends to be more precise and less ambiguous than doctrine written as flowing text with implicit assumptions. Some doctrine teams have found that the process of encoding draft doctrine for wargame adjudication is itself a valuable consistency check, independent of the wargame that follows.

After-action review tooling

The after-action review is where the doctrine conclusions are actually formed. The quality of the AAR is directly bounded by the quality of the data captured during play and the tools available to analyse it.

Turn replay. The AAR tooling must be able to replay any turn in the game, showing the state of the game at each decision point, the player submissions, and the adjudicator resolution. This is particularly important in doctrine wargaming because the interesting questions are usually not "what was the final outcome?" but "at what point did the procedure produce an unexpected result, and why?" A static end-state display cannot answer this question. A full-sequence turn replay can.

Outcome visualisation. Doctrine teams need to see patterns across multiple runs, not just the details of a single run. The AAR tooling should visualise outcomes across all runs of a scenario variant — attrition curves, timeline comparisons, communication event frequency, decision latency at key gates — in a format that allows the team to identify which variants produced systematically different results. This visualisation does not need to be complex; clear time-series comparisons and summary tables are often more useful than elaborate dashboards.

Statistical summary across runs. A single game run is not evidence. The AAR tooling should generate statistical summaries across all runs of each variant: mean outcomes, variance, and the distribution of results across the player set. These summaries are what doctrine teams present to review boards when arguing that a proposed change produces measurably better outcomes. Without statistical aggregation, a doctrine wargame produces anecdotes rather than findings.

The integration between the wargaming platform and the AAR tooling should be seamless — the game logs flow directly into the AAR system without manual export and import steps that introduce data handling errors and delay the analysis. In extended doctrine wargame programmes that run over multiple sessions across weeks, this pipeline reliability is essential.

WARG: doctrine wargaming with AI adjudication and structured outcome capture

WARG is Corvus Intelligence's wargaming platform, designed to support exactly the kind of flexible, data-driven doctrine wargaming described in this article. Its architecture reflects the requirements that distinguish doctrine wargaming from operational training simulation.

The rule set in WARG is fully configurable: every resolution parameter is exposed through a structured interface that adjudicators and scenario designers can modify between turns, with automatic change logging. There are no compiled-in constants that would prevent the platform from reflecting draft doctrine accurately. This is the feature that fixed training simulators cannot offer and that makes the difference between a wargame that tests doctrine and a wargame that tests the simulator.

WARG's AI adjudication layer applies the configured rule set to player submissions at the pace the game requires, surfacing inconsistencies and undefined outcomes to the control cell in real time rather than deferring them to post-game analysis. The human adjudicator cell retains full override authority; the AI handles volume and flags edge cases. In doctrine wargaming sessions, these edge-case flags have consistently been among the most productive outputs of the game.

The outcome logging architecture captures the full decision sequence — player submissions, adjudicator resolutions, rule change events, and observer-recorder notes — in a structured format that feeds directly into the AAR system. Statistical summaries across multiple runs, variant comparison charts, and turn-by-turn replay are all available without manual data processing. Doctrine teams leave the session with analysis-ready data rather than a pile of notes that requires days of manual reconstruction.