By Robbin Laird
For four decades, the U.S. Navy trained a generation of acoustic sensor operators who could look at a waterfall display and, from pattern and instinct built over a career, call a submarine contact with a confidence no algorithm could match. That generation is retiring, not by choice, but by the calendar. And with it goes a body of tacit knowledge that no requirements document ever fully captured.
Lockheed Martin’s rapid prototyping team for the Navy helicopter program has spent the past three years building a answer to that problem, not as a future concept, but as a fielded capability already flying against live targets in fleet exercises. I sat down with Rob Ziemba Senior Manager, Future Capabilities and Chip Whitfield Principal Systems Engineer/Maritime Military Aviation Advisor to talk through what they’ve built, how they built it, and why the way they built it may matter as much as the technology itself.
From Artisan to Algorithm
The starting point, Whitfield explained, was demographic as much as technical. The Cold War generation of anti-submarine warfare (ASW) sensor operators, the people who could read a spectrogram the way a sommelier reads a wine list, is aging out of the workforce, and the operational tempo of the last two decades hasn’t replaced that expertise. The Navy and the joint force spent a generation focused on the Middle East, where submarines were not the primary threat, and the passive-acoustic interpretation skill set atrophied as a result.
“What could we do to capture what remains?” Whitfield asked, describing the origin of the effort. He pointed to Chris Moon, a Navy weapons school instructor who has trained nearly every MH-60R sensor operator for forty years, as the kind of expertise the team set out to preserve. “How do we get Chris Moon’s brain in a box? That’s where this started.”
The “box” is SensorMax, a spectrum foundation model and AI inference engine that Lockheed Martin developed to do something narrower and more useful than the large, generically-trained AI models most people associate with the term. Whitfield’s analogy is a hunting dog. Conventional supervised-learning models are like a bloodhound raised from birth and trained over months to chase one specific thing; if the target changes, you need a new dog, raised and trained all over again.
SensorMax instead takes the “bloodhound you’ve already got” and retrains it in the field, in hours or minutes rather than months, to recognize a new signature. The model doesn’t need to be rebuilt from scratch for each new target. It needs to be told, in effect, what the new target smells like, and it adapts.
That distinction retraining at the edge rather than rebuilding in a lab is the technical core of the program. But both Ziemba and Whitfield were emphatic that the more consequential change is organizational: who gets to touch the software, and how fast.
From 37 Minutes to Real Time
The team’s account of SensorMax’s evolution is itself a case study in what rapid, iterative fielding looks like when a program is unconstrained by a traditional five-to-seven-year acquisition cycle.
The technology’s first real test came at Resolute Hunter in 2024, against a training target. That was where I first met Whitfield and discussed the initial capability during my visit to NAWDC and with the MISR group. The MISR officers which stands for Maritime ISR officers are the gold standard for the Navy in terms of learning to turn diverse data streams into reliable information for targeting decisions.
At the Resolute Hunter exercise, the MISR team had begun inviting external participants to introduce new payloads directly into the training environment rather than waiting on traditional acquisition timelines. Lockheed Martin was one of the participants, working with NAWDC on a sensor payload for the Romeo and Sierra helicopters designed to expand the surveillance and reconnaissance picture available to the fleet.
At that point, updating the model required physically landing the helicopter, walking the data into a secure room by hand on a data locker, retraining the model, and carrying it back out to the aircraft. Whitfield said the team got that cycle down to 37 minutes with rotors still turning.
By the multinational UNITAS maritime exercise, the team had moved the process onto a mesh network, eliminating the need for the aircraft to land before transferring its data. During a subsequent exercise in May involving what Ziemba described only as “another target,” however, the team discovered that the network pathway remained inadequate. Between one flight and the next, Lockheed Martin software engineers rewrote the data pipeline overnight. The revised architecture allowed operators to access the helicopter’s mission computer, label sensor data in real time, retrain the model, and transmit the updated model back to the aircraft while it remained in flight.
By RIMPAC this summer, that capability had matured into something the team calls routine: two to three model retrains per four-hour flight, with performance improving while the aircraft was still airborne. “We’ve now gotten it so we’re improving performance during the flight,” Ziemba said.
Whitfield credited the pace of that evolution to a decision the team made early on to fund the development themselves rather than wait on a formal program of record. “One of the benefits of funding the whole thing ourselves was that we were able to move much, much faster,” he said. That self-funded posture let a small internal team backed, in Whitfield’s description, by “a community that had the ability and the need, and a company that had the resources… and the engineering acumen to do it”, iterate at the speed of the exercise schedule rather than the speed of a budget cycle.
Best of Breed, Not Proprietary Lock-In
A recurring theme in the conversation was the team’s insistence on sensor and platform agnosticism. Whitfield noted that the MH-60R helicopter behind him in his office carries 106 boxes built by 52 different companies, and that the rapid prototyping team has deliberately sought out “best in breed” partners rather than building everything in-house. At RIMPAC, that meant working not only with Saildrone but with Liquid Robotics’ Waveglider unmanned surface vehicle.
That partnership produced one of the program’s more significant technical findings: the ability to take data from a sensor the model wasn’t originally built for, in this case, a low-frequency acoustic array on the Waveglider, distinct from the DIFAR sonobuoys the MH-60R normally uses and use it to update the model flying on the helicopter. Administrative restrictions kept the team from completing that specific demonstration live on the RIMPAC range, but Whitfield said the systems checks and prior Unitas data left him convinced the underlying capability works: disparate sensors, on different platforms, updating a shared model.
“If you have the web and you have the right encryption and you have the right data share, you can move it back to a laboratory where you have the world’s greatest engineers,” Whitfield said. “You can take all sensor data and update models for all platforms in one world.” He called the implication “very futuristic” but grounded it in what the team has already proven: that the model can absorb data from sensors it wasn’t purpose-built for and put that data to work.
Ziemba described the underlying design philosophy the same way: the model was originally built for sonobuoys off a helicopter and then recognizing that an unmanned underwater vehicle wouldn’t necessarily carry sonobuoys at all extended again to ingest fundamentally different sensor types. “We’re not adapting the fleet to us. We’re adapting to the fleet,” Ziemba said, which is why the team has also worked with data-transport systems like Silvus rather than insisting on a proprietary pipe. Whitfield put the same point more bluntly: “We’re not trying to capture everything and make everybody come through us. Literally, the goal is how do we make the fleet more lethal and more safe, faster with what we’ve got right now.”
To move data at the classified level fast enough to matter, the team brought in a small company, Fuse Incorporated, to handle cross-domain solutions and networking across command-and-control systems, an area Ziemba said explicitly falls outside Lockheed Martin’s own core expertise. He indicated that “Fuse had an existing CDS solution that we were able to acquire and use faster than LM’s existing options ” He added: “All these exquisite sensors do nobody any good unless it gets to a decision maker at a COP that they can actually take the data, fuse it with others, and make decisions,” Ziemba said.
The Coders Come with the Aircraft
Perhaps the most consequential organizational choice the team made was bringing software engineers into the field with the operators, rather than sending problems back to a home office for a fix on someone else’s schedule.
“We actually bring coders with us,” Ziemba said. “We’re not going back to the shop to recode. We’re bringing the coders with us.” The result, he said, has been overnight rewrites of entire operator interfaces based on feedback the aircrew gave after a single fligh, changes that, run through a conventional crew station working group and requirements review process, would ordinarily take months or years to reach the fleet.
That posture, engineers embedded with the exercise, iterating against operator feedback in near-real time, is what both men pointed to as the real substance behind terms like “rapid prototyping” and “innovation at the edge,” phrases Whitfield and Ziemba both acknowledged have become common currency across the services without a shared understanding of what they actually require in practice.
The Acquisition Gap
Both men were candid about the tension between what the team has demonstrated and the acquisition system meant to field it. Ziemba described watching a capability that has been proven against live targets get referred back into “the standard Future Years Defense Process (FYDP) process,” with a timeline measured in years rather than the months in which the technology itself had matured.
Whitfield drew a comparison to Special Operations Command’s acquisition model and to microlending practices in small economies, where faster, smaller capital commitments unlock activity that a conventional lending bureaucracy would take too long to approve. “The bureaucracy is set such that it takes years to even get the contract approved,” he said. “As a small business, the price of entry is ridiculous unless you partner with a big[ger] entry.”
Whitfield credited the culture that made SensorMax’s rapid evolution possible to exercises like Resolute Hunter and RIMPAC, and specifically to the leadership of Rear Admiral Max “Pepper” McCoy, who as the admiral overseeing NAWDC’s Nautic ranges opened access to operators and resources in a way that let the team iterate against real operational feedback rather than a static requirements document. “You can write a requirements document for years, and you will still not garner the context that you get from a single Resolute Hunter or a single RIMPAC,” Whitfield said.
He argued that industry needs more, not fewer, opportunities to bring a capability that is “50 percent ready” to an exercise and find out what breaks, rather than being expected to arrive with something the government could buy off the shelf. “The more opportunities the Department of War gives us to do that, the idea of us, of anyone in industry, going, ‘Hey, I’ve got a box, I think it’s 50 percent ready, I’m trying to address this gap, and I’d like to come break it’, that’s how we get faster.”
Both men described SensorMax less as a single sensor program and more as an adaptable engine meant to be sensor- and platform-agnostic by design. Whitfield framed the underlying question as: “How do we create the engine to make use of any sensor data that we bring in? …If I’ve created an AI model that I could then use with any sensor data that comes in and update it in a way that it’s useful for every platform that I currently have, then I don’t care what you build tomorrow.”
Ziemba connected that adaptability directly to the operational tempo the fleet is now being told to expect. Referencing Admiral Samuel Paparo’s description of readiness for “the fight tonight” rather than a future fleet years away, Ziemba argued that SensorMax and the process behind it are an example of the kind of industry posture that tempo demands: models trained not on a static historical baseline but capable of in-situ retraining against the adversary and environment the fleet is facing today.
“The underwater environment changes all the time,” he said. “The ability to do the in situ retraining of the AI/ML that SensorMax allows us to do is giving that flexibility in terms of giving the Navy the adaptability and speed they need to adapt and win this fight.”
Notably, the Cold War model of underwater surveillance is changing dramatically under the influence of new technologies and platforms. The SensorMax approach is a critical part of such a transition to the post-SOSUS world.
SOSUS solved the sensing problem of its era by fixing hydrophone arrays to the seabed and wiring the ocean back to shore-based analysts. The architecture now emerging solves a different problem, geometry rather than fixed listening, by scattering sensing across mobile, networked nodes in place of a handful of cables. Programs such as TRAPS, DRAPES, and NEREUS are building the wireless connective tissue that lets that disaggregated field of sensors talk to the fleet, but connectivity by itself only produces more raw acoustic noise. It does not answer who, or what, makes sense of that noise fast enough to matter, and faster than a quieter adversary submarine fleet.
SensorMax is best understood as an early answer to that second half of the problem: an AI classification layer that travels with whatever platform happens to be listening on a given day, rather than one tied permanently to a shore station or a single aircraft type. In that sense, it does for the intelligence side of undersea surveillance what DRAPES does for connectivity, letting decades of investment in acoustic sensing and analytic tradecraft migrate into a mobile, software-defined architecture instead of being discarded along with the fixed arrays.