Defense
Mission Systems
Conformant capability, not captive capability
For decades, the capabilities that decide a fight (sensor fusion, tracking, mission reasoning) lived welded inside platforms, built and owned by the platform integrator. The open architectures changed that. With Open Mission Systems (OMS), Universal Command and Control Interface (UCI), and the AMS Government Reference Architecture (AMS GRA), a mission capability can be built, verified, and fielded as an independent, conformant service: procured on its own merits, swapped without re-integrating the platform around it, sourced from whoever can actually meet the standard.
Stator builds in that world. We deliver mission capabilities as OMS-conformant, independently procurable units: Minimum Procurable Units that drop into any conformant platform and behave exactly as the standard says they will. That is open mission systems integration for defense open architecture, not captive capability locked to a single integrator.
Standards we work to
Our mission-systems work sits inside the Modular Open Systems Approach (MOSA) and related open-architecture families: Sensor Open Systems Architecture (SOSA), Future Airborne Capability Environment (FACE), and the Autonomy Government Reference Architecture (A-GRA). Spelling the names out matters for clarity; the acronyms are what programs actually type.
We're opening the foundation
The hardest part of the open architecture isn't writing a service. It's getting from running code to a defensible, assessed conformance posture. Stator is publishing the foundation that closes that gap, openly, as a reference for the whole community:
- Day-one-conformant libraries: the CAL plus baseline conformance implemented out of the box, so a service is compliant the moment it is built.
- A conformant service template: start from it, write your business logic, and you already have a fully conformant service.
- A behavior-driven conformance harness: executable step definitions for UCI and A-GRA, so conformance is expressed as human-readable, runnable specifications rather than prose nobody can test.
- Pipeline and deployment tooling: CI/CD components and deployment configuration that carry conformance through the entire build-and-field lifecycle.
The goal is simple: make the conformant path the easy path, and make the result something you can actually prove. That foundation is the OMS Developer Kit.
Up the command echelon
The mission-systems pattern (a fused local picture, with pluggable, conformant capabilities reading from and writing to it) exists at the platform. It does not exist one level up, at the command echelon, where the world is more relational, more uncertain, and still largely stitched together by hand. We are extending the same open-architecture discipline to that layer. More on that when it's ready.
Build on the standard
For how we license individually procurable services, see Licensing.