What CBM+ Actually Requires
The DoD Condition-Based Maintenance Plus policy — formalized through the OSD CBM+ Guidebook and governed by DoDI 4151.22 (Condition-Based Maintenance Plus for Materiel) — directs that maintenance decisions for applicable systems transition from time-based schedules ("inspect every 100 flight hours") to condition-based ones ("inspect when sensor data indicates wear approaching a threshold"). The "plus" is the AI layer: models that learn from fleet-level sensor histories to predict when a component will fail before it does.
This is a meaningful departure from how military sustainment has operated for decades. Fixed-interval maintenance is operationally predictable and supports depot planning cycles. Condition-based maintenance requires real-time visibility into system health, historical sensor data across the fleet to train and calibrate models, feedback loops that incorporate actual maintenance outcomes to improve prediction accuracy over time, and algorithms that can distinguish mission-relevant degradation from sensor noise.
Each of those requirements translates to a specific technical and contractual dependency that most legacy platform programs were not designed to fulfill.
The F-35 Case: ALIS to ODIN
The clearest public case study is the F-35 Joint Program Office's (JPO) transition from the Autonomic Logistics Information System (ALIS) to the Operational Data Integrated Network (ODIN). ALIS was designed to aggregate maintenance data and automate logistics workflows for F-35 fleets globally. Congressional testimony, DOT&E Annual Reports from FY2020 through FY2023, and GAO reviews documented its persistent problems: data quality failures that required manual corrections, cybersecurity vulnerabilities stemming from the system's distributed architecture across partner nations, and maintenance workflow integration that was more theoretical than operational for front-line maintainers.
The JPO's solution — ODIN — was a fundamental redesign, not an upgrade patch. ODIN moved the data architecture to a government-owned cloud environment, changed data ownership structures to give the government more direct access to fleet health data, and was designed from the ground up to support AI-enabled analytics. The JPO began initial ODIN hardware deployment in mid-2021, completing the first phase — delivery of hardware kits to F-35 bases in the United States and partner nations — in January 2022. The software fielding layer, which delivers the cloud-based data and analytics components, was originally planned for FY2023 but was delayed; first squadron deliveries of the software were pushed to 2025, with the transition still ongoing.
The lesson is not that ALIS failed technically because the models were wrong. ALIS failed because the data it generated was unreliable, the architecture made government access to that data structurally difficult, and the contract structure gave Lockheed Martin extensive control over data the government needed to operate the predictive analytics component. ODIN corrects those structural problems first, with the AI analytics built on top of a data foundation the government actually controls.
That sequencing — data governance first, AI second — is the lesson other program offices are still learning.
Where Other Programs Are Getting Stuck
The F-35 case attracted sustained GAO and congressional scrutiny, which forced a resolution. Most programs don't get that external pressure until readiness has already degraded. The structural challenges ODIN was designed to address are common across the DoD portfolio:
Sensor data is often proprietary or inaccessible. Many major weapon systems have onboard health and usage monitoring systems (HUMS) whose raw output is controlled by the OEM. The government's maintenance data rights under DFARS and FAR Part 27 were written for technical data packages — drawings, specifications, software source code — not continuous sensor streams and the trained models that interpret them. A program office that doesn't establish data access rights to HUMS output at contract award will face extensive negotiation or vendor dependency when trying to run its own predictive analytics later.
Fleet-level training data doesn't exist in useful form. AI predictive maintenance models need historical failure data — sensor states at the time of failure, maintenance records documenting the actual defect, and labeling that connects failure modes to precursor sensor patterns. Legacy platforms that predate digital maintenance recordkeeping have this history in paper or semi-structured digital records, if at all. Even platforms with electronic maintenance records often have inconsistent data entry that produces training sets too noisy for reliable model training.
Model governance is undefined. CBM+ introduces a class of decisions — when to schedule maintenance, what to inspect — that will increasingly be driven by model outputs rather than fixed schedules. DoD's AI governance requirements under the CDAO's Responsible AI framework require documented model governance including data provenance, version control, performance monitoring, and human oversight thresholds. Most logistics system contracts have not been updated to include model governance specifications, which means programs will face a reclassification and review burden later if they haven't planned for it.
Depot and field integration is an afterthought. The maintenance decisions that CBM+ informs are executed by depot maintainers, field-level technicians, and logistics planners — not software engineers. Predictive analytics outputs need to reach those users in a form they can act on, integrated into their existing workflows in organic maintenance management systems. Programs that build the predictive model without designing the workflow integration have analytics that generate alerts no one reads.
What the NDAA and Policy Environment Is Requiring
DoDI 4151.22 and successive NDAAs have progressively strengthened the CBM+ mandate. OSD has issued updated guidance through the CBM+ Guidebook (August 2024 edition) that covers data infrastructure requirements in more specificity than previous versions, including guidance on government data rights for maintenance-relevant data, model validation requirements, and integration with Contractor Logistics Support (CLS) arrangements.
The policy direction is clear: CBM+ is not optional for new programs, and existing programs with significant CLS relationships should be renegotiating to establish CBM+ data access rights at each major re-compete. Congressional interest in sustainment readiness has produced a pattern of reporting requirements across recent NDAAs — the number of major programs that lack CBM+ implementation plans is now a metric congressional staff track alongside readiness rates and depot capacity.
Program Executive Offices that have not conducted a CBM+ readiness assessment — mapping data access rights, sensor architecture, maintenance records digitization, and model governance frameworks against each major platform's current contract structure — are already behind and may face unfavorable findings when this reporting surfaces the gaps.
The Contracting Work That Isn't Happening
The most consequential work for CBM+ adoption is not algorithm development. It is the contract renegotiation required to establish government data rights to sensor output and maintenance history, CLS contract modifications that require OEM cooperation with government predictive analytics programs, data format and API standards for health monitoring data that make fleet data interoperable across depot and field systems, and model governance provisions in new logistics contracts that specify version control, performance thresholds, retraining triggers, and human-in-the-loop requirements.
None of that is glamorous acquisition work, and none of it has the visibility of a new capability demonstration. But without it, AI-enabled maintenance analytics will remain bounded to programs with favorable legacy data rights and motivated prime contractors — rather than scaling to the depot system as policy intends.
The programs that will get CBM+ right are not the ones that sign contracts with the best predictive analytics vendors. They're the ones that establish the data infrastructure, access rights, and governance framework that any analytics capability needs to operate.
Practical Assessment Checklist
Before a program office can determine whether AI-enabled predictive maintenance is achievable with current contract structure, it needs answers to these questions:
- Does the government hold data rights to raw HUMS/sensor output from the prime contractor, or is that data licensed with use restrictions?
- Are maintenance history records in a structured digital format sufficient for ML training datasets, or do they require remediation?
- Is there a data standard or API specification for sensor output that would make that data interoperable with government-owned analytics platforms?
- Does the current CLS arrangement require the prime to cooperate with government predictive analytics programs, or is cooperation voluntary?
- Has a model governance framework been specified for any AI components that inform maintenance scheduling decisions?
- Where do predictive alerts need to surface in maintainers' existing workflows, and has that integration been designed?
Programs that cannot answer those questions affirmatively have foundational work before the analytics investment makes sense.
Sources and further reading
- DoD CBM+ Guidebook, OSD Materiel Readiness (August 2024 edition)
- DoD Instruction 4151.22, Condition-Based Maintenance Plus for Materiel (issued October 2012, updated January 2018)
- GAO, *F-35 Aircraft: DOD and the Military Services Need to Reassess the Future Sustainment Strategy*, GAO-23-105341 (September 2023)
- DOT&E Annual Report FY2023, F-35 section
- DFARS Subpart 227.71–227.72, Technical Data and Computer Software rights
- DoD Responsible AI Strategy and Implementation Pathway, CDAO (June 2022)
- DoD Data Strategy, OSD Chief Data Officer (October 2020)
Spartan X works with defense program offices on the data architecture and model governance problems that determine whether AI-enabled sustainment actually reaches the field. The pattern we consistently see is programs that have strong analytics ambitions but fragile data foundations — and the corrective work is less about algorithm selection than about data rights, access architecture, and the contract provisions that govern both.
