Five Design Principles for an AI Copilot That Process Engineers Will Actually Use
Consumer AI tools fail on factory floors. Not because the underlying technology is inadequate — the models are often capable — but because the interaction model was built for a different context. A chat interface optimized for knowledge retrieval assumes the user has time, a keyboard, and a clear question. A process engineer standing at a fault station at 2:15 AM has none of those things. They have a tablet running a thick-client MES app, a fault code on a Siemens TIA Portal screen, and six minutes before the line should have restarted.
Building an AI copilot for discrete manufacturing is not a matter of deploying a general-purpose AI in a manufacturing context. It requires starting over from the engineer's cognitive model — how they think about faults, what information they need in what order, what they will trust and what they will dismiss — and designing the AI interaction around those constraints. Over twelve months of embedded observation at automotive stamping plants and electronics sub-assembly lines in the Midwest, we built Intuigence around five principles that consistently separated useful AI behavior from distracting AI behavior on the plant floor.
Principle 1: Show Evidence, Not Confidence Scores
The most common failure mode in industrial AI deployments we observed was the confidence score without evidence. A system would display "Station 14 — Root Cause Probability: 84%" and engineers would ignore it within two weeks. The number without the supporting trace data is not actionable — and for an engineer who has been burned before by a system that was confidently wrong, it is actively trust-destroying.
The design change that moved engineers from skepticism to engagement was simple: show the trace evidence alongside the hypothesis. Not "Station 14 — 84% probability" but "Station 14 — cylinder position overshoot started at 14:22, correlates with quality rejects beginning at 14:49 — this is the tag sequence we observed: ST14_CYL_POS_FB deviated +12% at T+0, QG_ST19_REJECT_BIT set at T+27min." The engineer can look at that sequence, recognize it from their own experience, and either confirm or dismiss the hypothesis in 30 seconds.
This is the difference between a system that asks for trust and a system that earns it. IEC 62832 (Digital Factory reference model) and similar industrial informatics frameworks emphasize traceability between decision and data source — not as a compliance requirement in this context, but because traceability is what makes an automated recommendation verifiable. Engineers who can verify a recommendation will use it. Engineers who cannot verify it will not.
Principle 2: Match the Engineer's Mental Model of the Line
Process engineers think in stations, not tags. They think in fault modes, not bit vectors. They think in production orders and quality gates, not raw data streams. An AI copilot that exposes its outputs in the same terms as the raw data it processes — tag names, signal amplitudes, timestamp offsets — is making the engineer translate its outputs into their mental model before they can use them.
The interaction design principle this implies is that the AI's vocabulary must be the engineer's vocabulary. When the AI names a root-cause station, it names it by its human-readable station label — "Station 14 hydraulic press" — not by its PLC address. When it describes the fault mode, it uses the fault taxonomy the plant's maintenance team already uses in their CMMS — "cylinder position drift" or "pressure undershoot" — not a model-internal classification label.
This requires a one-time mapping step when the system is commissioned at each plant: associating the PLC tag namespace with the station-level naming convention and fault taxonomy the plant uses. In a Rockwell Studio 5000 project, this mapping is typically embedded in the tag names themselves — well-structured projects use naming conventions like ST14_HYD_A_PRESS_ACT that encode the station, subsystem, instance, signal, and type. In older or less-structured projects, the mapping is manual. Either way, it is a configuration step, not an ongoing engineering burden.
Principle 3: Fit Into the Existing Workflow, Not Beside It
One of the earliest lessons from floor observation was that a separate AI interface — even a good one — competes with the engineer's existing tools rather than supporting them. If using the AI copilot means opening a browser tab, logging into a separate system, and reading a recommendation while also watching the PLC HMI and the MES production display, the cognitive load is additive rather than subtractive. The tool becomes another thing to manage, not a reduction in what needs to be managed.
The design principle that follows is: the AI copilot output should appear where the engineer is already looking. In practice, this means two integration points: the MES event view (where fault events are logged and where engineers spend most of their diagnostic time) and the work order interface (where corrective actions are initiated). When a fault fires and the engineer opens the fault event in the MES, the AI hypothesis and trace evidence should be visible in that same view — not in a separate system that requires a context switch.
We are not claiming that deep MES integration is always feasible — every plant's MES implementation is different, and some are structurally difficult to extend. What we are saying is that the workflow integration question should be the first question asked in any AI copilot deployment, not a later-stage concern. An AI copilot that requires engineers to change their workflow to use it will see adoption rates in the single digits. One that meets engineers where they already work will be used within the first week.
Principle 4: Distinguish Between What the AI Knows and What It Guesses
Fault diagnosis involves two types of inference: pattern-matched inference (this deviation profile matches fault modes the system has seen in similar equipment) and extrapolative inference (this deviation profile does not closely match anything known, but the temporal correlation structure suggests a probable mechanism). These are very different types of claim, and they should be visually distinguished in the output.
In practice, this means a fault-mode confidence display that has two axes: confidence (how strongly does the evidence point to this hypothesis?) and precedent (how closely does this pattern match previously observed fault events?). An engineer seeing a high-confidence hypothesis with strong precedent match should treat it differently than one seeing a moderately confident hypothesis derived from a novel pattern. The first is the AI drawing on experience that approximates the veteran engineer's mental map. The second is the AI reasoning about a new situation — still potentially useful, but warranting more caution before acting on it.
The failure mode this principle prevents is the engineer who trusts the AI's pattern-matched recommendations (earned through consistent accuracy) and then over-trusts a novel extrapolation. Distinguishing the two, visually and clearly, maintains the correct calibration of trust.
Principle 5: Generate the Work Order, Not Just the Diagnosis
This principle sounds obvious but was one of the hardest to implement correctly. The gap between "AI identifies root-cause station" and "engineer closes a work order" is not trivial. The work order requires: the correct station ID in the CMMS notation, the fault mode in the CMMS fault taxonomy, the corrective action in the format the maintenance team will act on, the relevant part numbers for likely replacement components, and a priority classification consistent with the plant's maintenance prioritization scheme.
Most AI-assisted fault detection systems stop at the diagnosis layer. The engineer receives a root-cause hypothesis and then must manually construct the work order — a process that is error-prone, time-consuming, and introduces a translation layer between the AI's output and the CMMS record that makes traceability harder to maintain.
The design principle is that the AI copilot should draft the complete work order, not just the diagnosis. The engineer's role is review and approval — confirming that the draft reflects what they observed on the floor, adjusting it if needed, and submitting it. This is the correct division of labor: the AI handles the data synthesis and document construction, the engineer provides ground-truth verification and final authorization.
For IATF 16949 traceability requirements, this structure also provides the audit trail: fault event → trace evidence → AI hypothesis → work order draft → engineer approval → CMMS record. Every step is logged, timestamped, and linked. The corrective action record is complete without requiring the engineer to manually reconstruct the diagnostic chain after the fact.
What These Principles Reject
These five principles collectively reject a particular design philosophy that is common in enterprise AI tools: the idea that the AI's job is to provide information, and the human's job is to figure out what to do with it. On a factory floor, under production pressure, with shift economics visible in real time on the OEE display, that philosophy produces tools that engineers browse but don't rely on.
Intuigence was built around the opposite philosophy: the AI's job is to produce a complete, actionable output at the end of each analysis cycle. The engineer's job is verification, not synthesis. The synthesis — pulling together 6 hours of trace data, correlating it across 64 stations, mapping it to fault modes, building a work order — is exactly the kind of time-consuming, pattern-intensive work that AI handles well. The final judgment about whether the work order reflects reality is exactly the kind of contextual, ground-truth verification that requires a human standing in front of the equipment.
Getting this division of labor right is what separates industrial AI tools that are used from ones that are piloted and abandoned. The technology is necessary but not sufficient. The design is the hard part.