What Shipping AI Into Submarine Construction Taught Me About Production ML

Most machine learning projects do not fail because the model was weak. They fail in the distance between a validated notebook and a system running inside someone else's workflow. I spent years closing that distance in Department of Defense inspection pipelines for submarine construction, and while the constraints there are stricter than most industries will ever see, the failure modes they expose are the same ones that quietly end commercial deployments.

The demo is the smallest part

A model that scores well on a curated dataset establishes feasibility and nothing more. The questions that decide whether the system survives arrive later. What happens when the input distribution drifts because the shipyard brings new imaging equipment online? Who reviews the model's output, and where does that review fit into a workday that was already full before the model existed? What evidence will satisfy a regulator, or in my case the DoD, that the system belongs in an active construction pipeline? A team that cannot answer those questions before development starts is still doing feasibility work, whatever the project plan calls it.

Evaluation carried the program

In defense work the evaluation harness is reviewed as closely as the model. We had to demonstrate, repeatably and with documented evidence, how the system performed across defect types, imaging conditions, and edge cases. That discipline consumed real budget, and it became the program's principal advantage: when a stakeholder challenged a result, the documentation answered the challenge, and when we changed the model, the harness told us immediately what the change had cost. Commercial teams can adopt this directly. Build the harness before the model matures, and make every model change answer to it.

The inspectors could have refused it

Our defect-recognition system changed what radiographic inspectors spent their attention on. It did not remove them, and designing that hand-off consumed as much engineering judgment as the network architecture did: which findings the model surfaces, how confidence is presented, and at what point a human has to make the call. An inspector who distrusts a tool routes around it, and once that happens the accuracy metrics stop mattering. That design work is what earned acceptance from the people in a position to refuse the system.

Constraints did useful engineering work

Air-gapped environments, classified data, and hardware we could not change ruled out most convenient answers. When calling a commercial API is legally impossible, you learn exactly what the system requires, because every capability has to be justified, built, and maintained inside the boundary. Several of our better architectural decisions trace directly to a constraint that had removed the easy path.

Across all of it, the model was rarely where the program's risk lived. The risk lived in evaluation, integration, and the people operating the result, and the budget only worked when it was allocated accordingly. That ordering looks obvious on paper, and schedule pressure is what reverses it: the model is the visible deliverable, so it gets the attention first and the harness gets whatever time is left.