A decision-support system for manufacturing supervisors facing unexpected machine failures. An on-premise LLM analyses the situation and ranks options for replacement machines and workers; the supervisor stays in charge of every decision that matters.
“Enable manufacturing supervisors to make effective decisions quickly when unexpected equipment failures occur, by coordinating machine replacement and worker reallocation.”
The objective is to resolve machine failures as quickly as possible, minimising production downtime by reallocating workers and replacement machinery. Two constraints shape everything that follows:
Every delay directly increases production loss.
Final decisions remain with the supervisor. The system advises; it does not act autonomously.
An experienced floor supervisor responsible for 20–50 workers across several lines. Decisive under pressure, they need reliable recommendations rather than raw data, on a tablet.
I started from a solution-neutral function model: what has to happen, from monitoring the line to the post-incident report, before deciding who or what does it.
| # | Function | Requirement | Type |
|---|---|---|---|
| F1 | Supervisor monitoring | A persistent overview of the production environment, accessible at any time | User-elicited |
| F2 | Failure detection | Automatically detect machine failures from sensor data | Technical |
| F3 | Supervisor alert | Notify the supervisor immediately upon failure detection | User-elicited |
| F4 | Machinery status | Real-time machine status without manual update | Technical |
| F5 | Worker status | Integrate with worker databases to show live availability and skills | Technical |
| F6 | Data analysis (AI/LLM) | Analyse machine and worker data to generate inputs for recommendations | Technical |
| F7 | Machinery recommendation | Ranked replacement machine options | User-elicited |
| F8 | Worker recommendation | Worker reallocation based on skills and availability | User-elicited |
| F9 | Supervisor decision interface | Machine and worker recommendations in a single view, usable while in motion | User-elicited |
| F10 | Worker notification | Notify workers of their reallocation upon supervisor confirmation | Business |
| F11 | Machinery replacement | Reduce time from failure to a confirmed rerouting decision | Business |
| F12 | Production restart control | Explicit supervisor confirmation before restart | Regulatory |
| F13 | Post-incident report | Automatic structured report upon production restart | Business |
A morphological chart listed the possible carriers for every function. Two concepts came out of it, identical except for the main interface: C01 uses a tablet, C02 an AR head-mounted display. I scored them on five weighted criteria.
On-premise LLM, not cloud. Local processing removes the dependency on external connectivity in an unstable industrial network, and gives the organisation full authority over when the model is updated. Unmanaged updates can silently change how the system behaves.
One view for machines and workers. Showing both recommendations together speeds up the decision in an emergency, at the cost of a higher cognitive load. A trade-off justified by the time-critical nature of the scenario.
Each function got an automation level from 1 (fully human) to 10 (fully automatic). The rule behind it: where speed and data volume favour the machine, the system runs autonomously; where judgment and accountability matter, authority stays with the supervisor.
The result is tactical shared control: the AI pre-structures the option space, the supervisor decides. A strategic level, a fully autonomous response, was explicitly rejected. Beyond trust, it opens a gap in the Gulf of Evaluation: a supervisor who no longer perceives decisions as their own cannot tell when something feels wrong.
Reduced by delegating detection, status tracking and analysis (F2, F4, F5, F6) to the AI.
Preserved by continuous monitoring (F1), always active in normal operation.
Countered by mandatory confirmations at the decision (F9) and the restart (F12).
Managed through interactive machine learning and simulation sessions.
Mapping the incident across four lanes (supervisor, system, machinery, workers) revealed physical and infrastructural dependencies that a single-actor view hides. It also made the system boundary explicit.
The supervisor decision interface (F9) is not information to study, but options to act on. Its governing principle is minimum necessary information: not completeness, but clarity. For each candidate it shows only the 3–5 factors that most influenced the AI’s ranking: enough to verify the key assumptions, not enough to overwhelm.
The format is parallel coordinates: each candidate machine or worker is a line across one axis per factor. The top recommendation can be verified or challenged in seconds, without reading a table.
Every response feeds back into the model. Modifications and overrides carry the strongest signal: an implicit correction of the AI’s reasoning.
The LLM produces outputs without showing the reasoning behind them. That is the central HCI tension of the system, and it shaped three decisions.
The analysis returns a ranked list with supporting data, not a single verdict. The supervisor evaluates the evidence, not the black box.
False positives erode trust in alerts; false negatives cost downtime and safety. A minimum true positive rate is defined before deployment, so trust can be measured.
A retrained model can change behaviour invisibly. Every update is validated against historical failure scenarios first.
I applied the Structured What-If Technique (SWIFT) across the whole process, from detection to restart: 18 scenarios, each scored by likelihood (1–5) and impact (1–10).
| N° | What if… | Cause | Risk |
|---|---|---|---|
| N°13 | Supervisor is distracted | Talking to others, context switching | 32 |
| N°9 | System fails to detect an error | Sensor malfunction | 20 |
| N°2 | Tablet receives no data | Power failure or network issue | 18 |
| N°4 | Machinery sensors send no data | Sensors not working | 16 |
| N°10 | LLM suggestion is not appropriate | Lack of data, data errors | 16 |
| N°16 | Worker receives no information | Communication failure | 16 |
The highest risk is not technical: a supervisor distracted under time pressure, compounded by automation bias.
The other high scenarios point to one structural weakness: the quality of the data feeds. Sensor reliability and up-to-date worker records are the main levers, and they sit outside the system’s direct control. SWIFT also has a limit: it scores discrete events, not gradual drift. Automation bias and skill degradation are systemic risks it underrepresents by design.
The production environment keeps changing. Without a way to learn, recommendations would drift from the reality the model was trained on.
Interactive machine learning turns every decision into a training signal: what was recommended, what the supervisor did, what happened next. Recurring overrides reveal gaps in the model.
Simulation is the main mechanism: scripted failure scenarios run under controlled conditions. One session validates the system, generates feedback for the model and keeps the supervisor’s skills alive through practice, including scenarios without AI support.
Every requirement maps to an acceptance criterion and a test instrument. Validation combines two: simulation-based testing as the primary method, and Nielsen’s heuristics for the interface. Visibility of system status (H1) tests whether the LLM’s reasoning is surfaced enough at the decision; user control and freedom (H3) tests whether the supervisor has real agency rather than coerced acceptance.
After any model update both are applied again: a retrained model may meet every requirement and still behave differently.
The system centres on LLM-driven automation without removing the supervisor’s sense of ownership. The tablet as primary interface keeps the supervisor cognitively present at every critical decision.
The core tension is the LLM’s opacity: the supervisor can evaluate and override suggestions independently, but doing so consistently increases response times. This is the trade-off the system navigates.
Over time, two risks require active management. Excessive reliance on automation can generate skill degradation, the gradual erosion of the supervisor’s independent judgment. And trust in the AI is not a given: it must be established and maintained through consistent performance, transparent outputs and structured validation.
This system enables the supervisor to resolve failures faster without substituting their judgment: the initial objective.