Production ML on a Factory Floor: Lessons from a Fiber Robot

Between October and December 2024, I worked as a machine learning engineer at Cowlar Design Studio on a fiber organizer and termination line for viaPhoton, an Amazon-partnered fiber optics supplier in Aurora, Illinois. The machine is covered by viaPhoton's US Patent 12,001,073 B2. I worked on its machine learning and computer vision.

It is still the project I think about most when someone tells me a product "just needs an ML layer." The short version is in the Fiber Organizer Robot case study. This is the longer version: what the work taught me.

The problem

Optical fiber is unforgiving at production scale. The fibers this line handled are 250 microns across, a quarter of a millimeter, and before a cable can be terminated its fibers have to be in the right order and precisely aligned. Sorting the fibers for one cable took about three minutes.

The patent describes the core idea. Fibers go into the machine in a random order, and the system works out the moves that put them into a predetermined sequence. A camera images the fibers, and a neural network checks whether they ended up correctly ordered.

What changed

These are the numbers I can stand behind:

• Sorting time per cable fell from about three minutes to eight seconds.
• The vision system sorted 250-micron fibers with 96% accuracy, and the integrated termination line aligned them to 5-micrometer precision.
• On the organizer line, AWS cable output went from one cable an hour to six, roughly fifty a day.
• Across the wider factory automation effort, monthly capacity went from 240 cables to 9,600: forty times.

Only one of those is a model metric. The rest are measured in seconds and cables, because that is what the business measured. That was the first lesson.

Lesson 1: the model is the small part

If I had to put a number on it, the model was maybe 30% of the work. In production computer vision, the rest is everything around the model: image capture that behaves the same way on every shift, inference that fits the machine's timing, and the edge cases a clean dataset never contains.

Research ML is a controlled experiment. You have a fixed dataset and one metric, and you iterate until the number goes up. Production ML is an integration problem, and the model is one component in a system that includes:

• Hardware. Cameras, lighting, mounts, and compute you cannot SSH into at 2 a.m.
• Data. Capture, preprocessing, and the failure cases specific to your environment.
• Serving. A latency budget, failure modes, and a plan for what the machine does when inference returns something strange.
• Operations. How an operator knows something is wrong, and how they recover without calling an engineer.
• Retraining. Production data drifts. A model you deploy once is a model that slowly degrades.

A notebook only asks you to get the first item on that list right, and only approximately.

Lesson 2: speed is designed, not discovered

Three minutes down to eight seconds is a product outcome, and no single component delivered it. Latency has to be budgeted across the whole pipeline, and the model gets only its share of that budget.

At Cowlar I also worked on inference speed in general, taking requests from about 200 ms to under 100 ms with NVIDIA-enabled Docker images, code optimization, and dimensionality reduction. On a production line that kind of gain compounds: the machine waits for the model on every cycle, all shift, every shift.

The same pressure showed up on the smart shopping cart for Al-Meera supermarkets in Qatar, where action recognition had to reach 95% accuracy in real time on edge devices. Accuracy you can only deliver slowly is accuracy the user never sees.

Lesson 3: "just add ML" hides most of the schedule

This project made me a better product manager. I didn't manage it. I worked on it, and watched every "how hard can it be" get tested by a factory.

When someone in a roadmap meeting says "we just need to add an ML layer," I know what "just" is hiding: hardware, data capture, latency, operations, and retraining. Those are product decisions with engineering consequences, and they are where the schedule goes. It is also why I think most AI products that fail in year one fail for reasons that have little to do with the model.

What I'd tell an engineer starting a project like this

• Write the operator's failure story before you write the model's accuracy target.
• Measure the system in the units the business uses, such as cables per hour or seconds per sort, not only in model metrics.
• Budget latency end to end, and give the model only its share.
• Plan retraining on day one. Production data is not your training data, and it will not stay still.

Correction, October 2026: an earlier version of this post overstated my role in the patent. The patent belongs to viaPhoton. I worked on the machine learning and computer vision for the machine it covers.