The DoW AI Strategy Is an Integration Problem

The Department of War AI strategy reads differently once engineers start asking how to land it on real systems.

The official AI-first enterprise strategy page describes seven Pace-Setting Projects and the push to make the department an AI-first enterprise. The public message is about speed, decision advantage, and scale across warfighting, intelligence, and enterprise missions. Those are strategic aims. They are not yet an integration plan.

The engineering reality underneath is harder. AI has to be integrated into mission threads rather than bolted onto them. A model that scores targets, summarizes intelligence, controls an unmanned system, recommends a plan, or assists a maintainer has to receive the right data, at the right time, with the right authority limits. It also has to leave evidence.

This is not a model-weights problem. The model matters, but the surrounding system often matters more. Data provisioning, labeling, lineage, logging, monitoring, drift detection, feedback, and human review all decide whether AI behavior can be trusted. The program must also decide which decisions are delegated, which are assisted, and which remain outside the AI boundary.

The data path is usually the first bottleneck. Mission data lives in different systems, networks, formats, and classification levels. Some of it is stale. Some of it is sensitive. Some of it was collected for a different purpose. AI cannot fix those issues after deployment. It will reflect them.

Verification is the next bottleneck. A conventional software test can check deterministic behavior. AI systems often need scenario coverage, statistical evidence, adversarial testing, runtime monitoring, and clear fallback behavior. In a weapon or command-and-control context, those tests must connect to mission risk, not only model accuracy.

Authority is just as important. If an AI system makes a recommendation, who can accept it? If it acts autonomously, what bounds apply? If it drifts, who notices? If it fails quietly, what evidence shows why? Those are interface, timing, and assurance questions.

Fielding AI inside a weapon or command-and-control system also changes sustainment. Models update. Data changes. Threat behavior changes. The authorization evidence has to keep pace without pretending every update is a brand-new program. That requires MLOps tooling engineered for the Risk Management Framework, not a commercial notebook workflow copied into a secure lab.

The strategy also depends on talent that can bridge model work and mission-system work. Data scientists may know training and evaluation. Mission engineers may know the operational thread. Cyber teams may know the boundary. The program needs all three voices in the architecture before the first fielded workflow depends on a model.

The first fielded uses should be chosen with that in mind. A narrow, observable workflow with clear human authority may teach more than an ambitious agent tied to a weak data path. Early wins should build the evidence system that later, harder use cases will need.

Those are the places Polyrhythm works: interfaces, data paths, test strategy, and evidence chains. The AI strategy is valuable because it raises the priority. It will become real only where programs make AI useful inside the mission system instead of decorative beside it.