The DOT&E report was released in March 2026, and the F-35 program is covered on pages 30–36.
Here is a slightly shorter analysis than the report itself:
The DOT&E report paints a picture of a program that is not merely behind schedule, but has become bogged down in a disconnect between production, software development, testing, and operational validation. We continue to produce aircraft, deliver them, modify them, and pile on interim standards, but without succeeding in transforming this industrial flow into a clearly validated combat capability. That, in essence, is the central problem. The F-35 is no longer in a situation where a one-off delay would temporarily prevent the arrival of a mature version; it is in a situation where the very way the program operates perpetuates the delay.
Where do we stand today? The harshest reality is that, by the end of FY25, no new combat capability had actually been put into service. The latest TR-2 version, 30R08, which was supposed to properly conclude this cycle, was unsuitable for a dedicated operational test for most of the year. As for TR-3, which was initially intended primarily as a hardware foundation to support Block 4, it failed to achieve a sufficient level of stability. We are therefore in a paradoxical situation: the old standard is not properly finalized, the transitional standard is not truly mature, and the future standard—Block 4 in the full sense—is not progressing at the necessary pace because the program’s energy is being absorbed by the stabilization of the transition itself.
This is the key point to understand: TR-3 appears, in theory, relatively minor when compared to the overall ambition of Block 4. On the software side, it is largely a rehost, and thus not a doctrinal or functional leap of the same magnitude as the Block 4 capabilities themselves. On the hardware side, the focus is on infrastructure: new computers, memory, displays, and then, looking ahead, the more complex issue of the ECU/PTMU and power generation. In other words, TR-3 is supposed to prepare the groundwork, not yet to truly expand it. Yet the program is already stalling on this groundwork. This means that the real difficulty of Block 4 is still partly obscured. As long as we’re struggling to stabilize the foundation, we don’t yet fully see the difficulty that will arise in integrating the more ambitious capabilities themselves. This is why the situation is more serious than a simple transition delay: the program hasn’t yet hit the main mountain, but is already stumbling on the access path.
How did we get here? First, through a clear underestimation of the complexity of integration. For a long time, the program seemed to operate under the assumption that one could maintain an agile development approach within a system extraordinarily burdened by cross-dependencies: mission software, hardware architecture, sensors, data fusion, simulation, flight testing, weapons integration, cybersecurity, and logistical support. In such a system, a modification that seems reasonable in isolation can trigger a cascade of side effects. The report’s data is highly revealing: the number of iterations is skyrocketing, deadlines are slipping, and even capabilities that previously functioned correctly sometimes cease to work properly in later versions. This is a sign of a poorly managed system in decline, and thus of a development architecture that fails to contain its own complexity.
Furthermore, the program committed what has almost become a classic sin of major Western programs: it allowed production and the political-industrial logic to outpace actual technical maturity. We accept aircraft, we organize temporary solutions, we stockpile, we retrofit, we trim capabilities to make the situation manageable in the short term, but this does not reduce overall complexity; it merely shifts it over time and often increases it. The TR-3 delivered with truncated software speaks volumes. It is a way to avoid a sudden halt, but it is also a way of implicitly acknowledging that we do not yet fully understand the system we are producing.
There is also a second layer of the problem: the test facilities themselves are inadequate or behind schedule. A program this complex cannot be turned around if its testing infrastructure is inadequate. Yet this is precisely what DOT&E states: a lack of properly configured OT aircraft, insufficient instrumentation, a fragmented schedule, an immature JSE, an insufficient number of FIABs, incomplete cyber tests, and dynamic RCS measurements that have not been carried out. This means that the program is not only struggling to produce a stable version; it is also struggling to quickly and clearly determine what actually works, under what conditions, and at what level of robustness. This leads to a vicious cycle: unstable development, delayed testing, late discovery of defects, late fixes, new regressions, and new iterations.
What should have been done? Ideally, a much stricter discipline should have been adopted earlier regarding production, hardware transition, and ramp-up. In short: freeze more, sequence more, and reject for longer the fiction that everything could progress simultaneously. TR-3 should have been treated as a genuine platform stabilization program, with strict release criteria, rather than as a mere technical milestone assumed to be quickly surmountable. The program should also have been equipped earlier with testing resources commensurate with its ambition: more OT aircraft, a JSE/FIAB architecture designed as a central pillar rather than an add-on, better tools for monitoring real-world operational instabilities, and above all, an absolute priority given to software robustness before piling on new features.
More fundamentally, it should have been acknowledged that an aircraft already extremely ambitious in its initial version is not a platform that can be extended indefinitely without increasing complexity costs. The program’s implicit dream was to combine mass production, continuous software evolution, hardware transition, weapons integration, engine modernization, and mission expansion—all under the banner of agility. This was likely too ambitious. A more realistic approach would have been to accept clearer milestones, with genuine technical milestones before moving on to a new phase.
What can be done now? First, we must likely abandon any illusion of a quick and clean catch-up. The program will not recover through mere extra effort or a few better-targeted patches. It must be viewed as engaged in a phase of structural recovery, not just incremental correction. This requires refocusing priorities. The top priority must be the genuine stabilization of a usable, instrumented, testable, and sustainable standard, even if this means temporarily setting aside some of the rhetoric about the speed of delivery for future capabilities. Until the foundation is stabilized, Block 4 will remain, in part, a catalog of promises rather than a credible roadmap.
Next, the various projects likely need to be more clearly separated. The program would be wise to mentally and industrially distinguish at least four issues: the stability of the mission software, OT/JSE validation, the TR-3 hardware transition, and the more extensive energy and propulsion modernization, particularly regarding the ECU/PTMU and power generation. As long as these issues remain politically lumped together under a single narrative of continuous progress, each masks the difficulty of the other. In particular, on one essential point: as long as TR-3 is not stabilized, the real difficulty of Block 4 remains partially hidden; and as long as the fundamental power and thermal issues are not properly resolved, the long-term hardware ambitions also remain underestimated.
We must also accept that part of the problem will not be solved by software alone. The F-35 program has often given the impression that almost any difficulty could be absorbed through software iterations. Yet when we deal with computing power, thermal dissipation, power supply, and equipment growth margins, we leave the realm of elegant fixes. We enter the realm of physical trade-offs. And these trade-offs are slow, costly, industrial, and sometimes doctrinal. The program will not get out of this mess until it explicitly addresses this reality.
When will we get out of this? We need to distinguish between three levels. We can get out of the worst of it—that is, return to a TR-3 standard that is roughly stable and sufficiently testable—relatively soon on the scale of a major program, likely within a few years if priorities are tightened and testing resources actually follow through. On the other hand, getting out of the current gray area—where we’re delivering but without fully validated capabilities—will require more than just a simple transition to 40R03: it will take a coherent sequence of validation, correction, and consolidation. Finally, truly breaking out—that is, having a mature, credible, and sustainably viable Block 4 backed by a stable power/thermal solution—will take significantly longer. The danger lies precisely in declaring that we’ve escaped the mess as soon as an intermediate milestone appears to have been crossed, when in reality the core of the difficulty has simply shifted elsewhere.
In summary, my view is as follows. The F-35 program is not merely facing a version delay; it is in a crisis of technical governance of complexity. TR-3 was supposed to be a transition. It has become a revealing indicator. It shows that the architecture for development, testing, and industrialization is already struggling to absorb a preparatory evolution, which requires us to view the stated ambitions for Block 4 itself with great caution. The program will likely eventually regain some form of stability, because it has considerable industrial, budgetary, and political backing. But it will not quickly regain the credibility of a program that progresses in a linear fashion. The way out of the crisis will come less from an acceleration than from a re-learning of technical discipline: stabilize, test properly, sequence, and only then add.
www.airandspaceforces.com
aviationweek.com
