Non-Negotiable: What the Army's Open Architecture Mandate Means for Safety-Critical, Autonomous Platforms

Open and fast are now requirements. Safe, secure, and certifiable still are too. Here is how Lynx helps programs deliver all of it.

At AUSA 2026, Acting Army Secretary Adam Telle said everything the Army buys will have open architecture, and called it "non-negotiable." In our first post we described this as one of five shifts reshaping Army technology. This post is for the engineers and program leads who now have to make it work.

Because the mandate raises a question that rhetoric does not answer: if everything is open, commercial and updated at the speed of business, what keeps it safe, secure and certifiable?

Openness removes lock-in. It does not remove the need for isolation, determinism and assurance. If anything, it raises the stakes. 

The Tension Programs Now Face

Four AUSA themes collide on the same hardware: 

• Open and Modular: Open architecture, an Army-owned data layer (NGC2), and a commercial marketplace where new entrants compete on software.

• Autonomous: FASCOM, autonomy integrated into at least six formation areas including aviation, armor and fires, and a fielding push by fiscal year 2028.

• AI-Enabled: Autonomy and decision aids increasingly depend on GPU and accelerator compute, bringing large, fast-changing AI workloads onto the same platforms as critical functions.

• Fast and Distributed: Problem-based acquisition, rapid update cycles, and systems that must run at the contested edge and survive disconnection.

Put those together and a platform may host third-party applications, AI-driven autonomy and legacy functions alongside flight-, vehicle- or weapon-critical software, all updated more often than traditional certification cycles assume. That is the engineering problem. It cannot be solved with a procurement clause. 

Five Requirements Hiding Inside "Open"

1. Isolation between software of different trust and criticality: A commercial app or an autonomy module should never be able to disturb a safety function. Hardware-enforced separation, not just policy, is what lets programs mix workloads on shared processors while containing faults and attacks.

2. Modularity that survives contact with real programs: Open standards only pay off if components can actually be swapped, added and updated independently, including by suppliers other than the original integrator.

3. A credible path to certification and re-certification: Telle wants the Army to move at the speed of business. For aviation and other safety-critical platforms, that is only achievable if the architecture localizes change, so an update to one component does not force re-qualification of everything.

4. Security that assumes a contested environment: Distributed operations, allied data-sharing (including the push to relax NOFORN constraints) and counter-UAS at the edge all demand software that is secure by construction and can enforce who sees what.

5. Safe, governed access to AI and GPU compute: Autonomy, sensor processing and decision aids need GPUs and other accelerators. Programs need to host those workloads on modular platforms, keep them isolated from safety and mission functions, and update models and software at a pace traditional embedded stacks were not built for.

How Lynx Approaches It 

Lynx builds software for exactly this intersection of openness and assurance. Our approach rests on a simple idea: separate what must be protected from what must be flexible, and make that separation strong enough to certify. 

• Separation and Partitioning: Our separation-kernel and hypervisor technology (LynxSecure) is designed to isolate workloads on shared hardware, so critical and non-critical functions can coexist without interfering with each other.

• MOSA Enablement: Our MOSA framework (LYNX MOSA.ic) is built to help programs adopt modular, standards-aligned architectures and integrate components from multiple vendors.

• Certifiable Real-Time Foundations: Our RTOS offerings are not limited to LynxOS-178. LynxElement is part of the portfolio too, giving programs a choice of real-time foundation matched to their assurance level, platform and deployment needs. Both support deterministic, safety-critical functions where assurance evidence matters.

• AI and GPU Enablement (MOSA.ic.AI): Building on the MOSA.ic framework, MOSA.ic.AI is aimed at bringing GPU and accelerator-based AI workloads onto modular, partitioned platforms, so AI can be hosted, isolated and updated without disturbing critical functions.

• Security by Design: Isolation, controlled information flow and a minimal trusted computing base support the secure data-sharing that allied and distributed operations require. 

Mapping AUSA Signals To Lynx Use Cases 

A Note on Aviation

No one at AUSA spoke directly about specific aviation programs such as MV-75 or Apache, and we do not want to imply otherwise. What we can say is general: Telle's criticism of program-centric structures, his preference for modular and commercial approaches, and the Army's plan to bring autonomy into aviation formations all favor architectures where software can evolve independently of the airframe. That is the design principle we build around.

Questions to Ask when Writing MOSA and Autonomy Requirements

• Does the architecture enforce isolation in hardware, or only by convention?

• Can a third party add or update a component without re-qualifying unrelated functions?

• What certification evidence exists today, and what is the plan for re-certification after change?

• How is information flow controlled between applications, including allied or cross-domain data?

• What happens to critical functions when an autonomy or commercial component misbehaves?

• How are GPU and accelerator resources shared and isolated between AI workloads and critical functions?

• Can AI models and software be updated independently of the certified baseline?

• Which interfaces are standards-based, and who owns them?

Where this Goes Next

The mandate is clear. The hard part is delivering open, autonomous and fast without giving up safety and security. That is where programs will succeed or stall over the next few years, and it is the problem we work on every day.

If you are shaping requirements or architecture for a platform affected by these shifts, we would welcome the conversation. Contact the Lynx team to discuss how separation, modularity and certifiable foundations can fit your program.