A Common Operational Picture (COP) is a shared, real-time display of the operational environment that gives commanders and operators a unified view of friendly, neutral, and threat entities across all relevant domains. The term is used across military doctrine, homeland security, emergency management, and critical infrastructure protection - but the quality of what passes for a "COP" varies enormously. At one end, a COP is a decision surface backed by real-time sensor fusion, automated policy enforcement, and multi-domain correlation. At the other, it is a map with manually plotted icons that was accurate when someone last updated it.
If you've in the US Army in the last decade or so, you probably have seen or heard of the Command Post of the Future (CPOF), that was one of many attempted COPs out there. The joke we had was to call it the CPORN - the Command Post of Right Now - and even then, that was being generous.
For quick-reference answers on COP concepts, see the COP FAQ. For how the fusion layer underneath the COP works, see What is Sensor Fusion?.
The problem with most COPs
Most operational pictures are not common and not operational. They are echelon-specific views of stale data, manually curated, pushed on a schedule, and rendered on a map that looks impressive in a briefing but tells the operator at the edge almost nothing they can act on in real time.
The root cause is architectural. If the COP is assembled at a command post or in the cloud from data that has to traverse multiple networks, classification boundaries, and processing queues, the picture is always behind reality. The operator sees where things were, not where they are. In a counter-UAS engagement where a threat closes at 30+ meters per second, "where it was" and "where it is" can diverge by hundreds of meters in the time it takes a cloud-hosted COP to round-trip a detection through ingest, processing, and rendering. That is the difference between an actionable track and an after-action artifact.
In contested environments where communications degrade - which is precisely when the COP matters most - the problem is worse. A cloud-dependent COP does not degrade gracefully; it goes blank. The operator is left with the individual sensor displays they had before the COP existed, correlating mentally across separate screens, which is exactly the problem the COP was supposed to solve.
This is not a theoretical failure mode. Russian EW capability demonstrated in Ukraine - Krasukha-4, Murmansk-BN, Zhitel - can degrade theater-scale SATCOM, GPS, and tactical data links simultaneously. Chinese A2/AD doctrine explicitly targets communications infrastructure. Even in permissive CONUS environments, a network outage at the wrong moment turns a cloud-hosted COP into an expensive blank screen in a security operations center. A COP that depends on connectivity is not a COP. It is a briefing tool that happens to update automatically when conditions are favorable.
What separates a COP from a tactical display
The terms "COP," "tactical display," "Common Tactical Picture (CTP)," and "situational awareness dashboard" are used interchangeably in marketing and procurement documents. They are not the same thing, and the differences are load-bearing.
A tactical display renders sensor data - often from a single sensor or a single sensor type - with minimal processing. A radar scope is a tactical display. A camera feed with bounding boxes is a tactical display. These are useful and necessary, but they are inputs to an operational picture, not the picture itself.
A Common Tactical Picture (CTP) is a tactical-level subset of the COP focused on the immediate battlespace. It typically covers a single domain or a narrow geographic area and is consumed by the tactical commander. In naval doctrine, the CTP is the shared picture of the air, surface, and subsurface tactical environment. The CTP feeds up into the COP, but a CTP alone does not provide the cross-domain, cross-echelon, and cross-functional integration that the COP requires.
A situational awareness dashboard is a visualization layer - often web-based - that aggregates data from multiple sources and presents it in charts, maps, and widgets. Dashboards are useful for monitoring and briefing. They are not decision surfaces. They do not fuse tracks, resolve identity, score confidence, enforce policy, or support engagement workflows. Putting four sensor feeds on one screen is a dashboard, not a COP. The operator is still mentally correlating the radar blip at 323 degrees and 712 meters with the RF detection bearing northeast with the EO/IR track on a different panel. That mental correlation works in a clean environment with two objects. It collapses the moment a real incursion happens and the operator is drinking from fifteen firehoses while the threat closes at 500 meters.
A COP - in the doctrinal sense from JP 3-0 and in the operational sense that actually matters - is a fused, correlated, assessed, multi-domain picture that enables decision. The difference is the fusion layer underneath. Without sensor fusion, you have a map with icons. With it, you have correlated tracks carrying identity provenance, confidence scoring, and behavioral assessment that an operator can act on.
What a real COP requires
A functional COP is built on four things, and skipping any one of them produces something that looks like a COP in a demo but falls apart under operational stress.
Fused tracks, not raw feeds
The COP consumes output from a sensor fusion engine that correlates detections from heterogeneous sensors - radar, RF, EO/IR, acoustic, cooperative broadcasts (ADS-B, AIS, Remote ID), space-based sensors, HUMINT/OSINT - into unified tracks. Each track carries a position (with uncertainty), velocity (with uncertainty), classification (what type of entity it is), identity (who or what it specifically is), affiliation (friendly, hostile, neutral, unknown), and provenance (which sensors contributed, when, and with what confidence). The fused track is more than any individual sensor report because it inherits the strengths of every sensor that observed the entity while averaging out their individual weaknesses.
This is where the quality of the fusion engine determines the quality of the COP. Greedy nearest-neighbor association - matching detections to the closest existing track - produces good results in sparse environments and catastrophic misassociations in dense ones. A fusion engine using multi-hypothesis tracking with optimal global assignment maintains association quality whether there are 2 tracks or 200, because it considers the globally best assignment of all detections to all tracks simultaneously rather than greedily matching each detection independently. The 25th detection in a dense scene gets the same association quality as the first. This is not an academic distinction - it is the difference between the COP showing you what is actually happening and the COP confidently showing you something wrong.
That said, not everything has a kinematic state. Electronic Order of Battle (EOOB), geocoded referential information domain intelligence products, geolocated Imagery Intelligence (IMINT), and power-density EMSO sweeps don't have a kinematic state. These should still be placed as information-dense overlays that are toggleable and interactive. This extends to more commercial-facing overlays as well such as Notice to Airmen (NOTAMs), Notice to Mariners, TFRs, airspace zones, forest fire overlays from NASA FIRMs, and more.
Data normalization
Before a single track can be fused, the raw sensor data has to be normalized into a common frame. Every sensor reports in its own coordinate system (WGS84 geodetic, MGRS, local Cartesian, sensor-relative polar), at its own update rate (milliseconds for radar, seconds for EO/IR, minutes for cooperative broadcasts, hours for HUMINT), with its own uncertainty expression (covariance matrix, Circular Error Probable, or nothing at all), across its own transport protocol (serial, gRPC, MQTT, vendor SDKs, CoT over TCP/UDP, ASTERIX CAT-062 over UDP, Link 16 J-series messages, NATS, and custom REST/WebSocket APIs from every vendor who decided their format was better than everyone else's).
This normalization layer is invisible to the operator and unglamorous in a demo, but it is where most "integrated" COP solutions quietly break. A radar reporting in local Cartesian with a 2Hz update rate and a covariance matrix does not trivially correlate with a Remote ID broadcast in WGS84 with a 1Hz update rate and no uncertainty expression whatsoever. Bridging that gap - timestamp alignment, coordinate transformation, uncertainty imputation, metadata preservation - is the plumbing that makes fusion possible. Cursor on Target (CoT) and Link 16 J-messages both carry lossiness that drops meaningful identity context into unstructured fields or off the table entirely. A COP that cannot handle the messiness of real-world sensor data in its native formats is a COP that only works in the lab.
Local compute at the edge
Fusion and rendering must run at the edge, on hardware that deploys with the unit. This is not a nice-to-have; it is the architectural decision that determines whether the COP survives first contact with a contested environment. When connectivity exists, the local picture propagates up to higher echelons and accepts fused tracks from adjacent units and national-level feeds, enriching the picture. When connectivity degrades - whether from adversary EW, network failure, or operating in a tunnel, a ship's interior, or a remote site - the unit retains a fully functional operational picture built from every sensor it can reach locally.
The alternative - cloud-hosted fusion with edge rendering - works in exactly one scenario: permissive connectivity. The moment the link degrades, the COP degrades with it. The operator does not get a "slightly worse" picture; they get tracks freezing, then disappearing, then the entire picture going stale. Edge compute eliminates this single point of failure. See Why JADC2 Needs Sensor Fusion at the Edge for the detailed architectural argument.
Decision support, not just display
A COP that only shows you where things are is a map. A COP that shows you what things are, what they are likely to do, what your options are, and what authorities you have to act - that is a decision surface. The gap between "display" and "decision surface" is where most COP implementations stop short.
Policy automation encodes rules of engagement, engagement authorities, escalation criteria, and response procedures into machine-executable policy that the COP enforces automatically. When a fused track crosses a geofence with a specific classification and threat assessment, the COP does not just highlight it - it presents the authorized courses of action for that operator's authority level, logs the decision, and maintains a full audit trail. In a counter-UAS engagement where the decision timeline is measured in seconds, the difference between "the operator sees a dot and figures out what to do" and "the operator sees a classified threat with recommended actions gated by their authority" is the difference between timely response and a postmortem.
Symbology and track representation
How tracks are rendered on the COP matters operationally. MIL-STD-2525 (current revision 2525D, with 2525C still widely fielded) is the DoD standard for military symbology. It defines Symbol Identification Codes (SIDCs) that encode affiliation (friendly, hostile, neutral, unknown, assumed friend, suspect, pending), dimension (air, ground, surface, subsurface, space, SOF), status (present, anticipated, planned), and function (infantry, armor, UAS, air defense, EW, and hundreds more) into standardized icons.
In most COP implementations, symbology is manually assigned - an operator tags a track as hostile air, and the correct 2525 icon appears. In a fused COP, symbology can be dynamically generated from resolved track attributes. When the fusion engine resolves a track's identity, classification, affiliation, and domain, the corresponding SIDC is computed automatically. If the identity resolution changes - a track previously classified as unknown air is reclassified as hostile UAS based on new sensor data - the symbol updates without operator intervention. This is not cosmetic; in a dense environment with dozens of tracks, manually maintaining symbol accuracy is a task that competes directly with the operator's ability to make decisions.
Track detail - the information available when an operator selects a specific track - is equally important. A track icon on the map tells you where something is and what affiliation the system has assigned. The track detail panel should expose the full provenance chain: which sensors contributed to this track, when each sensor last reported, what the individual sensor classifications were, what the fusion engine's confidence is, what the trust assessment is, and what the track's kinematic history shows. This lets the operator interrogate the machine's reasoning rather than trusting a colored icon on faith.
Multi-domain COP
The "common" in COP means shared across echelons and domains. A single-domain picture - air-only, ground-only, maritime-only - is useful but incomplete. Cross-domain correlation produces understanding that no single-domain view can provide: an RF emitter correlated with a radar track correlated with an EO/IR visual is a classified, identified, multi-phenomenology track. The same RF emitter, radar track, and EO/IR detection shown as three separate icons on three separate displays is three ambiguous contacts that an operator has to mentally stitch together under pressure.
A multi-domain COP integrates air tracks (radar, ADS-B, Remote ID, EO/IR), ground tracks (ground-moving target indication, force tracking, access control), maritime tracks (AIS, radar, sonar, EO/IR), space tracks (TLE-propagated satellite positions, pass windows, ground tracks from SSA), electromagnetic tracks (emitter locations, signal characterization, spectrum occupancy from EMSO), and narrative/information tracks (social media detections, influence operation indicators from narrative intelligence) into a single operational picture.
This is not accomplished by putting six domain-specific windows on one monitor. It is accomplished by a fusion engine and data model that represent entities across domains with consistent identity and provenance, so that a ship emitting on a characterized frequency while being tracked by coastal radar and broadcasting AIS appears as one entity with three contributing sensor phenomenologies - not three disconnected contacts that happen to be near each other on the map.
COP in force protection and critical infrastructure
The COP concept is not exclusively military. In force protection, the COP integrates perimeter sensors (radar, cameras, ground sensors), counter-UAS detections, access control systems, and threat intelligence into a single picture for the security operations center. A fused force protection COP lets operators see correlated threats - an RF detection coinciding with a radar track coinciding with a visual on a camera feed - rather than checking separate sensor displays independently and hoping someone notices the correlation before the threat reaches the perimeter.
For critical infrastructure - airports, ports, energy production facilities, data centers, water treatment plants - the COP provides the operational picture that ties physical security sensors to the threat environment. An airport COP integrating ADS-B, Remote ID, perimeter radar, and weather data gives the operations center a unified view of authorized and unauthorized air activity that no single sensor system can provide alone. This is where the counter-UAS kill chain and the operational picture converge: the COP is the surface where detection becomes classification becomes decision becomes action.
In emergency management and homeland security, the COP aggregates feeds from multiple agencies, sensor types, and information sources into a shared picture that enables coordinated response. The challenge is interoperability - every agency has its own systems, formats, and networks. A COP that can ingest CoT, CAP (Common Alerting Protocol), NIMS/ICS data, and commercial sensor feeds alongside military-standard formats is a COP that works across the interagency boundaries where coordination usually breaks down.
Where Empyrean fits
Empyrean's Common Operational Picture is the operator surface for the Decision Dominance Engine. It is not a visualization layer bolted onto separate sensor feeds; it is the rendering of a fused, multi-domain operational picture that runs at the edge.
Fused tracks from the fusion engine render with dynamic MIL-STD-2525C/2525D symbology generated from resolved identity attributes. The track detail panel exposes full sensor provenance, confidence scoring, trust assessment, and kinematic history. Sensor coverage overlays show where the picture is strong and - critically - where it is not, so the absence of detections in a well-covered sector is visibly different from the absence of detections in an uncovered sector. One of those is useful information; the other is dangerous ignorance.
The COP integrates EMSO spectrum data for electromagnetic domain awareness, SSA space tracks for satellite pass windows and overhead ISR threat prediction, and narrative intelligence for information domain awareness. The Policy & Decision Layer enforces rules of engagement, engagement authorities, and escalation criteria locally with a full audit trail - whether the COP is connected to higher or operating standalone. The Wargaming & Simulation Engine runs the same COP with synthetic sensor data, so training transfers directly to operations and operators build familiarity on the same interface they will use under stress.
The whole stack deploys at the edge. Same software on a server in a TOC, a ruggedized laptop in a vehicle, or a rack in a security operations center. Same operator experience whether connected or dark. Connectivity enriches the picture; its absence does not destroy it.
Going deeper
- COP FAQ - quick-reference answers on COP concepts and terminology
- What is Sensor Fusion? - the fusion layer that feeds the COP
- What is Counter-UAS? - where the COP meets the C-UAS kill chain
- What is Space Situational Awareness? - the space domain data that feeds into a multi-domain COP
- What is JADC2? - the command and control concept the COP serves
- Why JADC2 Needs Sensor Fusion at the Edge - the architectural case for edge deployment
- Common Operational Picture - Empyrean's COP capability
