The Rebaseline Trap
The Navy signed off on a design review for an aircraft upgrade with no flight test until 2029. Call that timeline a plan and you have already lost the argument.
The Rebaseline Trap
The Navy signed off on a design review for an aircraft upgrade with no flight test until 2029. Call that timeline a plan and you have already lost the argument.
MD Marine Electric | The Current Conversation
The E-2D Advanced Hawkeye Block II passed its critical design review this month.¹ Flight tests are scheduled for Fiscal Year 2029.¹ That gap, design review to first flight, is three years. Nobody in the acquisition chain has called that a problem. It has been called a foundation.
Northrop Grumman's modification "delivers the software foundation for rapid capability insertion," according to the Portfolio Acquisition Executive Aviation statement announcing the milestone.¹ The upgrade, built on the next evolution of Delta System Software Configuration 6 (DSSC-6), is meant to let the Navy field new capability on the Hawkeye faster than it has in the past.¹ That is the sales pitch. It is also, on its face, a three-year commitment to build the plumbing before the water runs.
Readers of this newsletter have seen this shape before. We have named it the Modernization Mirage: the promise of transformational capability that consistently arrives late, over cost, or after the platform it was meant to save has already been retired. The Hawkeye Block II is not that, not yet. It is something upstream of the mirage, and worse in one specific way. Call it the Rebaseline Trap: the practice of treating a schedule slip as a program milestone, so that "on track" comes to mean nothing more than "matching the revised plan," no matter how many times the plan has moved.
The Baseline That Keeps Moving
A critical design review is supposed to answer one question: is the design mature enough to build against. Passing CDR means the government and the contractor agree the drawings, the interfaces, and the software architecture are stable enough to commit hardware and labor to them. It is a checkpoint, not a finish line.
What the source material does not say is whether this CDR happened on the original schedule, on a rebaselined schedule, or on a second or third rebaseline. The Navy's own language, "preparing the Portfolio Acquisition Executive Aviation for flight tests sometime in Fiscal Year 2029,"¹ is instructive precisely because of its vagueness. "Sometime" is not a program date. It is a placeholder that lets the milestone count as achieved without anyone being on record for when the next one actually lands.
This is the mechanism of the Rebaseline Trap. Every program has a baseline: the dates, costs, and performance thresholds against which progress gets measured. When a program starts slipping, the honest move is to report the slip against the original baseline and eat the bad headline. The trap opens when, instead, the baseline itself gets redrawn around the new, later date. From that point forward, the program is "on schedule" again, because the schedule has been rewritten to match wherever the program actually is. GAO has documented this exact dynamic across Navy shipbuilding, where fewer than 40 percent of ships finish their maintenance availabilities on time even when dock space is available.² The ships are not late against a fixed standard. They are "late" against a standard that has already absorbed the lateness.
There is no evidence in the public record that this is what happened with Block II. There is also no evidence that it did not. That absence is the point: a program can pass a design review and still be years behind an original commitment, and the press release will read identically either way.
DSSC-6 and the Architecture of Deferred Capability
Trade-level specificity matters here, because "software upgrade" is doing a lot of work in that Navy statement, and it is worth being precise about what DSSC-6 actually is.
The E-2D's mission systems run on a common software baseline shared across the fleet, upgraded in discrete "Delta System Software Configurations." Each DSSC is a coordinated release: radar processing, identification friend-or-foe logic, data links, and the operator display suite all have to move together, because the Hawkeye's entire value proposition is as a networked sensor node, not a standalone aircraft. You cannot patch the radar software independently of the data link software without breaking the thing that makes the aircraft useful, which is that five different platforms are reading the same tactical picture off the same feed in something close to real time.
Block II, per the PAE, is explicitly architectural: it is meant to be "the software foundation for rapid capability insertion" on top of DSSC-6, not a new capability itself.¹ That is a meaningful distinction for anyone who has worked a shipboard combat system upgrade. Building the foundation is the part of the job that looks like nothing to an outside observer and eats the majority of the schedule anyway. Cable runs get pulled before the equipment that uses them exists. Interface control documents get finalized before either side of the interface is fully built. Software architecture gets locked down years before the capability that will run on it is even funded. The visible milestone, first flight of new capability, sits at the far end of a long chain of invisible groundwork, and every one of those groundwork steps is a place where a rebaseline can happen quietly.
This is not a criticism of the engineering choice. Building extensible architecture before bolting on features is often the right call; it is how you avoid the alternative failure mode, where every new sensor gets welded onto legacy code with no plan for what comes next. The problem is procedural, not technical: the Navy's public accounting treats "CDR passed" and "flight test in 2029" as two data points on a straight line, when the only thing publicly verifiable is that the first point happened. The straight line is an assumption, and assumptions are exactly what a rebaseline rewrites without anyone noticing.
The Fleet Expansion Sits on Top of the Slip
The Navy is not just modernizing the Hawkeye. It is planning to expand the fleet.¹ That detail changes the stakes of the schedule question from academic to operational.
Expanding a fleet of airborne early warning aircraft while the software baseline those aircraft depend on is still three years from flight test means the Navy is buying more airframes against a capability baseline that has not been validated in the air. If DSSC-6 Block II slips again, and if the Rebaseline Trap absorbs that slip into a new "sometime" date rather than a public schedule miss, the fleet expansion proceeds on the assumption that the foundation will be there when the new aircraft need it. That is a bet, not a plan, and it is a bet the public record does not currently let anyone size.
This is where the concept connects to a pattern this newsletter has tracked on the surface fleet: the $1.84 billion the Navy spent modernizing four Ticonderoga-class cruisers that were decommissioned before the modernization ever deployed operationally.³ That was not a software program. It was hull, mechanical, and electrical work. But the failure mode was identical in structure: capital committed against a schedule that assumed the modernization would land before the platform's service life ran out, and the assumption was wrong by enough to waste $1.84 billion outright.³ Nobody rebaselined those cruisers into relevance. They rebaselined them into the scrap queue.
The E-2D fleet expansion is the same shape of bet, aimed the other direction. Instead of modernizing hulls that might age out before the upgrade lands, the Navy is buying new airframes that will need an upgrade that has not yet flown. Both bets fail the same way if the schedule slips past the point where the platform's operational window closes. The only difference is which side of the timeline the risk sits on.
The Inspection Discipline That Should Be Watching This
There is a second, harder-edged connection to make, and it runs through inspection regimes rather than schedules.
GAO-25-106749 found that in 2020, Navy leadership changed procedures to reduce inspections by almost 50 percent, specifically to maintain working relationships with contractors.⁴ That finding was about ship maintenance, not aircraft software, but the underlying incentive structure is not platform-specific. It is an incentive structure that exists anywhere a program office has to certify a contractor's progress and also has to keep working with that contractor for years afterward. The QAR Vacuum, the gap left when qualified inspection staff are cut or sidelined, exists precisely because rigorous inspection produces friction, and friction produces bad optics for a relationship both sides need to survive.
A critical design review is, functionally, an inspection milestone. It exists to catch immature designs before the government commits production dollars to them. If the incentive to protect the contractor relationship shaped inspection rigor on ship maintenance enough for GAO to document a nearly 50 percent reduction,⁴ there is no structural reason to assume aviation software programs are immune to the same pressure. The public record does not show whether Block II's CDR was scrutinized at full rigor or whether it benefited from the same soft-pedaling GAO found elsewhere in the Navy's acquisition culture. [VERIFY: whether the E-2D Block II CDR included independent technical review beyond the PAE's own statement, and whether any GAO or DoD Inspector General review has assessed the DSSC-6 Block II schedule specifically.]
That is not an accusation. It is a gap, and gaps in a program with a three-year runway to first flight are exactly where a rebaseline hides.
For NAVSEA Program Offices
This one is for the program offices that will write the next status report on Block II, and every report after it.
The test is simple, and it is the same test that should apply to every "on track" claim in Navy acquisition: on track against what date, set when, by whom. If the answer to that question requires checking a revision history, the program is not on track. It is being managed to a moving target, and the public, Congress, and the fleet that will fly this aircraft in combat all deserve to know which target they are looking at.
The CBO's December 2025 ship repair analysis exists because Congress got tired of program offices reporting progress against baselines nobody outside the program could verify.⁵ Aviation acquisition is not exempt from that same scrutiny simply because the platform flies instead of floats. A program office that reports "CDR passed, flight test FY29" without disclosing how many times that FY29 date has already moved is not informing oversight. It is managing it.
The alternative is not complicated. Publish the baseline history alongside the milestone. Show the original schedule, show every rebaseline, show the date of each one. If the schedule has held, that transparency costs nothing and buys credibility. If it has not held, the fleet expansion currently being planned on top of this upgrade deserves to know that before more airframes get bought against a foundation that keeps getting poured later than promised.
A design review is not a delivery. Start reporting the difference.
References
- USNI News, "E-2D Advanced Hawkeye Block II Passes Critical Design Review as Navy Plans to Expand Fleet," August 18, 2026.
- GAO finding on Navy ship maintenance availabilities: fewer than 40 percent of ships finish on time even with dock space available.
- Verified figure: $1.84 billion spent modernizing four Ticonderoga class cruisers decommissioned before deploying the modernization.
- GAO-25-106749: Navy leadership changed procedures in 2020 to reduce inspections by almost 50 percent, specifically to maintain working relationships with contractors.
- Congressional Budget Office, December 2025 ship repair analysis.
