Last week at the Virginia Beach Convention Center, John Hopkin and John Mark Suhy presented a technical paper at the American Society of Naval Engineers Fleet Maintenance and Modernization Symposium. The symposium’s theme this year was “From Foundry to Fleet: Delivering Readiness and Capability,” and our paper addressed one corner of that: what happens to maintenance processes when the platforms they support no longer look like the platforms those processes were built around.
The argument starts with a mismatch. Maintenance requirement cards, preventive maintenance schedules, and lifecycle sustainment processes matured over decades against ships with forty-year service lives. Unmanned vessels operate on a different clock. They refresh faster, deploy on a different tempo, and sometimes do not come back. A configuration change can take longer to propagate through enterprise maintenance systems than the asset it describes remains in service.
That mismatch is made worse by a data problem. The information needed to answer even a straightforward maintenance question lives in separate places, and reconciling it is manual work that depends heavily on individual experience. A third problem compounds both: routing every non-trivial question back to a small pool of subject matter experts does not scale as assets multiply and disperse.
The paper describes a reference architecture for addressing this. It ingests from existing systems of record rather than replacing them, normalizes against a common domain ontology, and exposes the result through a governed data environment where source-system access controls remain authoritative. On top of that sits retrieval-augmented generation and agentic workflows, so a maintainer can ask a question in plain language and get a recommended action with the supporting evidence attached. Because the assets in question operate where connectivity is not assured, the architecture is designed to keep working at edge nodes through disconnected periods and reconcile cleanly on restore.
The questions from the floor went somewhere we did not expect, and they are worth reporting. None of them were about the maintenance architecture itself. The room asked how to get more useful functionality out of open models. It asked how to bring down the cost of building platforms like this in the first place. And it asked how to control token consumption and the cost that comes with it.
All three point at the same underlying concern, and it is not a technical one. The architecture is rarely what stops a capability from reaching the fleet. Cost is, as it includes both the cost to build and the cost to run. A system that answers maintenance questions well but consumes unpredictable amounts of inference is a system nobody can budget for.
Our answers drew on two areas of our own practice. On build cost, the agentic engineering processes we use internally are the reason we can move at the pace we do on programs of this kind. On operating cost, token control is built into our solutions at three levels. Budgets are set per user, so no individual account can run away with consumption. Requests are routed to specific models by task complexity and task type, so simple work does not get answered by an expensive model. And hard caps are enforced at the gateway, which bounds total spend regardless of what happens upstream. Together these make inferences cost, a number you set in advance rather than a number you discover at the end of the month.
The reception was encouraging in a specific way. Several attendees noted that it was good to see something working rather than conceptual, and there was clear appetite in the room for practical applications of AI in naval sustainment. Coming from an audience that has sat through a lot of AI briefings, that is the response we were hoping for. We also took away that the questions went to concerns of cost rather than capability.
Our thanks to ASNE for the venue and to the symposium papers committee. The paper will appear in the ASNE proceedings; we will link to it here once it is published. For questions, contact John Hopkin at jhopkin@greystonesgroup.com.
Copyright American Society of Naval Engineers. Reproduced with acknowledgement.