Multi-domain operations dashboard: visualizing cross-domain effects

Multi-domain operations (MDO) require a commander to understand not just what is happening in each warfighting domain independently, but how actions and conditions in one domain create, enable, or degrade effects in others. A cyber intrusion that silences a land unit's communications has consequences that are invisible to a purely terrestrial C2 picture. A satellite communications disruption that degrades maritime task force coordination shows up as a degraded capability, not as a track on the surface picture. Building a dashboard that makes these cross-domain relationships visible — in real time, at the tempo of modern operations — is one of the harder unsolved problems in defense software.

This article examines the architecture of an MDO C2 dashboard: what domain-specific data each layer must ingest, how those layers are normalized into a common track representation, how cross-domain track correlation works, and how the system visualizes causal relationships between cyber effects and physical force elements. It is written for defense software engineers building or evaluating MDO-capable C2 platforms and for procurement teams assessing whether a candidate system genuinely handles multi-domain fusion or merely displays five separate single-domain windows side by side.

The MDO C2 challenge: five domains, five data models, one picture

Each warfighting domain has evolved its own data formats, message protocols, and update rates in relative isolation. Land C2 runs on Cursor on Target (CoT) XML messages that encode entity positions, unit identifiers, and status attributes using the MIL-STD-2525 identity schema. Maritime surface pictures are built from AIS (Automatic Identification System) for cooperative commercial and naval vessels, supplemented by radar tracks and tactical data links for non-cooperative contacts. Air pictures combine ADS-B transponder data — increasingly absent in contested airspace where military aircraft operate with transponders off — with ground radar, airborne early warning feeds, and SIGINT-derived tracks for non-emitting aircraft. Space domain awareness delivers orbital track catalogs and communications satellite status through specialized feeds with update cycles measured in minutes or hours. Cyber domain data arrives as network health telemetry, intrusion detection alerts, and vulnerability assessment snapshots from SIEM and network monitoring systems.

The operational tempos differ as sharply as the formats. An air track from a fast mover is operationally stale within seconds; a land unit track may remain valid for several minutes; an orbital element set may be accurate for hours. A well-designed MDO dashboard handles this heterogeneity without allowing the slowest-updating domain's staleness to contaminate the perceived currency of faster domains, and without the high-velocity air picture update rate starving resources needed to process slower but equally critical cyber threat feeds.

Classification level handling adds another layer of complexity. Many MDO environments operate across classification boundaries: some sensor feeds are SECRET, others are UNCLASSIFIED or handled under partner-nation information sharing agreements with release caveats. The MDO dashboard must enforce information-level controls at the track level, not just at the system boundary, ensuring that a fusion event cannot inadvertently expose a classified sensor source to a user cleared only for the unclassified picture.

Domain layers: what each feed contributes

Land picture: CoT tracks and ground unit status

The land domain picture is built from Cursor on Target feeds published by vehicle tracking systems, soldier-worn tracking devices, unmanned ground sensors, and C2 nodes. A CoT message encodes the publishing entity's UID, position (latitude, longitude, altitude with circular and linear error estimates), course, speed, and a type field that maps to MIL-STD-2525 symbology. Remarks fields carry freeform status data: ammunition levels, fuel state, personnel strength, and communications status reported by the unit itself.

MDO-relevant attributes in the land picture include: which units are within range of known enemy electronic warfare systems (derived by overlaying EW threat emitter positions from SIGINT), which units are dependent on satellite relay for their command net (relevant when space domain status degrades), and which units are co-located with or adjacent to other-domain assets such as forward-deployed air defense systems or maritime landing elements. These relationships must be maintained in the MDO data model, not inferred ad hoc at display time.

Maritime picture: AIS, tactical tracks, and SIGINT correlation

The maritime surface picture layers cooperative vessel tracks from AIS — which broadcasts vessel MMSI, position, course, speed, and vessel type — with tactical radar tracks for non-cooperative contacts and SIGINT-derived tracks for vessels deliberately not broadcasting. AIS provides high-confidence identification for commercial and cooperative naval vessels but is trivially spoofed and routinely absent for vessels attempting to conceal their position or identity.

Cross-domain correlation in the maritime layer: a vessel track in the surface picture that correlates with a space-based RF emitter (identified by SIGINT as transmitting on a known adversary tactical frequency) becomes a candidate intelligence target regardless of whether AIS confirms its identity. The MDO dashboard must present this correlation — surface track plus SIGINT association — as a single entity with attributes drawn from both sources, not as two unrelated entries in separate domain lists.

Air picture: ADS-B, radar, and non-cooperative tracks

