The Problem
Our existing analytics engine could detect changes in machine behavior. Quality records lived on a separate timeline, often as a manual ticket created after a part reached inspection. A team could see that a machine had deviated and that a product had failed, but it could not reliably connect the two.
Timing made the problem harder. The quality event might be recorded at the end of a production step while the machine change that contributed to it happened several cycles earlier. Looking only at the fault timestamp hid the part of the process we needed to investigate.
My Role
I was asked to lead the project and turn the idea into a working use case. I wrote the executive plan, set the demo scope, and defined what the result needed to show. I also built the supervised-model approach.
The model used product-quality events as labels. Machine events and time-series measurements from the period before each quality record became the inputs. The purpose was to find which earlier patterns were consistently associated with a later quality result.
The internal plan is proprietary, so it is not attached here. This case study keeps the business problem and my decisions while leaving out customer examples, platform names, and implementation details that should remain inside the company.
How I Framed the Data
The first job was to create one usable timeline from records that were produced for different reasons.
- Align machine events and quality records to a common timestamp.
- Connect records by a production identifier when one is available.
- Build a lookback window before each quality event.
- Turn sensor behavior and detected events inside that window into model inputs.
- Train against the recorded quality outcome.
That last step needs a boundary. A model score can point an engineer toward a part of the timeline. It does not prove physical root cause. The output still has to make sense against the machine, the process, and what the operator observed.
The Controlled Demo
The demo plan used a robot arm as a small production line. We could run a normal cycle, introduce a measured change such as a gradual speed adjustment, and record the machine response. A quality ticket would be logged later in the sequence.
The test was whether the workflow could bring the earlier machine behavior back into view when someone investigated the quality event. Normal runs mattered too. Without them, the model could simply treat every unusual movement as meaningful.
The plan defined several checks:
- Machine and quality records had to remain traceable to the original timestamps.
- The report had to show where the analytics engine detected an event.
- Sensor deviations needed enough context for an engineer to review them.
- Troubleshooting material had to stay connected to the relevant machine event.
What Could Go Wrong
Bad time alignment. A correct model trained on the wrong window still gives the wrong investigation path.
Leakage. Information recorded after inspection cannot be allowed to explain a prediction that is supposed to use earlier machine behavior.
Sparse labels. Manual quality tickets may be inconsistent because operators use different language or record them at different points in the process.
Easy correlations. A signal can move near a defect without causing it. The model should narrow the search, then an engineer checks the process explanation.
Executive Update
Manufacturing teams can detect abnormal machine behavior, but the product-quality record often arrives later and in another system. I led a use case that joined those timelines and used quality outcomes as supervised labels. The working design looks backward from a quality event, scores the earlier machine history, and returns the signals that deserve review. The immediate demo used controlled robot behavior so the expected sequence was known. The next test was whether the model could surface that earlier change without flagging normal cycles the same way.
Why I Keep This Project in the Portfolio
This was an engineering problem, but most of the work was judgment. I had to decide which records belonged together, what counted as evidence, and where the model had to stop making claims.
That is also how I work with operational alerts. A signal can be real without being important. An event can deserve investigation without proving a cause. The useful output is a clear next step, plus enough of the original timeline for somebody else to challenge the decision.