Modern joint operations do not respect domain boundaries. A missile strike degrades a radar network; a cyber intrusion slows C2 response; GPS jamming throws ground navigation off by hundreds of metres. Training and analysis tools that treat these effects in isolation produce dangerously incomplete pictures of how conflict actually unfolds. Multi-domain operations (MDO) wargaming software must model all five domains simultaneously and – more importantly – model the interactions between them.

Why single-domain simulators fail for MDO

Most legacy wargame platforms were built to answer a single question: how does the land battle unfold, or how does the air campaign develop? That heritage is now a structural liability. A ground manoeuvre simulator with no air-threat model cannot represent the suppression of enemy air defences that precedes an armoured thrust. A maritime simulator with no cyber layer cannot represent the spoofed AIS tracks that mask a surface action group.

The specific failure modes compound each other. First, there is no cross-domain effects model: kinetic events in one domain do not change the operating environment in another. Second, there is no joint fires model: surface-to-air engagements, land-based fires called by an airborne FAC, and maritime strike all exist in separate execution queues with no shared target database. Third, the cyber and space layers are missing entirely, or – worse – are represented as binary on/off flags rather than graded degradation functions.

The operational consequence is that training audiences rehearse decision-making against a sanitised environment. They learn to synchronise organic fires but never face a scenario where their GPS-aided artillery loses sub-metre precision mid-mission because an adversary has jammed the L1 band. They rehearse C2 procedures but never experience the compounding latency that follows a successful intrusion into a tactical data-link aggregator. MDO wargaming software must close all three gaps simultaneously, or it reproduces the same blind spots it was meant to eliminate.

Domain models and their interaction surfaces

A well-architected MDO simulator maintains five domain engines, each with its own state representation, time-step logic, and agent population. The engines run concurrently and expose a defined interaction surface – a set of shared state variables that other engines can read and write.

Land manoeuvre tracks unit positions, logistics states, terrain-modified mobility, and direct/indirect fires. Its primary outputs to other domains are target coordinates (feeds joint fires), electronic signature data (feeds cyber/EW), and route-network status (feeds space-based ISR queries).

Air campaign models sortie generation, fuel/ordnance states, threat envelopes, and sensor footprints. It reads from the land domain to resolve surface-based threat pop-ups and writes to the land domain when strikes occur. Its interaction surface with the space domain is continuous: airspace picture quality degrades as ISR satellite passes are denied.

Maritime covers surface, subsurface, and amphibious elements. It interacts with the air domain through carrier air wing generation and integrated air defence coordination. Its cyber interaction surface is particularly sensitive: modern warships run integrated platform management systems where a single intrusion can affect propulsion, navigation, and weapons simultaneously.

Space is the domain most frequently reduced to a flag in legacy tools. A proper space model tracks constellation health per orbital shell, computes GPS position-error ellipses as a function of jamming power and geometry, and degrades ISR imagery availability as a function of satellite tasking conflicts and uplink disruption. Space outputs flow continuously into every other domain engine – navigation accuracy for land manoeuvre, targeting quality for air strike, precision for maritime navigation.

Cyber models network topology, intrusion paths, and service-degradation cascades. Unlike kinetic domains, its time-step is measured in milliseconds to seconds rather than minutes to hours. The cyber engine must expose a latency-injection API that other domains query when resolving C2 actions – a ground commander's call for fire that would normally process in four seconds might take forty seconds after a successful intrusion into the brigade communications node.

Cross-domain effect chains

Modelling effect chains is the hardest engineering problem in MDO wargaming. Individual domain models are tractable; the combinatorial space of cross-domain interactions is not. The solution is an effect-chain graph with typed edges and propagation rules.

Consider three canonical chains. A kinetic strike on a ground-based radar creates a coverage gap in the integrated air picture. In code, this means the air domain engine removes the sensor node from its surveillance mesh, recalculates coverage polygons, and flags the degradation to the joint picture. Aircraft operating in that coverage gap now carry a higher threat uncertainty, which propagates into the OpFor's intercept probability calculations.

A cyber attack on a tactical C2 aggregator injects latency into every fire mission that routes through that node. The cyber engine writes a latency multiplier to a shared state table; the land and air domain engines read that multiplier when resolving any C2-dependent action. A fire-support request that nominally takes five minutes end-to-end might breach the engagement window for a time-sensitive target – the wargame captures this as a missed opportunity rather than a simple success/failure flag.

Space denial – specifically GPS jamming above a threshold effective radiated power – widens the circular error probable (CEP) of every GPS-guided munition in the affected area. The space engine computes a CEP multiplier as a function of jamming geometry and antenna gain. The land and air domain engines apply that multiplier when resolving strike accuracy. A precision strike mission planned against a 10-metre CEP requirement may fail its damage-expectancy threshold if the CEP has been degraded to 80 metres – a chain that connects electronic warfare decisions to kinetic outcomes across two domains.

Implementing these chains requires careful ontology work. Every shared state variable needs a schema, a unit of measure, a source domain, and a set of consuming domains. Version-control that schema like production code. Breaking changes to the effect-chain interface are the most common source of cross-domain simulation bugs, and they are extremely hard to detect without end-to-end integration tests that exercise all five domains simultaneously.

AI OpFor across domains

A credible OpFor in an MDO wargame cannot be a single monolithic AI agent. The decision spaces are too large and too domain-specific. The correct architecture is a federation of domain-specific AI agents that share intelligence through a common OpFor picture and coordinate through a joint-effects planner.

Each domain agent owns its force's tactical decisions within its domain. The land OpFor agent selects ambush positions, controls artillery allocation, and manages logistics. The air OpFor agent manages intercept vectors, suppresses friendly air defences, and controls ISR asset tasking. The maritime OpFor agent plans surface action group manoeuvres, submarine patrol routes, and anti-access corridor enforcement.

