Do Not Wait for the Center: A Federated Model for Defense AI Acquisition
How mission command, federated marketplaces, reusable security evidence, open-source sustainment, and first-prime pathways can move defense AI from centralized dependency to distributed execution at scale in order to create Defense AI Acquisition Reform.
Somewhere inside the Department of War, a mission team already knows what it needs.
The team has an operational problem, personnel prepared to test a solution, and perhaps even a small business or open-source project capable of producing a useful result within weeks. What the team lacks is not technology. It lacks freedom of movement.
The requirement must travel through several headquarters. The funding belongs to another organization. The data sits behind an enterprise gate. The security approval assumes a conventional software lifecycle. The contracting vehicle was designed around a large integrator. The past-performance criteria favor companies that have already won large prime contracts. The central office wants to standardize the solution before the mission owner has been allowed to test it.
By the time permission arrives, the model has changed, the original requirement has evolved, and the small company has either run out of money, shifted toward a commercial market, or agreed to work beneath a prime contractor that will absorb much of the funding without necessarily improving the technology.
The Department then pays an integration premium to acquire something more expensive, more complicated, and less adaptable than the capability it could have purchased directly.
That is how a ten-dollar hammer becomes a four-hundred-dollar hammer.
Not necessarily because the hammer itself costs four hundred dollars, but because the acquisition system surrounds it with layers of program management, integration, compliance translation, subcontract adminismtration, proprietary tooling, and labor-based support. Complexity becomes the justification for a large team, and the large team becomes the justification for additional complexity.
Artificial intelligence gives the Department an opportunity to break that cycle. It also creates a danger that the same cycle will simply be rebuilt around models, data platforms, agents, and enterprise AI contracts.
Centralize strategic intent, security boundaries, identity, evidence, and interoperability. Decentralize experimentation, product selection, integration, contracting, and mission execution.
That is how the Department can move at AI speed without making the Chief Digital and Artificial Intelligence Office or “any other central organization” the mandatory gateway to progress.
Figure 1. The $600 Hammer Syndrome: the tool is not the system.
The Problem Is Larger Than One Office
The debate surrounding CDAO, Advana, and the Department’s broader innovation ecosystem should not be reduced to personalities. The stronger argument is structural: an organization can begin as an accelerant and gradually become a dependency. The dependency becomes a gate. The gate becomes a bottleneck. Eventually, the organization spends more effort managing the complexity it accumulated than delivering the outcome it was established to produce.
That concern now sits beside the Department’s own reform direction. The January 2026 Artificial Intelligence Strategy for the Department of War states that competition should outperform centralized planning, calls for small accountable teams, directs continuous field experimentation, and requires modular open system architectures with documentation sufficient for third-party integration without prime-contractor support.
A companion memorandum on transforming the defense innovation ecosystem is equally direct: empowered execution organizations should deliver with operational independence, program offices own the last mile, and mission command should govern the ecosystem through intent, priorities, barrier removal, and measurable outcomes.
The Department’s stated strategy therefore contains much of the answer. The unresolved question is whether the operating and acquisition systems will permit that strategy to be executed at the echelon where mission information is freshest.
The center should define the boundaries. The mission owner should move inside them. |
Figure 2. Centralized chokepoint versus federated execution.
The Department Needs an AI Market, Not Another AI Monolith
The Department should establish a federated Mission Capability Exchange: an app-store-like environment through which military departments, combatant commands, defense agencies, major commands, program offices, installations, and authorized local organizations can discover, test, acquire, deploy, evaluate, and replace AI-enabled capabilities.
This should not be one centrally controlled storefront. It should be a network of interoperable exchanges that share common technical, security, contracting, and evidentiary standards. Each military department or agency could operate its own exchange while allowing qualified solutions and reusable evidence packages to move among them.
The center would define the rules of the market. It would not select every winner.
The Department has already demonstrated parts of this model. Tradewinds operates as a marketplace for readily awardable AI, data, and analytics solutions. Platform One’s Iron Bank provides a vetted repository of assessed containers for rapid, scalable, and secure deployment. The next step is to connect discovery, qualification, contracting, authorization, deployment, telemetry, and renewal into one continuous mission-to-outcome workflow.
The exchange should organize demand around mission effects rather than vendor product pages. A logistics organization should describe the decision or workflow it needs to improve, the data involved, the consequences of failure, the operating environment, the maximum acceptable cost, and the measurable outcome. Vendors, small businesses, research teams, and open-source projects should compete against that mission card—not rewrite the requirement around the platform they already sell.
Figure 3. The Mission Capability Exchange: a market for mission outcomes.
The Security Capability Passport
The output of these five layers should be a signed, machine-readable Security Capability Passport associated with the exact application, model, agent, policy, configuration, and evidence versions evaluated.
The passport should identify inherited controls, contractor controls, product controls, AI SAFE² runtime controls, mission-owner responsibilities, known weaknesses, restrictions, evidence expiration, and the authority responsible for the most recent risk decision.
The technical structure should use open formats such as NIST’s Open Security Controls Assessment Language wherever possible, with extensions for model lineage, agent identity, memory state, delegation, runtime evidence, and mission restrictions. FedRAMP evidence can establish the cloud foundation; SP 800-171 evidence can establish applicable CUI protections; software evidence can establish product integrity; AI SAFE² can establish runtime governance; and mission evidence can establish operational suitability.
That creates one evidence fabric with multiple valid risk views. A capability qualified in one service or agency can carry its reusable evidence to another. The receiving organization still decides whether the capability is suitable for its mission, but it does not rebuild every assurance artifact from zero.
Figure 4. Five-layer federated security qualification.
The Security Capability Passport
The output of these five layers should be a signed, machine-readable Security Capability Passport associated with the exact application, model, agent, policy, configuration, and evidence versions evaluated.
The passport should identify inherited controls, contractor controls, product controls, AI SAFE² runtime controls, mission-owner responsibilities, known weaknesses, restrictions, evidence expiration, and the authority responsible for the most recent risk decision.
The technical structure should use open formats such as NIST’s Open Security Controls Assessment Language wherever possible, with extensions for model lineage, agent identity, memory state, delegation, runtime evidence, and mission restrictions. FedRAMP evidence can establish the cloud foundation; SP 800-171 evidence can establish applicable CUI protections; software evidence can establish product integrity; AI SAFE² can establish runtime governance; and mission evidence can establish operational suitability.
That creates one evidence fabric with multiple valid risk views. A capability qualified in one service or agency can carry its reusable evidence to another. The receiving organization still decides whether the capability is suitable for its mission, but it does not rebuild every assurance artifact from zero.
Figure 5. The Security Capability Passport follows the capability; the mission still decides whether to use it.
Continuous Qualification Instead of Periodic Certification
A certification can confirm that a set of controls existed at a particular moment. It cannot prove that a system remains secure after a model change, retrieval update, modified system prompt, new tool, expanded permission, memory-schema change, dependency update, new mission purpose, or increase in autonomy.
The marketplace should therefore align with the direction of FedRAMP 20x: machine-readable evidence, measured outcomes, persistent validation, and progressively stronger assurance rather than static documentation alone.
Every material component should have a unique identity and version. When a component changes, the platform calculates which security claims and mission controls may be affected. A low-impact library patch may rerun vulnerability, dependency, signing, and regression tests. A new model may trigger behavior, provenance, cost, and mission-performance evaluations. A new tool may trigger permission, exfiltration, logging, and human-approval tests. A shift from read-only assistance to autonomous execution should trigger a new autonomy classification and mission authorization.
The capability moves automatically when required evidence remains valid. It stops automatically when a required control fails. Only unresolved exceptions require human review.
Independent Validation Without an Assessor Tollbooth
Eliminating a mandatory third-party certification for every company does not require eliminating independent assessment. It requires placing independent assessment where consequence justifies it.
Government or accredited independent assessment should remain available for high-impact systems, high-autonomy agents, mission-critical capabilities, sensitive environments, significant architecture changes, repeated failures, inconsistent evidence, random spot checks, intelligence-driven reviews, and incidents suggesting inaccurate self-attestation.
The assessor should evaluate technical behavior and evidence—not sell a mandatory stamp that every emerging company must purchase before entering the market. The objective is neither “audit harder” nor “audit never.” It is to validate continuously, assess independently where consequence requires it, and never allow paperwork to substitute for demonstrated security.
Automated Gates, Human Decisions by Exception
The exchange should express routine legal, security, acquisition, and architectural conditions as executable policy wherever possible. Automated gates could determine whether the data classification is supported, whether mandatory evidence exists, whether artifacts are signed, whether data can be exported, whether agent permissions exceed the mission card, whether projected consumption breaches the ceiling, or whether unresolved vulnerabilities block deployment.
Each gate should produce one of three results: pass and proceed automatically; conditional pass with specified controls; or exception requiring a human decision. Most low-risk transactions should not require a committee meeting. Contracting officers, authorizing officials, counsel, security professionals, and mission leaders should spend their scarce time on consequential exceptions and market design—not recreating routine documents.
Figure 6. Automated gates; human decisions by exception.
The Contracting System Must Match the Technology
An app-store operating model cannot scale if every installation requires a new 18-month source selection. The exchange needs predesigned contracting lanes that match the maturity, uncertainty, and economics of the capability.
Commercial Products and SaaS
Mature commercial capabilities should generally use commercial acquisition procedures with fixed implementation prices and transparent subscription or consumption rates. Every offer should disclose installation and integration cost, unit consumption price, minimum commitments, data-egress cost, model or API charges, support price, security-maintenance price, transition price, and maximum monthly and annual exposure.
The government should not be surprised by the cost of successful adoption.
Small-Business Solutions
Small companies should compete through modular multiple-award pools, capability-specific lots, frequent on-ramps, and bounded task orders. Rather than asking one prime to provide the application, integration, data engineering, cybersecurity, training, operations, and program management, the government should decompose requirements into modules that different firms can perform.
The FAR already permits small-business reserves and set-asides under multiple-award contracts and requires scrutiny when bundling reduces small-business participation. FAR 19.502-4 should be treated as a design consideration at requirement formation—not a compliance check after the requirement has already become too large for a new entrant.
The purpose is not artificial fragmentation. It is to prevent administrative convenience from becoming a permanent competitive advantage for the largest bidder.
Open-Source Capabilities: Fund the Maintainers, Not the Markup
The government should pay nothing for rights already provided by a permissive open-source license. It should pay directly for deployment, integration, security engineering, government-specific features, documentation, training, classified-environment support, vulnerability response, maintainer availability, long-term sustainment, and roadmap participation.
This is where the current model can destroy value. A large integrator may charge a substantial premium to incorporate an open-source project into a proprietary delivery stack. The integrator adds contract administration, program management, internal tooling, labor categories, and markup. The original contributors may receive little or none of the resulting revenue.
The government pays more while the people who understand the software best remain underfunded.
A direct sustainment model would route a larger share of funding to the small business or maintainers responsible for the capability. Those organizations could hire dedicated security engineers, documentation specialists, integration personnel, and support staff. They could respond to vulnerabilities faster, incorporate government requirements directly into the roadmap, and provide more knowledgeable support than a multilayer subcontracting chain.
This is consistent with the broader security principle behind securing the AI itself: the party closest to the code, model, memory, and runtime should be resourced to enforce the controls rather than merely produce a compliance translation for another layer.
Pay nothing for rights the license already grants. Pay transparent, fixed rates for the engineering and sustainment the mission actually requires. |
The ten-dollar-hammer analogy does not mean that every operational capability should cost ten dollars. Mission integration and security have legitimate costs. The principle is that additional spending must purchase measurable mission value—not complexity created to justify a massive delivery team.
Research and Technically Uncertain Development
Not every AI requirement can responsibly use a firm-fixed-price contract. Basic research, early experimentation, and genuinely uncertain development may require milestone-based prototypes, other transactions, cost-sharing, or other appropriate structures.
The Department can use prototype authority under 10 U.S.C. § 4022 where the statutory conditions are satisfied, while keeping the evaluation dataset, milestones, transition criteria, and follow-on logic visible from the beginning.
The rule should not be “fixed price regardless of uncertainty.” It should be: no unbounded economic exposure, no undefined deliverables, and no indefinite labor-based program where measurable outcomes can reasonably be established.
Breaking the Small-Business Prime Trap
The government often reports strong aggregate small-business spending while the number of participating firms declines. The Department’s own Small Business Strategy reported that small-business participation in the defense industrial base had fallen by more than forty percent over the preceding decade even as small-business prime spending increased.
That finding is documented in the Department’s Small Business Strategy. It reveals why total dollars alone are an inadequate measure of industrial-base health.
The current structure can create a self-reinforcing exclusion loop. A small business has not managed a large prime contract, so its lack of prime past performance is treated as a risk. It is pushed beneath an established prime. Its technical work is delivered, but the prime receives the contractual performance record. The small company then applies for the next prime opportunity and is rejected again because it still lacks prime past performance.
Whether or not an organization maintains a literal “no-prime list,” the practical effect can be the same: failure to win early prime awards becomes evidence that the firm should not receive future prime awards.
The answer is not to ignore contract-management risk. It is to separate technical-delivery risk from contract-administration risk.
The exchange should provide a first-prime pathway with smaller bounded awards, standard contract terms, government-furnished compliance templates, shared invoicing and reporting services, milestone-based payments, separate technical and administrative scoring, recognition of relevant subcontract and commercial performance, and graduated award ceilings based on demonstrated execution.
A firm could begin with a bounded deployment, establish a verified prime delivery record, progress to a multi-site deployment, and then compete for larger production work. Past performance would become something the system helps a capable company build—not a wall that prevents the company from entering.
Figure 7. The small-business prime trap and a first-prime progression.
From Hundreds of Opportunities to Millions of Transactions
The existing acquisition system is document-centric and human-intensive. It can support hundreds or thousands of major opportunities because every opportunity consumes substantial professional attention. An AI-enabled exchange should be designed for thousands to millions of smaller, lower-friction transactions.
That scale requires a different architecture: one control plane, many execution nodes.
The Department-level control plane should maintain common identity, security and autonomy taxonomies, interoperability standards, reusable contract terms, evidence schemas, supplier and contributor records, exclusions, cross-marketplace performance data, spend visibility, and oversight access.
Military departments, agencies, combatant commands, major commands, PEOs, installations, and units should operate execution nodes controlling local mission priorities, funding, deployment environments, evaluation datasets, operational tests, users, support, and adoption decisions.
A solution qualified in one node could share its evidence with another. The second node would still determine whether it met the local mission need. Qualification would be reusable; mission acceptance would remain local.
Contracting as Reusable Infrastructure
The marketplace should maintain modular clause libraries and ordering templates for commercial software, SaaS, consumption-based AI, open-source sustainment, data services, agentic systems, integration, classified deployment, prototypes, and maintenance.
Contracting professionals would remain responsible for legal sufficiency and award decisions. Their role would shift away from repeatedly rebuilding routine documents and toward designing competitions, protecting government interests, resolving exceptions, and exercising judgment where judgment matters.
Continuous Competition
The marketplace should never close permanently after one large award. New vendors, open-source projects, models, and capabilities should enter through frequent on-ramps. Existing suppliers should remain qualified only while evidence and performance remain current.
A company should not hold a ten-year position because it happened to be large and compliant at one moment. It should continue receiving work because the capability continues producing mission value.
Let the Best Capability Win—but Measure the Right Things
An app-store analogy is useful, but defense decisions cannot rely on star ratings alone. Popularity is not mission effectiveness.
The exchange should combine operator feedback with objective telemetry: successful workflow completions, accuracy against approved benchmarks, time saved, mission-effect improvement, cost per accepted result, human-intervention rate, retry frequency, false-positive and false-negative rates, security findings, rollback events, degraded-mode performance, transition performance, user retention, and support-response time.
The marketplace should display evidence in context: this capability solved this problem, under these conditions, with this data, at this cost, and with these documented limitations.
Resources would follow demonstrated results. Poor performers would be improved, competed, or deprecated. Successful applications would become more discoverable to users with similar needs. Adoption would emerge through evidence and mission pull rather than headquarters mandate.
Let performance—not organizational mass—determine what scales. |
What CDAO and Other Central Organizations Should Do
This model does not eliminate the need for CDAO or other Department-level organizations. It gives them a role appropriate to the center.
The center should establish measurement standards, interoperable evidence formats, shared testing infrastructure, model and agent evaluation, authorization reciprocity, identity and delegation standards, reusable acquisition clauses, enterprise data interfaces, common-mode risk analysis, and barriers that subordinate organizations cannot remove themselves.
It should not select every model, control every contract, own every application, or force every mission into one technical stack.
This is the institutional version of the argument made in CSI’s Architect’s Mandate: policy and observation are not enough. The architecture must make the desired behavior easier, the prohibited behavior harder, and accountability technically visible.
The center should make distributed execution safer and faster. It should not make distributed execution dependent upon the center.
AI Sovereignty at Every Echelon
AI sovereignty does not require every unit to train its own foundation model. It requires each mission owner to retain meaningful control over the capability upon which the mission depends.
That means control of mission data; the ability to replace a model or provider; knowledge of every agent operating in the workflow; authority to constrain or terminate agent activity; access to complete decision and audit records; the ability to export government information; the ability to operate under degraded conditions where required; and a credible path away from the incumbent vendor or integrator.
Sovereignty exists at multiple levels. A unit requires execution sovereignty. A combatant command or major command requires mission sovereignty. A military department requires portfolio sovereignty. The Department requires strategic sovereignty.
That model depends on diversity. Multiple models reduce common-mode failure. Multiple suppliers reduce economic dependence. Small businesses expand the industrial base. Open-source projects expose assumptions and enable independent validation. Local experimentation reveals mission differences that an enterprise office cannot anticipate.
Diversity without interoperability produces disorder. Uniformity without diversity produces fragility. The correct objective is interoperable diversity: many independently replaceable capabilities operating within common identity, security, evidence, and data standards.
Figure 8. AI sovereignty at every echelon.
This Is Easier Than It Appears
The Department does not need to build every element from zero. It already possesses digital marketplaces, hardened repositories, continuous-integration infrastructure, commercial acquisition authorities, multiple-award vehicles, small-business set-asides, prototype authorities, software factories, security-control catalogs, identity platforms, cloud environments, operational test organizations, and AI evaluation expertise.
The missing capability is the connective architecture.
The Department must join requirements, discovery, qualification, contracting, security, deployment, telemetry, payment, and renewal into one coherent transaction model.
The model can begin with one military department, agency, or major command and a limited set of low- and moderate-risk use cases. The initial measures should include time from mission card to test, time from test to award, cost of qualification, percentage of evidence reused, number of new prime contractors, number of open-source maintainers funded directly, percentage of dollars reaching technical contributors, reduction in integration markup, cost per successful mission outcome, and vendor or model replacement time.
The first implementation does not need to process millions of transactions. It needs an architecture capable of reaching that scale without requiring millions of manual reviews.
Figure 9. Do not wait for the center: one control plane, many execution paths.
The Strategic Choice
The Department faces a choice between two models of control.
The first concentrates money, data, contracts, technology, and authority in a limited number of enterprise organizations and prime contractors. It produces administrative uniformity but also long queues, high switching costs, reduced competition, and large common-mode failure surfaces.
The second centralizes strategic boundaries while distributing execution. It creates a transparent market in which military departments, agencies, commands, units, small businesses, open-source contributors, and commercial firms can participate under common rules.
The first model asks who controls the platform. The second asks whether the mission is being accomplished.
The first funds organizational mass. The second funds measurable value.
The first treats the absence of prior prime awards as a reason not to trust an emerging company. The second creates bounded opportunities through which capable companies can earn that trust.
The first pays an integrator to place layers around a ten-dollar hammer. The second pays the people who designed the hammer to maintain it, improve it, secure it, and ensure it works for the operator.
Centralized strategic intent. Federated marketplaces. Automated gates. Continuous competition. Modular contracts. Directly funded contributors. Security inheritance. Local mission authority. Measurable outcomes. |
The Department does not need to wait for a perfect central organization. It needs an operating system that continues advancing when the center is slow, strategically misaligned, captured by legacy incentives, or simply wrong.
Define the objective. Establish the boundaries. Equip the force. Measure the result. Then let capable people execute.
Selected Sources and Further Reading
- Artificial Intelligence Strategy for the Department of War (January 2026) — Competition, small accountable teams, field experimentation, and modular open architectures.
- Transforming the Defense Innovation Ecosystem to Accelerate Warfighting Advantage — Mission command, empowered execution organizations, and program-office ownership of the last mile.
- Department of War Suspends CMMC Phase II Requirements — Official July 2026 announcement and reform direction.
- FedRAMP 20x — Modernized cloud assurance using measured outcomes, machine-readable evidence, and persistent validation.
- NIST Open Security Controls Assessment Language (OSCAL) — Open XML, JSON, and YAML formats for automated control and assessment information.
- Tradewinds — Department marketplace for readily awardable AI, data, and analytics capabilities.
- Platform One Iron Bank — Vetted repository of assessed containers for Department deployment.
- OMB M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government — Performance-based acquisition, portability, pricing transparency, open interfaces, and anti-lock-in provisions.
- Department of Defense Small Business Strategy — Documents the decline in small-business participation despite higher aggregate spending.
- FAR 19.502-4: Partial Set-Asides of Multiple-Award Contracts — Small-business participation mechanisms within multiple-award structures.
- AI SAFE² Framework — CSI’s operational framework for agentic AI security, runtime governance, and evidence generation.
- AI Governance Maturity Model: Six Frameworks Compared — CSI analysis of governance maturity, enforcement, sovereignty, and agentic readiness.
Internal Linking Notes for WordPress
The article already contains contextual internal hyperlinks. Preserve the following anchor relationships when pasting into WordPress:
