Building a C2 System from Scratch, Part 1: Foundations and Architecture

The literature on command and control is heavy on procurement, doctrine, and acronyms; it is light on the question that an engineer actually wants answered: how do I build one? This four-part series walks through the construction of a defense C2 system from a blank repository to operational deployment. Part 1 establishes the foundations — scope, architecture, schemas, and tech stack. Parts 2 through 4 work through fusion, display, and the interop-and-security work that gets the platform out the door.

The series complements the architectural Complete Guide to Command and Control (C2) Systems, which surveys the whole field. The series goes narrower and deeper: a single example platform, with decisions made, trade-offs explained, and the engineering reasoning surfaced. The example is generic enough to apply across echelons; the principles transfer.

Step 1: Pick a Scope and Commit to It

The first decision is the one most often skipped, and it is the one that determines whether the platform reaches operations. A C2 system designed to serve every echelon — tactical, operational, strategic — usually serves none of them well. Pick one.

The defining questions:

Echelon. Brigade and below means latency budgets in seconds, a flat data model, and a UI for stressed operators with gloves on a sunlit tablet. Division through corps means longer latencies, richer planning tools, and staff officers at workstations. Joint and national means hierarchical models, compartmented intelligence, and a desktop-class analyst experience. The full treatment of how echelon shapes architecture is in What Is a C2 System?.

Domain. Land, maritime, air, or joint-domain. Each has different sensor families, message standards, and operator workflows. A multi-domain platform is a heavier engineering lift than a single-domain one and is rarely justified for a first build.

Coalition vs national. Coalition deployment means NATO interoperability is a procurement gate from day one. National-only allows a sovereign data model with NATO bridging built later. The interop-side trade-offs are in The Complete Guide to NATO Interoperability.

Classification ceiling. The highest classification the platform will handle determines accreditation effort, network topology, and tooling choices. A NATO RESTRICTED platform is roughly an order of magnitude easier to build than a NATO SECRET one.

Write the scope decisions down. Tag every architectural ticket with which scope decision it serves. Scope creep — the gradual addition of echelons, domains, or classifications during development — is the single largest cause of programme failure.

For the running example in this series, we choose: brigade-level tactical C2, multi-domain (land + air situational awareness), NATO-interoperable, classification ceiling NATO SECRET. Different choices would shift specific decisions throughout the series but not the overall architecture.

Step 2: Settle on the Four-Layer Architecture

Every operational C2 platform converges on the same four-layer architecture. Sensor, processing, display, communications. The naming varies; the responsibilities do not. The architectural rule is simple: each layer has a single responsibility, the interfaces between layers are explicit, and no concept leaks across layer boundaries.

Sensor layer. Adapters that translate sensor-native formats (ASTERIX, STANAG 4586, CoT, AIS NMEA, ADS-B) into the platform's internal canonical track. Adapters are one-way data converters; they never make decisions about tracks.

Processing layer. Track fusion, normalization, the authoritative track store. The track is the unit of data the rest of the platform operates on. This layer is the topic of Part 2.

Display layer. The Common Operational Picture and its surrounding tooling. Tasking, messaging, planning. Web-based frontend consuming WebSocket and REST APIs from the processing layer. The topic of Part 3.

Communications layer. Message buses, store-and-forward replication, cross-enclave bridges, tactical-radio integration. The topic of Part 4 alongside interop and security.

Lay this out as actual repos and services from day one. Resist the temptation to "start with one service and extract later" — the extraction never happens cleanly, and the layer boundaries blur in ways that cost a year of work to repair.

Step 3: Design the Canonical Track Schema

The track is the central data structure of any C2 platform. Every adapter produces tracks. Every fusion decision updates tracks. Every COP renders tracks. Every audit log references tracks. Get the schema right and most of the rest of the platform is straightforward; get it wrong and the cost compounds across years.

The minimum viable track schema includes:

• Track ID. Stable, globally unique, never reused. UUIDv7 or a typed prefix-plus-UUID is a safe default.
• Identity. What the track is. Type taxonomy (vessel, aircraft, vehicle, person, unit) plus subtype and tail-number / hull-number / callsign where known. Identity is fused over time; do not bake it into the ID.
• Position. Latitude, longitude, altitude. Coordinate system explicit (WGS84 is the safe default). Uncertainty ellipse — not a single number; covariance matrix or major/minor axis with bearing.
• Kinematic state. Velocity (vector), turn rate, derived course/speed. Time-tagged.
• Source set. Which adapters contributed to this track. Source classification, releasability, confidence.
• Timestamps. Three distinct times: observation time (when the sensor saw it), report time (when the message left the sensor), ingest time (when the platform received it). Conflating these is a common bug source.
• Lifecycle state. Tentative, confirmed, mature, fading, lost. Driven by the fusion engine; visible to the COP.
• Classification envelope. Effective classification computed from source set. Releasability tags. Compartment markings if applicable.
• Confidence and certainty. Track-level confidence; per-attribute certainty where it matters (e.g. position has high certainty but identity is tentative).

