Aerospace & Defense research

MOSA designs defense systems for affordable change

MOSA aligns modular design, interfaces, data rights, qualification, and acquisition so defense systems can change without reopening the full system.

Originally published in 2024 ยท Substantially revised in 2026

The operating idea

Decouple what must change without giving up control of the mission.

Modular Open Systems Approach (MOSA) is an approach to decoupling complex systems for greater modularity and composability and decreased lock-in. Talbot West applies MOSA principles to complex informational and AI systems.

Defense systems stay in service longer than the software, sensors, compute, and communications inside them. 10 U.S.C. 4401 defines MOSA as an integrated business and technical strategy using modular design and modular system interfaces. MOSA defines modules and interfaces for replacing selected components without redesigning the full system.

Interface control, data rights, qualification, and contracts determine replacement cost, eligible suppliers, and schedule for each component.

MOSA makes a broader Talbot West design discipline concrete in defense. Across industries, we start with the capability an organization needs, then choose the mechanisms and specialists that fit. The test is the same: preserve the outcome while deciding which components change independently, who controls their interfaces, and what rights make replacement practical.

Why MOSA exists

Architectures outlive the technologies inside them.

Programs commit to architectures and contracts before they know which sensors, software, or compute will age first. A tightly coupled design ties those refreshes together. MOSA defines boundaries for independent upgrades, replacement, and competition.

Each open boundary adds interface, integration, test, and sustainment costs. Open a boundary when replacement value, interoperability, or competition justifies those costs.

Five practices

MOSA requires technical design and acquisition terms to work together.

01

Establish an enabling environment

Program offices set acquisition strategy, data-rights terms, interface-control authority, standards, and qualification rules. If contracts or governance block replacement, modular design has no commercial effect.

02

Employ modular design

Partition the system where components change on different cycles or need separate competition. Contain change at each boundary without exporting integration burden to adjacent components.

03

Designate key interfaces

Name the interfaces that govern substitution, interoperability, upgrade cost, or supplier competition. Assign each an owner and a change authority before integration begins.

04

Use open standards that support substitution

Adopt a standard when it gives multiple suppliers a usable interface or improves interoperability. A standard that changes neither substitution economics nor interoperability adds compliance effort without opening the system.

05

Certify conformance

Test each implementation against the interface and end-to-end mission behavior. A published standard does not prove that two components interoperate.

Design criterion

Preserve mission capability across technology refreshes.

Keep mission functions, interface contracts, data access, qualification evidence, and architectural decision rights under program control. Replace vendors, models, sensors, software, and compute as performance, cost, or threats change.

Supplier dependence persists through data and qualification

Modular boundaries do not erase supplier dependence. Proprietary data formats, undocumented behavior, restricted tools, license terms, qualification evidence, integration knowledge, and sustainment expertise all affect switching cost.

Some dependencies create value. Validated components, stable interfaces, common standards, and accumulated expertise support safety, reliability, and lower integration cost. Preserve dependencies that produce measurable value; remove those that block viable replacements.

For each key interface, record who controls technical data, test tools, qualification evidence, licenses, and change authority. Then price the work a replacement supplier must complete before its component enters service.

MOSA applies to software, data, and AI

AI-enabled systems distribute mission functions across models, data pipelines, retrieval, sensors, evaluation, software, user interfaces, policy controls, compute, and human authority. These elements change on different schedules and carry different proprietary value. Treating them as one component makes independent upgrades and competitive replacement harder.

CHAI applies related design logic to AI workflows across industries where a business process needs different kinds of computation. It assembles specialized components around a workflow and defines how their outputs, uncertainty, failures, and disagreements shape decisions. MOSA is a useful analogy for interfaces and replacement, not proof that an AI architecture is sound. CHAI adds the decision and governance contracts MOSA does not specify for AI components. CHAI's decision architecture explains the distinction.

Program leaders must identify which interfaces, data, and evaluation criteria stay under program control. They must also define replacement criteria for models, retrieval systems, sensors, software, and compute.

Architecture sets the cost of future change

Contracts, data rights, certification, tooling, test access, and integration knowledge set the cost and schedule of substitution.

For each boundary, compare the cost of maintaining interfaces, testing substitutes, and integrating replacements with the cost of redesign after obsolescence or supplier failure. Keep the boundary open when avoided redesign and competition justify that investment.

Align architecture with acquisition

Modernization requires an architecture and acquisition plan that names each key interface, its owner, data rights, contracting mechanism, qualification criteria, and integration funding.

Align interface ownership and data rights with contract and certification paths. Then the program knows what a replacement supplier must prove, buy, or receive before integration.

Open each interface only when avoided redesign, competition, or interoperability justifies its integration, testing, and sustainment cost.

The test

MOSA is proven at the point of substitution. A qualified supplier replaces a component through a controlled interface without reopening the full system.