These agents share an intelligence common operating picture that aggregates detections across all domains. When the land agent detects a friendly logistics convoy via an ISR feed, that sighting is available to the maritime agent if the convoy is moving toward an embarkation point, and to the air agent if an interdiction strike is within range. Intelligence fusion is the joint-effects planner's core function: it maintains the shared picture, resolves conflicts between domain agents competing for the same asset, and applies synchronisation constraints – no air strike within 500 metres of a friendly ground force without explicit deconfliction, for example.

The architecture described in our article on AI OpFor wargaming covers the behavioural tree and utility-scoring approaches that work well at the domain level. For MDO, the critical addition is the inter-agent communication protocol: each domain agent must be able to request support from other domains, and the joint-effects planner must be able to veto or prioritise those requests based on the global situation.

Scenario scripting and inject engine

No AI OpFor, however sophisticated, can replace the deliberate instructional design of a scripted scenario. The inject engine sits between the scenario author and the simulation state, and it is architecturally as important as any of the domain models.

A production inject engine needs four injection types. Pre-scripted events fire at a defined simulation time or on a defined trigger condition – a convoy reaches grid reference X, a satellite pass begins over area Y. These establish the narrative spine of the scenario and guarantee that key training objectives are encountered. Random injects introduce friction and uncertainty: equipment failures, weather changes, civilian presence in an engagement area. They are sampled from probability distributions and fire within defined windows, ensuring no two runs of the scenario are identical.

Adversarial AI injects are generated by the OpFor agents rather than the scenario script. They represent the AI's response to blue force decisions – if the training audience chooses an unexpected axis of advance, the land OpFor agent generates an inject that repositions its reserve. This keeps the scenario reactive without requiring a human controller to anticipate every possible blue course of action.

Controller injections are manual: a human exercise director observes the training audience's decision-making in real time and fires an inject to reinforce a learning objective, inject a complication, or recover a scenario that has gone off-script. The inject engine must expose a low-latency controller interface – a director who has to navigate five menus to fire an inject will always be too slow to make it instructionally relevant.

All four injection types write to the same shared state through the same API. The inject engine does not know or care whether an injection comes from a timer, a random draw, an AI agent, or a human director. This uniformity is what makes the architecture extensible – new inject sources plug in without modifying domain engine code.

Multi-participant federation

An MDO wargame with meaningful training value requires role players at domain workstations – a maritime cell, an air operations cell, a cyber/EW cell, and a space effects coordinator, all operating simultaneously under a joint headquarters. The technical substrate for this is federation.

The High Level Architecture (HLA) standard, and its IEEE 1516 implementation, provides the object model and time-management framework needed to federate domain simulators. Each domain runs as an HLA federate. A joint federation object model (FOM) defines the shared object classes – units, effects, sensor contacts – and the interaction classes – fire missions, C2 messages, effect-chain events. Each federate publishes the attributes it owns and subscribes to the attributes it needs to read.

The detailed trade-offs between HLA and DIS, and the latency characteristics of each under high object-count scenarios, are covered in our article on distributed simulation with HLA and DIS. For MDO specifically, the key architectural decision is the FOM design: a poorly designed FOM that forces all cross-domain interactions through a single interaction class creates a bottleneck that degrades as scenario complexity grows. Model cross-domain effects as first-class FOM objects with their own publish/subscribe topology.

Role-player workstations need a filtered view of the joint picture – an air operations cell should see their organic assets plus the portions of the land and maritime picture that affect their mission planning, but not the full simulation state. Build role-player views as FOM subscription profiles that the federation management layer configures at scenario load time, not as hard-coded UI filters.

Analytics and after-action review

The training value of an MDO wargame is realised in the after-action review (AAR). A scenario that generates no analytically structured output forces instructors to rely on memory and notes – an approach that consistently misses the cross-domain interactions that MDO training is specifically designed to surface.

The AAR database must record every cross-domain event with a full context snapshot: the simulation time, the source domain, the effect chain triggered, the downstream state changes, and the decision-maker responsible. This enables the three most instructionally valuable AAR analyses.

Decision quality scoring across domains measures whether the training audience applied effects in the right sequence and at the right time. A ground commander who requested a cyber effect on an adversary radar 20 minutes before a penetrating air strike planned correctly; one who requested it 90 seconds before gave the effect chain no time to propagate. The AAR can surface this timing gap quantitatively.

Effect chain coverage analysis identifies which cross-domain chains were available in the scenario and which were exploited. A training audience that never used GPS-denial as a shaping operation despite having the capability available has a capability-awareness gap – the AAR makes this visible without requiring an instructor to have watched every decision point.

Missed-opportunity detection flags situations where a cross-domain effect was available, its preconditions were met, and no action was taken. This is the hardest analysis to automate well, because it requires the simulation to evaluate counterfactuals – what would have happened if the cyber attack had been executed at T+15? – but even a coarse version of this analysis, based on pre-computed effect-chain windows, is substantially more valuable than a purely descriptive AAR.

The Corvus Warg platform is built around this architecture: federated domain engines, a typed effect-chain graph, domain-specific AI OpFor agents with a joint-effects coordinator, and an AAR database that records every cross-domain event for structured replay and scoring.

If you are designing or procuring an MDO wargaming capability, the engineering requirements described above are non-negotiable minimums – not aspirational features. The interaction surfaces, the effect-chain graph, the inject engine, and the federation object model must all be first-class design artefacts, specified before a line of simulation code is written.

To discuss how these requirements map to a deliverable programme, visit our training simulation development services page or book a technical demonstration with the Corvus engineering team.