Version the schema additively. New fields are optional; existing fields never change meaning. Breaking changes are accepted only across major platform releases with a documented migration. The detailed treatment, including identity normalization patterns and schema-evolution strategies, is in Defense Data Integration Challenges.

Step 4: Pick the Tech Stack

The tech stack for a defense C2 platform must balance four constraints: operational survivability (20-year lifecycle), accreditation friendliness (national approval lists), the team's existing skills, and the engineering ergonomics that determine sprint velocity. The choices below are one defensible set, not the only one.

Backend services: a typed language with a mature concurrency story. Go and Rust are the two strong choices for new programmes; Java remains a defensible incumbent. Avoid niche languages with single maintainers — the platform will outlast the language community.

Message bus: Kafka or NATS JetStream as the durable event log; the choice between them is in Message Queues for Defense Data Pipelines. For small deployments NATS is lighter; for large deployments Kafka is operationally proven.

Geospatial database: PostGIS on PostgreSQL is the default. Mature, accreditation-friendly, scales to billions of points with proper indexing. The engineering details are in PostGIS for Defense Geospatial Data.

Time-series database: TimescaleDB extending PostGIS, or InfluxDB as a separate store. Sensor histories and telemetry belong here, not in the operational track store.

Frontend stack: React or Vue, typed (TypeScript). Cesium for 3D and globe views; Mapbox GL or MapLibre for 2D. Detailed map-rendering trade-offs in Real-Time Map Rendering for Military C2.

Real-time transport: WebSocket for browser, MQTT for tactical edge, gRPC for service-to-service inside the data centre. Each has a clear fit and they coexist.

Authentication and authorization: OpenID Connect for human users (with national-PKI integration where required), service-to-service mTLS with short-lived certificates. RBAC and classification layered through a dedicated policy engine — Open Policy Agent is a defensible choice. The detailed pattern is in Role-Based Access Control in Defense C2 Systems.

Deployment: Containers (OCI), orchestrated by Kubernetes in cloud or large on-prem; systemd or k3s for tactical-edge nodes. The same artefacts run across the spectrum; the orchestration changes.

Resist over-engineering. A first build does not need a service mesh, a multi-cloud abstraction, or a hand-rolled framework. The boring choices — well-supported, widely deployed, with mature accreditation evidence — are the right choices for defense.

Step 5: Set Up the Repository Structure

Decide early on monorepo vs multi-repo. For a new platform with a single team, a monorepo is usually correct: shared libraries (schema, RBAC client, telemetry) live alongside services, changes flow atomically, and the build system enforces consistency. Multi-repo becomes attractive only when team boundaries diverge.

A defensible top-level structure:

• schemas/ — canonical track schema, message schemas, API contracts. Code-generated bindings for each consumer language.
• adapters/ — sensor adapters, one per source type.
• services/ — fusion engine, track store, policy engine, audit service.
• frontend/ — the COP and supporting UI.
• tools/ — operational tools, test harnesses, simulators.
• deploy/ — Kubernetes manifests, Helm charts, Ansible playbooks for tactical-edge nodes.
• docs/ — architecture decisions (ADRs), runbooks, accreditation evidence.

Treat the documentation directory as code: reviewed, versioned, mandatory. ADRs (Architecture Decision Records) save the platform from re-litigating the same trade-offs every six months when a new engineer joins.

What's Next

Part 1 has framed the platform. Scope chosen, four-layer architecture committed, canonical track schema designed, tech stack picked, repo structured. The skeleton exists; nothing yet ingests a sensor or renders a track.

Part 2: The Fusion Engine takes the schema and builds the layer that ingests sensor reports, correlates them into tracks, and exposes them to the rest of the platform. It is the engineering heart of the C2 system, and it is where the architectural decisions of Part 1 get tested against reality.

Before continuing to Part 2, settle the scope decisions and write down the canonical track schema. The series assumes both are in hand.