The air domain picture is the most demanding in terms of update rate and positional accuracy requirements. ADS-B provides 1-second updates for equipped aircraft, but military operations routinely involve non-cooperative aircraft — adversary aircraft, friendly aircraft operating with emissions control (EMCON) procedures, or UAVs without transponders — that appear only on radar or SIGINT-derived tracks. The MDO dashboard must handle seamless coexistence of high-update ADS-B tracks and lower-update radar tracks without the radar tracks appearing as stale duplicates of their ADS-B equivalents for the same aircraft.

Air domain integration with other domains: aircraft conducting close air support missions have direct dependencies on land unit forward air controller (FAC) communications, air traffic deconfliction data shared with maritime units in littoral zones, and space-based GPS availability for precision navigation. When any of these dependencies are degraded — a land FAC's communications net is jammed, GPS is spoofed in the operational area — the MDO dashboard must flag the affected aircraft operations immediately, not wait for a separate deconfliction workflow to discover the conflict.

Space picture: orbital tracks and communications status

The space domain layer contributes two primary information types to the MDO picture: orbital track data for satellites relevant to the operation (surveillance, communications, navigation), and real-time status for the communications and data relay services those satellites provide. Orbital tracks support mission planning — knowing when an ISR satellite will be in coverage over the operational area, when GPS satellite geometry will degrade below a usable PDOP threshold — but are not typically consumed by operators second by second the way air tracks are.

Communications satellite status is the more operationally immediate space-domain contribution to the MDO dashboard. When a satellite communications link degrades — whether from atmospheric effects, orbital geometry, or active jamming — the effect on ground and maritime units using that link must be surfaced immediately. The MDO dashboard maintains a dependency map from communications services to force elements and pushes degradation annotations to affected tracks automatically. See the space domain awareness software article for the full architecture of the orbital tracking and threat assessment pipeline that feeds this layer.

Cyber domain: network health and threat indicators

The cyber layer is the domain most frequently treated as an afterthought in MDO dashboards built by teams with traditional kinetic C2 backgrounds. Cyber data arrives as structured alerts from intrusion detection systems, network health metrics from monitoring infrastructure, and vulnerability assessment data from security scanning tools. None of this maps naturally to a geographic track — there is no position for a network intrusion event.

The MDO dashboard bridges this gap through the dependency model: a maintained graph that maps network segments, data links, and services to the physical force elements that depend on them. A cyber event that affects a network segment is automatically translated, via the dependency model, into a set of force element tracks that are degraded in some operationally relevant capability. The translation logic must be specific: not "unit X's network is affected" but "unit X's command net is down, fire mission coordination capacity is reduced, and ISR feed from sector 4 is interrupted." This specificity requires the dependency model to be rich enough to distinguish between different communication channels and services, not just binary connectivity.

Data ingestion architecture: the multi-source adapter pattern

A robust MDO ingestion architecture isolates domain-specific parsing from the fusion pipeline using a per-source adapter pattern. Each adapter handles exactly one source in its native format — CoT parser, AIS NMEA decoder, ADS-B Beast format receiver, orbital TLE feed client, SIEM webhook consumer — and publishes normalized track updates to an internal message bus. Adapters are stateless: they transform incoming messages to the common track schema and publish them, with no correlation or fusion logic at this layer.

The common track schema is the critical contract. Every track carries: a globally unique identifier, the source domain and source system, a creation and last-update timestamp (UTC to millisecond precision), a position representation appropriate to the domain (WGS84 for surface and air, orbital elements for space, network node identifier for cyber), a MIL-STD-2525 identity and affiliation, a confidence level, and a freeform attribute bag for domain-specific fields. The schema must be versioned explicitly: as sensor sources evolve and new attribute types are required, the schema must accommodate extension without breaking existing consumers.

The message bus decouples adapters from the fusion engine and from the display layer. A high-update ADS-B adapter publishing at 1 Hz for 500 air tracks cannot be allowed to starve CPU resources from the cyber event consumer processing lower-frequency but operationally urgent intrusion alerts. The message bus enforces fair consumption policies and enables the fusion engine to be scaled horizontally when track volumes exceed single-node capacity.

Fusion challenges: track correlation across domains

Cross-domain track correlation — determining that a maritime surface track, a SIGINT emitter track, and a space-based RF detection all represent the same vessel — is the core technical challenge of MDO fusion. Single-domain correlation (matching two radar tracks of the same aircraft) is well-understood; cross-domain correlation involves sources with fundamentally different measurement types, accuracy characteristics, and update rates.

