Ukraine did not build one situational awareness system. It built a dozen, in parallel, under fire, and then spent three years wiring them together. The result is not a tidy architecture diagram — it is an ecosystem of cloud platforms, tablet apps, artillery calculators and drone-video pipelines, each optimized for a different layer of the kill chain, loosely federated by a handful of bridges and data formats. For Western engineers used to single-prime, decade-long C2 programs, the interesting question is not whether this ecosystem is elegant. It is not. The interesting question is why it works, and what survives translation to an alliance context.
1. the stack at a glance — many tools, one goal: shorten the sensor-to-shooter loop
Every component in the Ukrainian SA stack exists to compress the time between a sensor seeing a target and a weapon affecting it. That is the organizing principle, and it explains the apparent fragmentation. Delta provides the theater-level common operating picture. Kropyva runs the reconnaissance-and-fires workflow on a battalion tablet. The GIS Arta family coordinates distributed artillery. Drone ground-control stations feed live video and coordinates upward. The Brave1 cluster is the procurement and integration engine that keeps spinning out new tools.
None of these started as a grand unified program. They grew from volunteer projects, NGO efforts and small companies, each solving an urgent problem for the unit in front of them. Standardization came later, retroactively, driven by the practical need to make a drone operator's target nomination land in the same picture an artillery commander was already looking at. That ordering — capability first, integration second — is the single most important structural fact about the entire ecosystem.
2. Delta — the cloud situational-awareness layer, the common operating picture, NATO-exercise exposure
Delta is the closest thing Ukraine has to a theater-wide common operating picture. Developed under the Defence Ministry's innovation arm, it is a web-and-mobile platform that aggregates friendly and enemy positions, intelligence reports, sensor feeds and unit status into a single map that scales from a brigade staff to general-staff level. Architecturally it is cloud-native: a browser client, mobile apps, and a back end that ingests reports from humans and machines alike and resolves them into a shared track database.
What makes Delta interesting to an interoperability engineer is its data model. Rather than couple tightly to any one client, Delta exposes the Delta format — a structured representation of entities, sightings and overlays that other systems can read from and write to. This decoupling is what lets a tablet app, a drone station and a staff browser all contribute to the same picture without sharing code. Delta has been exposed to NATO audiences in alliance exercises, where its standards-conformant interfaces let it exchange tracks with coalition systems rather than living in a national silo.
3. Kropyva — the artillery and reconnaissance app, fire-control math, tablet-based workflow
Where Delta is the theater picture, Kropyva is the working surface of a fighting battalion. Built by the volunteer-rooted Army SOS effort, it runs on a ruggedized Android tablet and bundles two jobs that Western armies usually split across separate systems: digital map-based reconnaissance reporting and artillery fire-control computation.
The fire-control side is the part Western engineers underestimate. Kropyva does the ballistic math — range, azimuth, and corrections — turning an observer's grid reference and a known gun position into a firing solution in seconds. An observer marks a target on the map; the app computes the gun-target geometry, applies meteorological and muzzle-velocity corrections, and produces the data the gun crew dials in. The same tablet that drew the reconnaissance overlay produces the fire mission, collapsing a workflow that elsewhere involves a forward observer, a fire-direction center and several radio relays into one device and one operator.
That integration is deliberate. By keeping reconnaissance and fires in one app on one tablet, Kropyva removes the handoffs where time and accuracy leak away. Its tracks and target nominations can be pushed up into the broader picture, so a local fire mission also becomes a contribution to theater awareness.
Key insight: The Ukrainian stack's advantage is not any single app — it is that the artillery calculator, the drone feed and the staff map all write into a shared entity model instead of into each other. The data model is the integration point, not the application. Every app is replaceable; the picture is not.
4. the GIS Arta lineage — distributed fires coordination, the "Uber for artillery" pattern
GIS Arta is the system that gave the ecosystem its signature pattern. Conceived before the full-scale invasion, it tackled a hard distributed-systems problem: given many sensors generating targets and many guns of differing types and readiness, how do you match each target to the best-positioned, best-suited weapon, fast, without a human bottleneck?
The answer became known by analogy as the "Uber for artillery." A target enters the system from any observer — a scout, a drone, a radar. The software evaluates which fire units are in range, available, and appropriate, and routes the mission to the optimal gun, much as a ride-hailing platform matches a rider to the nearest driver. The reported effect of this matching was a dramatic compression of the engagement timeline, from the tens of minutes typical of manual coordination down to a few minutes or less.
The lineage matters because the GIS Arta pattern — treat fires as a distributed dispatch problem, optimize allocation in software, keep humans on approval rather than routing — propagated into how the rest of the ecosystem thinks about target handoff. Later tools inherited the assumption that a target nomination is a structured message to be routed, not a voice call to be relayed.
5. drone feeds and Brave1 — the defense-tech cluster, reconnaissance video, target nomination
The sensor layer of this ecosystem is overwhelmingly unmanned. Thousands of reconnaissance and strike drones generate the bulk of fresh target data, and their ground-control stations are first-class participants in the SA stack, not afterthoughts. A drone operator watching live video can mark a coordinate and push a target nomination directly into the picture, where it becomes available to fires coordination within seconds.
Brave1 is the cluster that industrializes this. A government-backed coordination platform launched to connect developers, military units, and funding, Brave1 functions as both a marketplace and an integration forcing-function for Ukrainian defense tech. It is where new tools get discovered, tested against real units, and — critically — pushed toward conformance with the shared data formats so they can plug into Delta and the fires layer rather than becoming another island. The Brave1 and Delta Marketplace channels are where source and distribution for much of this software now lives.
The effect is a feedback loop: a unit needs a capability, a small team builds it, Brave1 helps field and integrate it, and the surviving tools converge on the common data model. Selection pressure, not central design, produces the integration.
6. how the layers exchange data — bridges, CoT, APIs, the integration seams and their friction
The federation between these systems runs over a small number of mechanisms. The Delta format and its APIs are the primary backbone: systems read and write entities and overlays through documented interfaces. Where third-party and coalition tooling is involved, Cursor-on-Target (CoT) — the lightweight XML event schema popularized by ATAK — acts as a lingua franca, and bridges translate between CoT events and the native Delta entity model.
These bridges are where the friction lives. CoT is event-oriented and loosely typed; the Delta model is entity-oriented and richer. Mapping one to the other means deciding how a transient CoT marker becomes a persistent tracked entity, how identity and track quality survive the translation, and how to avoid duplicate entities when two systems report the same object. Every bridge is, in effect, an opinionated translator, and two bridges can produce subtly different pictures from the same events. Latency, deduplication and identity reconciliation are the recurring engineering problems — the same class of problem any multi-source fusion system faces, solved here pragmatically and per-seam rather than by a single grand schema.
7. NATO interoperability — Delta as the alliance-facing surface, standards alignment
When the ecosystem has to speak to the alliance, Delta is the surface it presents. Its standards-conformant interfaces and exercise exposure make it the natural broker between national tools and coalition C2. Rather than ask NATO partners to integrate with a dozen Ukrainian apps, the model is to integrate with Delta and let Delta federate downward into Kropyva, the fires layer and the drone stations.
This is sound NATO interoperability practice: a single, well-specified federation point is far easier to certify and accredit than a mesh of bilateral integrations. Alignment with alliance data exchange standards — the messaging formats and entity models coalition systems already use — is what lets a Ukrainian track appear in a partner's picture and vice versa. The work is ongoing and imperfect, but the architectural instinct is correct: concentrate the alliance-facing interface in one place and harden it.
8. lessons for Western C2 — iterate at the edge, assume degraded comms, decouple apps from the data model
Three lessons port cleanly. First, iterate at the edge. The Ukrainian tools improved because units used them daily and fed corrections back to small teams that shipped updates in days, not program cycles. A Western prime cannot replicate the war, but it can replicate the loop: get software in front of operators early and shorten the feedback cycle ruthlessly.
Second, assume degraded communications. Every app in this stack is designed to keep working when the network is jammed, intermittent or absent — local computation on the tablet, store-and-forward sync, graceful degradation. Western C2 that assumes a reliable backbone is building for an environment that electronic warfare will not provide. Design for the disconnected case first and treat connectivity as a bonus.
Third, and most important, decouple the apps from the data model. The reason this fragmented ecosystem federates at all is that the entity model is the contract, and the applications are interchangeable clients of it. A Western program that lets a vendor's protocol or UI leak into its core domain model buys itself a rip-and-replace problem the first time requirements change. Ukraine's pragmatic, sometimes messy stack got one thing structurally right — the picture is owned by the data model, not by any application — and that is the lesson most worth importing.