The U.S. Army is putting hard policy behind something the defense industry has discussed for years: systems must become easier to integrate, upgrade, and evolve. Army Directive 2026-21, Implementing Modular System Interfaces, took effect on August 24, 2026. It requires program managers across new and legacy acquisition efforts — regardless of dollar value or acquisition pathway, and spanning the regular Army, National Guard, and Reserve — to apply modular design, standardized interfaces, documented system access, and secure APIs so the Army can integrate existing, future, and authorized third-party capabilities.
This is an important evolution of the Modular Open Systems Approach — and notably, it is being institutionalized: the directive folds into Army Regulation 70-1 within two years, so it will outlast any single official. It reflects lessons the Army says it drew from operational reporting and from a validation sprint during Operation Jailbreak, which demonstrated that open architectures and APIs let Army systems share information and support battlefield visibility.
The directive gets the interface right. Our argument is about the layer it implies but does not specify: the right to integrate also requires the ability to integrate safely.
Figure 1: Openness lives at the interface; the separation-kernel foundation beneath it is what keeps mixed-criticality integration safe.
From Open Hardware to Open Software Integration
For years, MOSA conversations centered on hardware modularity: standard form factors, replaceable components, open buses, and the ability to source subsystems competitively. Those remain essential. But increasingly, the real integration challenge is software. Modern mission systems combine applications, sensors, operating environments, communications, AI models, graphics, real-time control, and accelerated compute. Making the hardware modular does not automatically make those capabilities easy to integrate or replace.
The Army’s latest direction recognizes this reality. Its requirements are almost entirely about the software and data plane: secure bidirectional APIs, documented access to telemetry and operational data, appropriate data rights, and explicit restrictions against artificial technical barriers. The question is no longer simply “Can I replace this hardware component?” It is increasingly “Can I introduce a new software capability — a sensor, an application, an AI workload, a different operating environment, an upgraded GPU, or software from another supplier — without destabilizing mission-critical functions that are already deployed and validated?” That is where the software architecture underneath the applications becomes decisive.
Openness Does Not Mean Giving Up Control
There is an important distinction between an open system and an uncontrolled one. Simply exposing more APIs or admitting more applications onto a platform does not, by itself, create a mission-ready architecture. At the tactical edge, applications have dramatically different requirements. A Linux analytics workload may coexist with a safety-critical control function. AI inference may share compute with deterministic real-time software. One application may need GPU acceleration while another handles communications, cybersecurity, or vehicle control. Those applications come from different suppliers, carry different assurance levels, evolve at different rates, and in some cases should not trust one another. The more open the system becomes, the more the boundaries underneath it matters.
That is the fundamental idea behind LYNX MOSA.ic.AI. It uses a separation-kernel-based architecture to create controlled execution environments in which multiple operating systems and applications run side by side while maintaining strong isolation and predictable allocation of computing resources — deterministic partitioning, mixed-criticality consolidation, and open systems integration. The objective is not to dictate which application, operating system, or supplier a program must use. It is to provide a trusted foundation underneath them.
This is also where the directive’s security requirements land. It does not ask for APIs — it asks for secure bidirectional APIs, with full compliance to Army and Department of War cybersecurity policy. An API is only as trustworthy as the boundary it sits on. If a compromised or misbehaving application can reach across into a safety- or security-critical function, the interface was open, but the system was not safe. Strong isolation beneath the API is what lets a program expose data and control surfaces to third parties without widening the attack surface of everything else on the platform.
The Operating System Should Not Become the New Vendor Lock-in
Software openness also changes how we should think about operating systems. Mission platforms increasingly need heterogeneous environments: one function needs an RTOS, another needs Linux, a legacy capability depends on an operating environment selected years ago, and a new application is built in a different ecosystem entirely. Forcing all those workloads into a single operating-system environment simply moves vendor lock-in from one layer of the architecture to another.
The directive itself is emphatic on this point at the interface level: no proprietary data formats, no artificial technical limits, and — pointedly — no deprecating an API endpoint without an equivalent or superior replacement at no added cost. That is anti-lock-in language. But lock-in defeated at the interface can quietly reappear one layer down if the operating system becomes the platform. A modular architecture should instead let programs select the appropriate runtime for each workload while keeping a common foundation for isolation, resource control, and integration. That is why MOSA.ic supports multiple operating environments rather than treating the OS as the platform: RTOSes, Linux, unikernels, bare-metal applications, and third-party operating environments can coexist as peers within a partitioned system. True openness protects existing software investment while allowing new capability to be inserted alongside it.
Figure 2: Lynx sees the evolution of MOSA through three complementary requirements — control of resources, efficient deployment of capability, and governance across the lifecycle.
MOSA is Moving Into the CPU, the GPU, and Now the AI Stack
The same principle extends beyond CPUs. AI, sensor fusion, advanced visualization, image processing, and autonomous functions are driving GPUs and other accelerators deeper into mission systems. The directive quietly acknowledges this: alongside gRPC, MQTT, WebSockets, and GraphQL, its list of acceptable interface protocols includes Model Context Protocol — an AI-agent integration standard. When the Army’s own interface policy names a protocol for connecting AI models and agents, it is formally recognizing that the integration surface now reaches into the AI stack.
That raises the stakes for the foundation. The next generation of MOSA architectures must answer: how do we make heterogeneous compute available to applications — including AI agents — without recreating proprietary silos or compromising determinism and isolation? That challenge is central to LYNX MOSA.ic.AI, which extends the deterministic infrastructure model across CPU and GPU domains so advanced workloads can coexist with real-time and safety-critical applications while preserving controlled execution and system integrity. Software modularity ultimately depends on more than an API: programs need to deploy new capability onto the compute best suited to it while keeping behavior predictable across the whole platform.
Figure 3: Each requirement in Directive 2026-21 implies an architectural property the interface alone cannot deliver.
The Real Meaning of the "Right to Integrate"
The directive is the latest step in a broader Army push — a Silicon Valley-style acquisition model, a commercial-first approach to software, and the Right to Integrate initiative aimed at reducing the custom engineering and proprietary barriers traditionally required to make different defense systems work together. The commercial-first direction makes the foundation question sharper, not softer: bringing more off-the-shelf and third-party software onto a mission platform only works if that software can be admitted without putting the safety case at risk.
So, the right to integrate has an architectural consequence. Programs need freedom to introduce new technology without letting a change in one part of the system create unpredictable consequences elsewhere. They need openness without losing isolation, modularity without losing determinism, innovation without repeatedly resetting the certification and assurance baseline, and supplier choice without sacrificing mission confidence. That is precisely why the underlying software substrate matters.
The Real Meaning of the "Right to Integrate"
This is not a thought experiment. LYNX MOSA.ic was selected by Bell Textron and Lockheed Martin to help power mission-system software on the U.S. Army’s Future Long Range Assault Aircraft — the MV-75 Cheyenne II — a program built around a MOSA open-architecture digital backbone and designed for hardware-agnostic, refreshable integration over a decades-long service life. It is a concrete example of what the directive is asking for: an open integration surface above, and a trusted, controlled foundation beneath.
Building Platforms That Can Evolve
MOSA should ultimately be measured by what it lets a program do over time. Can capabilities be changed independently? Can new suppliers participate? Can technology be refreshed without wholesale redesign? Can legacy investment be preserved? Can software and AI capability evolve faster than the vehicle or weapons platform beneath them — while maintaining the safety, security, determinism, and assurance that mission-critical systems demand?
Directive 2026-21 reinforces that open architecture is about far more than interchangeable hardware. It is about building systems designed from the outset to evolve. At Lynx, that is how we view the role of MOSA.ic: a trusted software foundation that gives programs the freedom to integrate above it while maintaining control underneath it.
The Army is establishing the right to integrate. The industry’s challenge is to build the architecture that makes that right practical, scalable, and trustworthy.
To learn more about LYNX MOSA.ic.AI, visit the product page. To gain a deeper technical insight into LYNX MOSA.ic, read our technical whitepaper.
