Problems, and how they were closed.

Customers were sitting on a portal full of temperature, vibration and motion telemetry and asking their account manager what it meant. The insight existed; the interface to it did not.

I designed a multi-tool agent on Azure OpenAI that speaks the platform's language. It writes and runs queries against the production databases, retrieves the right slice of sensor history, reasons over it, and returns an answer in plain language — with the numbers behind it.

The part that changes the product is the write path: the agent can change sensor settings in the portal directly. Asking a question and fixing the configuration became the same conversation.

A capable model is worth nothing commercially until someone outside engineering can show it to a buyer and have the value land. That gap is where most technical work quietly dies, so I treated closing it as part of the engineering job rather than someone else's problem.

I built interactive demo environments that put real analysis in front of prospects — live data, real model output, framed around the customer's operational question rather than our architecture. Sales and marketing use them directly in customer conversations.

I also run the enablement behind them: sessions that give commercial teams the vocabulary to explain what the system does, where it is strong, and where it is honestly not the right fit.

Vibration data coming off the fleet was noisy enough that models plateaued early. Rather than reach for a bigger model, I went after the representation: Fast Fourier Transform decomposition, targeted filtering, and spectral features engineered around the failure modes the domain actually cares about.

Cleaner features made the whole signal chain easier to reason about end to end, and the ideas that came out of the analysis were carried into successive hardware and firmware iterations. That kind of progressive improvement only happens when the software and hardware teams are reading the same data — as much a collaboration outcome as a technical one.

The pipeline later extended past vibration into temperature and motion, giving a single analytical view of the whole asset.

Detecting THC in breath is a genuinely hard measurement problem: the concentrations are tiny, the sensor drifts, and the ground truth is expensive to collect. The pipeline had to earn every point of accuracy at the data-cleaning stage before any model touched it.

Beyond classification, the analysis mapped how the device performed across operating conditions. Those insights informed each successive iteration of the breathalyzer, alongside the hardware team.

This is the project where I stopped being only a data scientist. The models were good; there was nowhere for a customer to see them.

I designed and built the portal on AWS from scratch, then built the on-device GUI for the Raspberry Pi breathalyzer units and connected the fleet back to it — so a device in the field and a user in a browser were looking at the same truth.

Hydrogen starvation degrades a solid oxide fuel cell quickly, and the place you would want to measure it is the place you cannot put a sensor. So I built the sensor in software.

A pseudo-2D physical model was swept across nine input parameters to generate a dataset of roughly half a million operating points. Networks trained on that dataset predict not only whether starvation is occurring, but how severe it is — fast enough to run inside a control loop, where the original simulation could not.

The same approach extended into dynamic modelling via modal analysis and into inverse algorithms for recovering internal cell parameters from external measurements.