- \n
- An AI model answers the question it is given, right or wrong.<\/li>\n
- On a production line, the problem statement is written in the stop log.<\/li>\n
- Manual logs miss short stops, round durations and overuse “other”.<\/li>\n
- Measure every stop, rank losses, write the problem, then choose the role of AI.<\/li>\n<\/ul>\n<\/div>\n
The question nobody asks before the AI project<\/h2>\n
Many AI projects on downtime start from a solution. Someone wants to predict breakdowns, detect anomalies or automate reason codes. The project is scoped around the tool, the data is pulled from whatever exists, and the model is trained.<\/p>\n
The trouble is that a model answers the question it is given. If the question is when a spindle will fail, you get a failure prediction, even if breakdowns are only a small share of the time the line loses. On many lines, for example, the bigger losses sit elsewhere: short stops of a minute or two that nobody writes down, changeovers that drift from the standard, waiting for material or for a technician. A perfect answer to the wrong question still leaves those minutes on the table.<\/p>\n
That is why the first deliverable of an AI project on downtime should not be a model. It should be a problem statement that a production team agrees with and that the data can support.<\/p>\n
Problem framing comes first: what Tim McMahon takes from Who Leads When AI Thinks?<\/h2>\n
Tim McMahon, founder of the A Lean Journey blog, puts the underlying principle at the center of his Book Review: Who Leads When AI Thinks? Leadership, Judgment, and the Art of Problem Framing<\/a>. Reviewing Adrian Wolfberg’s book, he highlights the author’s argument that framing problems correctly is one of the most important responsibilities of leadership, and that this responsibility stays with people.<\/p>\n
In closing, he writes that Wolfberg offers \u201ca timely reminder that while technology may help us solve problems faster, it is still people who must ensure we are solving the right ones.\u201d<\/p><\/blockquote>\n
Two other ideas from the review translate directly to the shop floor. First, the link to familiar lean practice: PDCA, A3 thinking and root cause analysis all start with careful observation and thoughtful problem definition. Second, the framework the book proposes for deciding whether AI should automate, assist, augment or simply inform a decision. Tim also notes that the book is not a technical guide to implementing AI. Its subject is judgment. And both ideas assume something that many plants do not have yet: a factual picture of where the time goes.<\/p>\n
![\"Four-step](\"https:\/\/teeptrak.com\/wp-content\/uploads\/2026\/10\/teeptrak-ai-downtime-problem-framing-en.png\")
<\/figure>\nWhy the stop log is your problem statement<\/h2>\n
On a production line, the problem statement for downtime is written in the stop log. Where did the line stop, when, for how long, how often and why? If those five answers are reliable, framing the problem is mostly a matter of reading them honestly. If they are not, every discussion about AI rests on assumptions.<\/p>\n
Manual logs tend to fail in predictable ways. Short stops are rarely recorded because stopping to write them down takes longer than the stop itself. Durations get rounded. Reasons are filled in at the end of the shift from memory, and a large share lands in “other”. Train a model on that history and it learns the logging habits of each shift rather than the behavior of the machine.<\/p>\n