The correlation engine applies a two-stage pipeline. In the first stage, a spatial index (geohash grid or R-tree) identifies candidate pairs: tracks from different sources that are within a domain-appropriate proximity threshold (tighter for air tracks with known high positional accuracy, wider for SIGINT-derived tracks whose position estimate carries large uncertainty). In the second stage, candidate pairs are evaluated for kinematic consistency (do velocity vectors agree within uncertainty bounds?), temporal consistency (are the timestamps compatible given the entity's reported speed?), and attribute matching (do identifier fields such as MMSI, tail number, or emitter fingerprint agree?). A correlation score is computed; pairs above a threshold are automatically merged into a composite fused track, while near-threshold pairs are surfaced to operators for manual resolution.

Time synchronization is an underestimated fusion challenge. A land CoT message carries the time the originating device generated the position fix — which may be seconds behind the time the message arrives at the dashboard after traversing tactical communications links with variable latency. An ADS-B track carries the aircraft's GPS timestamp, which is highly accurate but may be processed with ingestion delay. The fusion engine must use the observation time, not the ingestion time, when comparing tracks — and must propagate each track's position forward to a common reference time before computing separation for correlation.

Conflicting reports are another operational reality. Two SIGINT sources may report different positions for the same emitter due to direction-finding triangulation geometry. Two land units may report different positions for the same hostile vehicle observed from different angles with different sensor accuracies. The MDO dashboard must represent this uncertainty explicitly — displaying the fused position with a positional uncertainty ellipse, or flagging the conflict for analyst resolution — rather than silently choosing one report over the other in a way that could mislead decision-makers.

Cross-domain effect visualization

The most distinctive capability of a genuine MDO dashboard — and the one most difficult to implement correctly — is the visualization of causal relationships between cyber events and physical force elements. When a red team intrudes into the communications infrastructure supporting a brigade's forward units, the MDO dashboard should not require an operator to mentally connect a cyber alert on one screen to the affected units on another screen. The connection must be drawn explicitly in the interface.

The visualization approach depends on the display context. On the main tactical map, affected force element symbols receive a degradation overlay: a standardized icon or color modification that indicates the category of degradation (communications, sensor feed, data link, navigation). The icon is accompanied by a tooltip or side panel that describes the specific effect in operational terms: "Brigade command net: comms degraded — satellite relay link interrupted." The overlay is temporary and clears automatically when the cyber threat indicator resolves or the dependency model indicates the capability has been restored through an alternate path.

For deeper analysis, a graph view renders the full causal chain: the cyber event node (intrusion alert, jamming indicator, network outage) connects via directed edges to the affected infrastructure nodes, which connect to the dependent force elements. Edge labels indicate the nature of the dependency and the severity of the degradation. This graph is not the primary display — it is accessible from the main map on demand — but it allows operations staff to trace the precise pathway of an effect and to assess which mitigation options (switching to alternate communications, re-routing the data link, degraded-mode operation) are available.

For an example of how the C2 dashboard architecture implements layered visualization that supports this kind of multi-domain overlay pattern, the layered rendering model described there applies directly to the MDO context — each domain track set occupies a named layer with independent toggle, filter, and styling controls.

MDO commander information needs and refresh rates

Designing for the commander's information needs — rather than for the data engineer's natural instinct to display everything — is what separates an operationally useful MDO dashboard from a technically impressive data visualization. The commander's decisions in an MDO environment fall into three broad categories, each with distinct information needs and latency requirements.

Synchronization decisions — timing and coordinating effects across domains to achieve convergence on a single objective — require the commander to see the current state of multiple domain lines of effort simultaneously and assess whether they are converging as planned. The relevant information is: are all domain elements on track against the synchronization matrix? Are there effects in one domain that are ahead of, or behind, the schedule that other domains depend on? This picture needs to be current to the minute, not the second, and is best presented as a synchronized timeline overlay rather than a raw track picture.

Exploitation decisions — acting on a fleeting opportunity created by a cross-domain effect — require much lower latency. When a cyber effect degrades an adversary air defense radar network, the window for air domain exploitation may be measured in minutes before the adversary switches to backup systems or manual procedures. The MDO dashboard must surface this opportunity immediately, with a clear indication of the affected sensor coverage and the estimated time the degradation will persist. This is the decision that requires sub-minute dashboard update cycles.

Risk mitigation decisions — protecting friendly forces from cross-domain vulnerabilities — require understanding which friendly elements are exposed to degradation from adversary action in other domains. Which units are GPS-dependent in an area where the adversary has demonstrated GPS jamming capability? Which communications paths run through satellite links that are within range of adversary directed energy systems? The MDO dashboard must maintain this risk picture continuously and flag new exposures as the operational situation evolves.

Corvus.Head: MDO-capable cross-domain track fusion

Building a functional MDO dashboard requires solving the full stack simultaneously: per-domain ingestion adapters, a domain-agnostic track schema, a cross-domain correlation engine, a dependency model for cyber effects, and a layered visualization that makes causal relationships visible to operators under time pressure. These components are not separable — a system with excellent air track display and no cyber dependency model is not an MDO dashboard, regardless of how it is marketed.