What CBM+ actually requires
DoDI 4151.22, dated August 14, 2020, establishes CBM+ as a primary strategy for cost-effective life-cycle sustainment. Its policy conditions matter: integration in new programs follows reliability-centered maintenance findings about availability or cost benefit; incorporation into current systems depends on technical feasibility, improved availability, and cost-effectiveness. The instruction superseded the 2012 issuance.
The Defense Department Inspector General's June 2022 audit describes CBM+ as the broader strategy and predictive maintenance as a technique for anticipating component failure. Neither supports defining the “plus” as an AI layer or assuming every maintenance task must replace a fixed interval with a machine-learning prediction.
That distinction protects the business case. Some problems may justify sophisticated analytics; others may be addressed through better inspection information, conventional analysis, improved records, or a different maintenance process. The relevant comparison is improved sustainment against the cost and risk of the change, within the applicable maintenance and engineering authorities.
The official November 2024 guidebook presentation page confirms an August 2024 CBM+ guidebook emphasizing life-cycle integration and data capabilities. The applicable instruction and program requirements determine the obligations for a specific use.
The F-35 case needs its full chronology
GAO's 2020 ALIS review documented inaccurate or missing data, usability problems, and uncertainty about the redesign. It also identified a need to connect logistics-system performance with fleet outcomes. Those findings support examining the data and workflow together; they do not establish that all the problems arose from one contracting decision.
By April 2022, GAO reported that the program had moved from a plan to replace ALIS toward incremental improvements, including new hardware, software changes, and improved government access to data, with an eventual ODIN name. Describing that history as a completed, entirely new government-owned architecture would skip an important change in the program's approach.
Progress since then also belongs in the account. GAO's current recommendation record says that in April 2026 the department supplied evidence of an ODIN performance-measurement process connecting system measures to user needs and fleet performance. GAO closed the relevant recommendations as implemented. That is a documented management improvement, not proof that every logistics or readiness problem has been eliminated.
The lesson for another program is to separate several milestones: installing hardware, improving software, obtaining usable data, changing a maintenance workflow, and demonstrating a better outcome. They can advance at different rates. A dashboard should not collapse them into a single “modernized” status that prevents leaders from seeing what remains unfinished.
Build the data chain around a maintenance decision
“More fleet data” is too broad a starting requirement. Begin with the component or maintenance decision under consideration. Determine which observations could inform it, how the actual outcome will be recorded, and whether the records can be joined without losing their meaning.
A sensor reading without the relevant configuration or operating context may be difficult to interpret. A maintenance record showing that a part was removed does not necessarily establish that it had failed. If the program cannot distinguish an inspection finding, a precautionary removal, and a confirmed defect, it may train or evaluate an analytics tool against an unreliable outcome label.
This was a concrete issue in the 2022 inspector-general audit, which identified challenges including usable data, algorithms, and distinguishing parts removed because of forecasts. The audit describes that period; it is not a claim that every current program has the same maturity or that none has improved since then.
The engineering response should be targeted. Identify the information needed for the chosen decision, assess the quality of existing records, and determine whether a bounded collection effort can close the gap. Digitizing an entire archive may be valuable in some circumstances, but it should not become an unexplained prerequisite for every useful pilot.
Separate data rights, delivery, and practical access
A program can possess files it cannot readily use, or have a contractual right that has not been translated into a usable delivery. Those are different problems. Before negotiations, distinguish the information required, the permitted uses, the delivery mechanism, the format, and the supporting documentation.
The contracting and legal teams should examine the actual terms governing sensor output, maintenance history, software, and any trained model. Do not assume that existing technical-data rules exclude every sensor stream, that all data belong to the contractor, or that a government purchase automatically confers every desired right. The applicable instrument and circumstances determine the answer.
For planning purposes, ask what the program needs to do: operate an existing service, verify its output, bring in another evaluator, change suppliers, or sustain the capability itself. Those uses may require different access and delivery arrangements. Naming them makes the negotiation more concrete than a general demand to “own the data.”
A contract change may be necessary, but it is not the only possible remedy. An existing delivery obligation may need enforcement or clarification. A format problem may need engineering work. A narrowly scoped service may meet the requirement without transferring every proprietary component. Compare these alternatives against the intended sustainment model and the cost of future dependence.
Test whether the recommendation changes useful work
A predictive model can be statistically promising and operationally unhelpful. An alert delivered after the relevant maintenance window may provide little benefit. A warning with no available inspection capacity or replacement part may create work without improving availability. These are implementation risks to test, not findings about every deployed system.
A hypothetical pilot makes the issue concrete. An analytics tool flags a component for inspection. The maintainer needs to know what approved action follows, where the supporting information appears, and how to record the finding. The program then needs to determine whether the alert led to a useful intervention, an unnecessary inspection, or a result that remains uncertain. Simply counting the alert as a success would obscure all three possibilities.
Evaluation should compare the proposed process with the existing one under suitable conditions. Include the staff effort, time to act, unnecessary interventions, missed problems, and any effect on equipment availability. Avoid declaring a failure “prevented” when the evidence only shows that a part was replaced. The analysis must explain what supports the claimed benefit and what remains an estimate.
The maintenance authority should retain control over changes to approved procedures. An analytics recommendation is not permission for software developers to alter inspection or replacement rules on their own.
Model governance belongs in the sustainment plan
Where AI is used, its release and support process should be explicit. Identify the evaluated configuration, relevant data, intended use, known limitations, and owner of continued performance assessment. Keep model changes connected to the maintenance process they inform.
A changed fleet configuration, new sensor, or revised recordkeeping practice can affect an earlier evaluation even if the model itself is unchanged. Conversely, a supplier's model update may change recommendations without any alteration to the aircraft or vehicle. The program needs a proportionate way to determine whether the previous evidence still applies.
These are recommended governance practices, not a claim that every existing logistics contract contains them. Requirements should be tailored and placed in the appropriate program documents and agreements. Where a team lacks the resources to monitor and sustain an AI component, a simpler method or narrower use may be the more credible initial choice.
Fund the handoff from pilot to routine maintenance
A pilot often has unusually close attention from its developers. Routine operation cannot depend on that attention continuing indefinitely. Before expanding use, determine who maintains the data interface, resolves a disputed recommendation, supports users, and funds the work after the demonstration ends.
The receiving organization should also be able to explain why the capability remains worth operating. A reduction in one category of maintenance effort may be offset by additional data preparation, inspections, licensing, or technical support. A sound business case includes those costs rather than crediting the analytics product with every favorable change in readiness.
There is room for a staged commitment. A program can retain an approved maintenance approach while evaluating a limited analytic use, improve the records needed to judge that use, and expand only when the evidence warrants it. That path may be more useful than promising an immediate fleet-wide transformation or withholding all improvement until the data are perfect.
Questions for the next program review
- Which maintenance decision are we improving? Name its current process, responsible authority, and consequence of error.
- Can we connect observations to credible outcomes? Identify missing context and the work needed to make the records usable.
- What can we actually access and use? Separate legal rights, delivery obligations, technical formats, and supplier support.
- Where will the recommendation reach the maintainer? Include approved action, feedback, and handling of disagreement.
- What evidence would justify expansion or stopping? Compare the proposed process with its baseline and include support costs.
- Who owns the capability after the pilot? Fund data upkeep, configuration review, user support, and outcome measurement.
A negative answer identifies work or a reason to narrow the proposal; it does not automatically rule out every form of useful analytics. The immediate task is to identify the limiting dependency and decide whether fixing it is worth the expected benefit. That is how a program turns the CBM+ objective into a supportable maintenance capability.
Sources and further reading
- DoDI 4151.22, August 14, 2020: CBM+ policy and conditions
- DODIG-2022-103: implementation audit and data challenges
- GAO-20-316: ALIS review and updated recommendation status
- GAO-22-105128: incremental ALIS/ODIN modernization
- Official August 2024 guidebook update presentation
Spartan X brings technical leadership, program experience, and AI integration practices to the connection between usable data and executable work. In sustainment, that means examining the access, architecture, and operational handoffs that determine whether an analytical insight can become a maintenance decision the organization can support.
