Government-Owned Integration: The Air Force MASH Model
The Air Force's MASH experiment combined AI microservices from different vendors into one battle management workflow. The result was a working example of government-owned integration, where the government controlled the orchestrator, data models, and ontology that made the pieces interoperable.
Open architecture arguments tend to stall at the level of standards documents, interface specifications, and contract language.
The Air Force’s recent Multi-Decision Advantage Sprint for Human-Machine Teaming, or MASH, provides something more useful: a working example of government-owned integration.
During the May 2026 experiment, multiple industry teams built independent artificial intelligence microservices for different parts of the battle management process. Rather than selecting one vendor to deliver an end-to-end application, the Air Force combined services from different developers into operational workflows.
The important result was not simply that the applications communicated. It was that the government controlled the environment that made communication possible.
A Working Example of Open Architecture
The two-week MASH experiment was conducted at the Shadow Operations Center-Nellis and led by the Department of the Air Force’s Advanced Battle Management System Cross-Functional Team. The effort included the Air Force Research Laboratory, the U.S. Space Force, the 805th Combat Training Squadron, operational battle managers, and industry software developers. Industry software teams and the 805th Combat Training Squadron’s own engineers were assigned to develop AI-enabled tools for three decision functions:
- Analyzing incoming information and identifying relevant entities.
- Matching available capabilities to the operational situation.
- Generating potential battle courses of action.
Each simulated workflow used three separate microservices, with each service developed by a different team. The applications therefore had to work as a system even though no single company had built the entire system.
That is a more demanding test of open architecture than publishing an interface standard or requiring vendors to expose APIs.
The Government-Owned Integration Layer
The independent microservices were connected through an orchestration tool developed by AFRL.
Col. John Ohlund, director of the ABMS Cross-Functional Team, described its role directly:
“AFRL has done incredible work building an orchestrator that ensures these different companies can exchange data, ontologies and metadata seamlessly.”
The result was an environment in which the Air Force could combine independently developed capabilities and evaluate different services without committing the entire workflow to one vendor. That is the central lesson from MASH.
The strategic asset was not any one AI application. It was the government-controlled integration context surrounding those applications:
- The orchestration mechanism
- The data structures exchanged between services
- The ontology mappings that established shared meaning
- The metadata required to interpret and govern outputs
- The test environment used to determine whether components behaved correctly
Ownership in this context means more than holding intellectual property rights. It means having the authority and technical ability to operate, test, modify, and evolve the integration layer without depending on a single application vendor.
That is what government-owned integration looks like in practice.
Open APIs Are Not an Open Architecture
An API can define how one system sends a field to another system. It does not necessarily establish what that field means.
Two applications may both accept an object labeled target, for example, while applying different definitions, confidence thresholds, classification rules, geographic models, or assumptions about operational status.
The interface can be syntactically valid while the resulting system remains semantically incompatible.
This is why open architecture cannot be reduced to interface control documents. Interfaces describe how components connect. Ontologies and data models determine whether the connected components understand one another.
Without control of that semantic layer, the government may be able to replace an application in theory but not in practice. A new vendor must either reproduce the incumbent’s proprietary interpretation of the data or force every connected system to accommodate a new one.
The integration burden becomes the lock-in mechanism.
Open Architecture Is Won or Lost on the Ontology
An ontology defines the concepts a system recognizes and the relationships among them.
In a battle management environment, that may include definitions for entities, threats, effects, capabilities, constraints, timing, confidence, availability, authorities, and courses of action.
These definitions are not secondary documentation. They influence how software interprets the operational environment and how one service consumes another service’s output.
Whoever controls the ontology therefore controls the terms on which the system participates.
A vendor-controlled ontology can become a proprietary center of gravity even when every individual application exposes a nominally open interface. Competitors may be permitted to connect, but only by adopting concepts, mappings, and dependencies established by the incumbent.
A government-controlled ontology changes that relationship. Vendors build against a shared operational model. Components can compete at the application and algorithm level without redefining the meaning of the information moving through the system.
That is the leverage point.
What Government Programs Should Own
A serious government-owned integration strategy should include more than a set of interface requirements. At minimum, the government should control:
The canonical data model
The government needs an authoritative representation of the objects, events, decisions, and relationships used across the mission workflow.
The ontology and semantic mappings
The program must define what exchanged information means, including how vendor-specific concepts map to the government’s canonical model.
The orchestration layer
The government needs a mechanism for composing services, routing information, handling failures, and replacing one implementation with another.
Metadata and provenance requirements
Outputs should carry sufficient context to identify their source, version, confidence, assumptions, security attributes, and transformation history.
Conformance tests and reference implementations
A published standard is not enough. Vendors need executable tests that determine whether their services behave correctly within the government-owned environment.
Versioning and governance processes
Ontologies and data models will evolve. The government must control how changes are proposed, reviewed, tested, published, and retired.
These capabilities must be treated as operational software products, not static contracting artifacts.
The Acquisition Implication
Programs frequently attempt to negotiate open architecture after an application has already become central to the mission.
By then, the application may have accumulated years of proprietary data structures, business rules, semantic assumptions, and point-to-point integrations. Extracting those dependencies can be more difficult and expensive than replacing the application itself.
Contract language helps, but contracts cannot recover architectural leverage that the government never established.
The integration layer, data model, and ontology must be government-controlled from the beginning. Vendors should compete to provide components within that environment rather than competing to become the environment.
This approach preserves room for continuous competition. A program can evaluate new algorithms, user interfaces, data sources, or decision-support services without rebuilding the full system around each new entrant.
It also changes the government’s role. The government is no longer only a purchaser of finished applications. It becomes the architect and steward of the operational ecosystem in which those applications run.
From Standards Compliance to Substitutability
The practical test of an open architecture is not whether every vendor claims compliance with the same standard.
The test is whether the government can remove one component, insert another, and continue operating without redesigning the rest of the system.
The MASH experiment moved that principle from a standards document into a working battle management environment. Independent teams developed separate AI services. AFRL provided the orchestration mechanism. The services exchanged data, ontologies, and metadata as part of a combined workflow.
That is a credible model for government-owned integration.
Polyrhythm’s view is straightforward: open architecture is won or lost on who controls the ontology.
Applications will change. Vendors will change. Algorithms will improve. The semantic foundation connecting them must remain under government control.