Building a C2 System from Scratch, Part 3: The Common Operational Picture

Parts 1 and 2 produced trustworthy tracks. Part 3 builds the surface the operator actually sees. The Common Operational Picture is the layer the platform is judged on — get it right and forgiveness flows down through the rest of the stack; get it wrong and a technically correct fusion pipeline gets disabled in week two of operations. The architectural patterns are established (see Common Operational Picture: How It's Built in Modern Defense Software); Part 3 turns them into specific engineering decisions.

Step 1: Frontend Stack

For the running example platform, the COP is a browser-based application. The choice between native and web has been settled in favor of web for over a decade; the residual native footprint is in specialized handheld platforms (the ATAK ecosystem — see ATAK Plugin Development) rather than command-post displays.

The defensible stack:

• React with TypeScript for the application shell. The ecosystem maturity, hiring availability, and accreditation-friendly tooling make it the safe choice for a 20-year platform. Vue is defensible; Svelte is not yet a procurement-grade choice for defense.
• Cesium for the globe view and 3D — terrain, airspace volumes, satellite tracks. WebGL-accelerated, mature, the de-facto standard for geospatial 3D in defense.
• Mapbox GL or MapLibre for the 2D map view. Vector tiles for speed; raster tile fallback for offline. The trade-offs and performance ceiling are in Real-Time Map Rendering for Military C2.
• Zustand or Redux Toolkit for state. The volume of streaming track updates makes naive React state untenable; use a store with reference-stable selectors and shallow-equal comparisons.
• Ant Design or Mantine for the surrounding UI — panels, modals, forms. Resist building a bespoke design system in the first build; pick a mature library and theme it to defense conventions.

One non-obvious decision: keep the COP a single-page application, not a multi-page site. Operators do not navigate. They open the COP once and use it for hours. Page reloads are the wrong abstraction; views and panels within a single shell are the right one.

Step 2: Military Symbology, Done Right

Tracks render as symbols. The symbol catalogue is governed by MIL-STD-2525D (or the equivalent NATO APP-6 variant). Hand-rolled symbology is a procurement red flag and an interoperability blocker: the moment the platform integrates with an allied system, mismatched symbols trigger an immediate compliance failure.

Use a maintained library. The open-source milsymbol implementation is the de-facto choice for web-based COPs; it produces the standard symbol set as SVG or canvas drawables. The library handles affiliation (friend, hostile, neutral, unknown), echelon markers, identifying text, and the modifiers that turn a generic infantry symbol into "1st Battalion, mechanized, in defensive posture".

The integration pattern: the fusion engine emits tracks with identity attributes; the COP looks up the appropriate MIL-STD-2525 SIDC (Symbol Identification Code) for those attributes; the library renders the symbol. Cache rendered symbols by SIDC; the same symbol is reused thousands of times across a typical operational picture.

A practical detail worth flagging: MIL-STD-2525D has thousands of distinct symbols. Almost none operationally relevant scenarios use more than a few hundred. Build the catalogue from the inside out — start with what the platform's sensors produce, expand as new sensor classes arrive.

Step 3: Real-Time Updates Over WebSocket

The COP's job is to reflect the track store in near-real-time. Polling does not scale; WebSocket is the structural answer. The architectural pattern:

A gateway service holds open WebSocket connections to each browser. It subscribes to the fusion engine's tracks.updates and tracks.lifecycle topics. When a track update arrives, the gateway evaluates the per-connection filter (which area, which roles, which classifications) and pushes the update to the browser. The browser applies the update to its local state store; React re-renders only the affected symbols.

The non-obvious engineering details that determine whether this works at scale:

Filtering happens server-side. Pushing every track to every browser does not work — at 10,000 tracks updating multiple times per minute, the wire and the browser both choke. Each connection has a subscription filter (viewport bounds, role-based layers, classification filter) and only matching updates flow.

Delta updates, not full replacements. A track update is a partial — position changed, lifecycle state changed, identity refined. The browser applies the patch to its local copy. Full-track payloads are sent only on initial subscription and on schema migrations.

Reconnection with state recovery. WebSocket connections drop, especially on tactical networks. On reconnect, the browser exchanges its last-seen sequence number with the gateway, which replays missed updates from the bus. No state loss, no full refetch.

Backpressure handling. A slow client must not stall the gateway. Queue depth per client is bounded; when the queue overflows, the client is dropped and forced to reconnect with a full state fetch. Better one operator who reconnects than all operators frozen.

Step 4: Role-Based Filtering and Classification

Not every operator sees every track. An infantry platoon leader's COP does not show air-defense engagement zones. A NATO-RESTRICTED account does not see SECRET-classified tracks. The platform enforces this in two places: the gateway filter (what to send) and the policy engine (whether to send at all).

The role filter is a per-user, per-session configuration: which track types, which areas of operations, which display layers. The user can adjust within their authorization; the system enforces the upper bound. The classification filter is non-negotiable: a track's effective classification (computed in fusion, propagated to the gateway) must be at or below the user's clearance. Cross-checks at the API and database layers — never only at the UI — are the rule. The detailed pattern is in Role-Based Access Control in Defense C2 Systems.

An operational note: build the role configuration UI together with the operator community, not in isolation. Defaults matter. An infantry user does not want to start every session disabling six layers of irrelevant air-defense data. A wing operator does not want to start every session enabling the air-defense layers their predecessor disabled. Role-based defaults that match the operator's actual job halve the operator-frustration baseline.

Step 5: Operator Ergonomics

A COP that fails ergonomically fails operationally. The discipline is built up from a handful of non-negotiable rules.

Stale-track indication. When a track's lifecycle state is fading or lost, the symbol changes — typically dimmer, possibly outlined, with an age indicator. Operators must see at a glance which tracks they can trust.

Conflict resolution UI. When two operators edit the same track or task simultaneously, the platform must surface the conflict, not silently overwrite one side. Last-writer-wins on a per-attribute basis is the default; explicit reconciliation for high-stakes attributes.

Keyboard-first design. Mouse-only UIs fail in stressed operations. Every common action has a keyboard shortcut; the shortcuts are documented in-product and discoverable.

Touch-and-glove operation for ruggedized targets. The same COP runs in command posts on workstations and on ruggedized tablets at brigade-forward positions. Hit targets are sized for gloves; high-contrast modes are first-class. The broader pattern is in Ruggedized UX for Military Operators.

Offline operation. Tactical-edge deployments lose connectivity. The COP must function on its local cache, replay queued operator actions on reconnection, and indicate clearly which data is stale. The architectural pattern is in Offline-First Military Apps; the offline-map side in Offline Maps with MBTiles and PMTiles.

Step 6: Beyond the Map — Dashboards and Panels

The COP is more than a map. Operators need tasking interfaces, message composition, planning tools, intelligence panels, log views. The platform-wide UX rule: every panel obeys the same interaction conventions. If selecting a track in the map highlights it in a side panel, then selecting a track in any panel highlights it in the map. Inconsistency in this layer is the most common UX failure in defense software.

The architectural separation worth maintaining: the map view is one panel; the dashboards and side panels are other panels; they share the same selection state through the central store. Adding a new analyst tool is a new panel, not a new application. The dashboard-architecture patterns are in C2 Dashboard Architecture.

Step 7: Performance Targets

The COP's targets are tighter than they sound:

• Initial load under 3 seconds on a tactical-edge laptop with cached static assets.
• Track update latency under 200 ms from gateway emit to symbol visibly moved on the browser.
• Sustained 60 FPS map rendering with up to 10,000 visible tracks.
• Pan-and-zoom responsive at typical tactical map scales (1:50,000 to 1:1,000,000).
• Memory bounded — the browser must run all day without leaking. Profile every release.

The targets are achievable with the stack chosen; missing them is usually the result of an architectural shortcut earlier in the pipeline (server-side filtering not implemented, full payloads instead of deltas, naive state management).

What's Next

Part 3 has built the COP. Tracks render with correct symbology; updates stream over WebSocket; operators see only what they're authorized for; the ergonomics support real operations. The platform is now usable by an operator — but not yet shippable.

Part 4 closes the loop: NATO interoperability bridges (CoT, MIP4, STANAG 4559), classification labelling and releasability enforcement, the DevSecOps pipeline that produces accreditation evidence, and air-gapped deployment for tactical-edge use. After Part 4, the platform is operationally deployable.