Enterprise Architecture Blueprint for an AI Production Supervisor

Executive Summary

Walk onto any mid-to-large plant floor and you will find a paradox. The plant is exquisitely instrumented - PLCs streaming machine states, an MES counting every unit, an andon system capturing stoppage reasons, a quality system logging every inspection. And you will find a shift supervisor standing in front of a screen that tells her Line 3 is behind, walking to the machine, phoning maintenance, and reconstructing why from memory and hearsay - usually finishing that reconstruction after the shift is already lost.

The data was never the problem. The gap is between the data and the next decision.

This article sets out how we at Codersarts would design and deliver an AI Production Supervisor:

A governed decision-intelligence layer that sits above a plant's existing systems, continuously monitors every line, explains deviations with ranked and evidence-cited root causes, forecasts end-of-shift attainment, recommends specific corrective actions inside the window where they still matter, and generates the shift handover report in one click. It answers a supervisor's questions in plain language - and it does so under one non-negotiable principle: the AI never invents a number.

That principle is not a slogan. It is the central architectural decision of the entire system, and most of this article is about how to enforce it.

For a representative discrete manufacturer — 6 plants, ~40 lines, $1.2B revenue, ~62% average OEE — the modeled value at 24 months is $18M–$31M annually, against a payback window of 9–15 months. We will show that model and, more usefully, show you the three ways it is commonly overstated and how to avoid overstating it.

Download the PRD for Reference

AI_Production_Supervisor_PRD.pdf

Download PDF • 305KB

Part 1 - The Problem

Plants are data-rich and answer-poor

Everything needed to explain a shortfall already exists somewhere in the plant. Machine states come from the PLCs. Counts come from the MES. Stoppage reasons are keyed at the andon. Changeover start and stop timings are recorded. Inspection results sit in the quality system. The roster sits in a workforce system, or a spreadsheet.

That data lands in four to six systems, owned by three different functions, on incompatible time bases, with no shared definition of a "line" or a "shift." Nothing joins them.

So the supervisor becomes the integration layer. She integrates by walking, phoning, and remembering. She is a $70,000-a-year human ETL pipeline, and she is doing this job during the same eight hours in which she is also supposed to be running production.

Dashboards report the past; they do not defend the shift

A dashboard is a passive artifact. It requires a human to look at it, at the right moment, knowing what to look for. That is a poor design for a problem where the most valuable minute of the shift is the one immediately after a loss begins - and that is precisely the minute in which nobody is reading a dashboard, because something has just gone wrong on the floor and everyone is looking at the machine.

The consequence is structural: deviations are discovered late, and by the time they are understood, the recoverable window has closed. A tooling failure understood at 08:20 can be contained. The same failure understood at the end-of-shift review is just a number in a report.

Root-cause analysis is tribal, inconsistent, and reserved for the wrong losses

Ask three supervisors why a line missed target and you may well get three different answers, ranked differently, sourced from memory.

Worse, formal RCA — the 5-Whys, the fishbone, the cross-functional review — is reserved for incidents. It gets applied to the big breakdown, days later. It is almost never applied to the routine, cumulative losses: the four-minute micro-stops, the changeover that ran eighteen minutes long, the speed loss nobody noticed because the line was, technically, running.

Those unglamorous losses usually destroy far more output than the incidents that get investigated. They are invisible precisely because each one is individually beneath the threshold at which anyone would open an investigation.

The shift handover is a manual reconstruction

Supervisors typically spend 30 to 50 minutes per shift assembling the handover: pulling counts, listing stoppages, recalling what maintenance said, writing the note. This is unpaid analytical labour, performed by a scarce and expensive operational leader, at the end of a physically demanding shift, when she is least able to do careful work.

The output is inconsistent in quality and routinely omits the causal detail the incoming shift most needs. Multiply by three shifts, by 120 supervisors, by 340 days.

Generative AI raised expectations and risk at the same time

Plant leadership has watched consumer LLMs answer questions fluently, and now asks for "ask the plant anything."

Point a language model naïvely at plant data and it will do exactly what language models do: produce a confident, well-phrased, plausible answer. It will misattribute a stoppage. It will invent a downtime duration. It will assert a causal link the data does not support.

On a shop floor, a confidently wrong instruction has physical consequences. Reallocate the wrong operator, defer the wrong maintenance, chase the wrong root cause — these are not embarrassing, they are expensive, and occasionally they are dangerous. And a single fabricated number, discovered by a plant head who then loses trust in the whole system, ends the programme.

This is why so many manufacturing AI pilots die between demo and production. The demo was convincing. Nobody could vouch for the numbers.

Part 2 — Why Existing Solutions Fall Short

MES and SCADA are systems of record and control. They capture events accurately and display them faithfully. But they do not reason across domains — they cannot connect a quality drift to a tooling stop to a roster gap, because they were never designed to hold all three at once.

BI and OEE dashboards visualize the aggregate. They tell a plant head that OEE was 62% and availability was the biggest bucket. They cannot tell a shift supervisor that M12's carbide insert is degrading right now, and will cost her forty minutes if it isn't changed at the next planned stop.

Point predictive-maintenance tools address one loss class — breakdowns — on one asset class, usually via a proprietary sensor kit. They are structurally blind to changeover, material, scheduling and quality losses, which together typically exceed breakdown losses.

Generic "chat with your data" tools have no model of a shift, a line, a standard rate, or a downtime reason code. They will answer a production question fluently and unverifiably — which is strictly worse than not answering it.

Consulting-led CI programmes produce genuine improvement, but they are episodic and human-intensive. The consultant is not present on the night shift, and the insight decays the moment the engagement ends.

None of these is wrong. They are just not the thing that closes the gap between the data and the next decision.

Part 3 — The Architecture

The platform is a layered system, deployed with a plant-edge component and a central component. That split is not an aesthetic preference; it is forced by the operating environment. Plant networks are segmented from corporate IT. WAN links are unreliable. Data-residency rules may prohibit raw process data leaving the site. A system that stops monitoring production because the corporate VPN dropped is not a production system.

Layer	Responsibility
1. Acquisition (plant edge)	OPC UA / MQTT clients, MES and CMMS connectors, store-and-forward buffering, local time alignment. Runs inside the plant network.
2. Plant Model (edge + centre)	Canonical entities Plant, Line, Machine, Shift, Product, Batch, Event, Inspection plus the reason-code taxonomy, standard rates, and roster. The single semantic contract every other layer reads.
3. Analytics Engine	Deterministic computation: attainment, OEE and its components, loss attribution, bottleneck detection, forecasting, scenario evaluation. All numbers originate here.
4. Reasoning & Orchestration	Root-cause ranking, recommendation generation, evidence assembly, report composition.
5. Language Layer	An LLM used for question interpretation, evidence-grounded phrasing, and report narrative constrained by tool-calling into Layers 3 and 4. Produces no numbers of its own.
6. Experience	Supervisor console (line-side screen), mobile, chat, report export, admin.
7. Governance	RBAC, audit log, data-quality monitoring, model evaluation, action authorization.

The Grounding Contract - the one decision that matters

The single most important architectural decision in this entire system is the boundary between Layer 3 (deterministic analytics) and Layer 5 (the language model).

The language model may read computed results and phrase them. It may not compute them.

Concretely:

• Layer 3 exposes a fixed set of typed analytical functions: line_attainment(line, t), oee(line, shift), loss_attribution(line, shift), bottleneck(plant, shift), forecast(line, shift), scenario(action). Each returns a structured, evidence-bearing result.

  
  

• Layer 5 answers a question by selecting and invoking those functions, then rendering the returned values into prose. Numbers in the prose are substituted from the structured payload — not generated.

  
  

• If no function can answer the question, the system says so. It does not extrapolate.

  
  

• Every answer carries the record identifiers it used, so any number on the screen can be traced to a machine, a timestamp, and a count.

  
  

This is what makes the system safe to run a shift on. It is also what makes it demonstrable: a plant head can point at any figure and ask "where did that come from?" — and get an answer, immediately.

There is a pleasant second-order benefit. Because the LLM is confined to interpretation and phrasing, the platform is unusually insensitive to model choice. Swap the model, and the numbers do not change. In a field where the frontier moves every few months, that is a deliberate hedge against both vendor lock-in and model churn.

Part 4 - Root-Cause Attribution Is Accounting, Not Inference

Here is where most "AI for manufacturing" propositions get hand-wavy. Ours does not, because attribution is not an inference problem. It is a deterministic accounting exercise.

For a line behind plan by N units, the engine reconstructs the shift minute by minute:

1. Compute the theoretical output for the elapsed shift at the standard rate for the running product.

   
   

2. Subtract time lost to recorded downtime events, converting minutes to units at the standard rate — accounting for buffers, so a stop on a non-constraining machine is not over-counted.

   
   

3. Subtract changeover time in excess of the applicable standard.

   
   

4. Subtract material starvation and blocking time.

   
   

5. Subtract speed loss: the gap between actual and standard cycle time while running.

   
   

6. Subtract quality loss: scrap and rework units.

   
   

7. Reconcile. Attributed losses plus actual output must equal theoretical output.

   
   

Step 7 is the one that earns trust. Any residual is reported as unattributed loss — never silently distributed across the other buckets to make the arithmetic look tidy.

That residual is a first-class output of the system. A plant with 20% unattributed loss has a data problem, and the platform's job is to say so plainly, on the first day.

In practice, that finding alone is frequently worth the pilot. It is very common for a plant to discover that a third of its downtime is never keyed with a reason, which means a third of its improvement effort has been aimed by guesswork. Nobody enjoys hearing this. Everybody benefits from it.

The AI-vs-not-AI division of labour

"AI" covers four distinct techniques here, and conflating them is how programmes fail:

Technique	Used for	Explicitly not used for
Deterministic analytics	Every metric a supervisor acts on: attainment, OEE, lost minutes, unit impact, forecasts	Anything requiring judgement or unstructured input
Statistical / ML models	Anomaly and drift detection, micro-stop clustering, changeover-duration prediction, RUL signals	Producing the headline numbers
Rules & optimization	Recommendations under roster, skills and capacity constraints	Explaining causality
Large language model	Question interpretation, evidence-grounded phrasing, report narrative, multilingual delivery	Computing any number. Asserting any causal claim the attribution engine did not supply.

Notice how little the LLM does. That is the point. The LLM is the interface, not the intelligence — and in this domain, that is exactly the right allocation of trust.

Part 5 - What the System Must Refuse to Do

Scope discipline is a safety property in manufacturing. These are architectural commitments, not backlog items:

It does not write to control systems. No PLC writes. No SCADA setpoint changes. No interface of any kind to safety-instrumented systems, interlocks, or e-stop circuits. OPC UA connections are subscription/read-only — and the write methods are not implemented in the connector, not merely disabled in configuration.

State this early and unambiguously in every customer conversation: the AI Production Supervisor cannot move a machine. It is the single most important sentence for getting past OT and plant engineering, and it needs to be true at the code level, not the policy level.

It does not schedule production. It informs the scheduler; APS/ERP remains the planning authority.

It does not act autonomously on the floor. Actions with physical or commercial consequence — creating a CMMS work order, raising a material expedite — are disabled by default, and when enabled, every one is human-approved and audited.

It does not score workers. Which brings us to the constraint that most technical teams forget, and that kills more manufacturing AI programmes than any architecture flaw.

Part 6 - The Constraint Everyone Forgets: Measure the Process, Not the Person

A system that watches a factory floor can very easily become a system that watches the people on it.

That would be ethically objectionable. It would also, in most jurisdictions our customers operate in, be a fast route to a works-council or union veto that ends the programme regardless of its technical merit.

So these are product requirements, not policy suggestions:

• Attribution is to causes, not individuals. Losses are attributed to tooling, material, procedure, scheduling and equipment. The system does not produce per-operator productivity scores, rankings, or comparisons — and cannot be configured to.

  
  

• Roster data is used for capability, not surveillance. Operator identity determines skills and availability for reallocation recommendations. It is never used to evaluate performance.

  
  

• Coaching is addressed to the process. The recommendation reads "changeover ran 18 minutes over the 12-minute standard; a checklist board at this line typically closes most of that gap" — not "this crew is slow."

  
  

• Transparency to the workforce. What is collected and why should be disclosed to employee representatives before deployment. Make it part of the pilot charter.

  
  

• No individual-level data in exports. Reports aggregate to line, shift, and cause.

  
  

Experience in this sector is unambiguous: programmes perceived as worker-surveillance tools do not survive contact with the floor. Designing this constraint in from the first architecture diagram is a commercial advantage, not a limitation — and it is, incidentally, what keeps the system comfortably outside high-risk classification under the EU AI Act.

Part 7 - Delivery

Phasing

Phase	Duration	Scope	Exit criteria
0 — Discovery	3–5 weeks	Data-source audit; reason-code reconciliation; standard-rate model; OT security review; baseline measurement	Signed data map, security approval, agreed baseline
1 — Pilot	10–14 weeks	One plant, 4–8 lines. Ingestion, plant model, OEE engine, attribution, forecasting, handover, NL Q&A	Unattributed loss ≤5%; handover time down ≥60%; supervisors actually using it
2 — Production	4–7 months	All lines in 2–4 plants. Recommendations, mobile, notifications, human-approved CMMS work orders	2–4 OEE points on constrained lines; recommendation acceptance ≥40%
3 — Network scale	6–12 months	Enterprise rollout; cross-plant benchmarking; predictive-maintenance signals	Sustained, provable OEE gain across the network

Why Phase 0 exists

The single most common failure of manufacturing AI programmes is that nobody can prove they worked.

OEE is seasonal, product-mix-dependent, and noisy. A two-point movement is statistically invisible without a properly established baseline. Phase 0 therefore exists primarily to measure the plant honestly, before the platform influences anything: the loss taxonomy, the unattributed residual, the changeover-overrun distribution, the handover time.

Those numbers become the contract against which value is later claimed. Skip this, and in eighteen months you will be in a room arguing about whether the thing worked, with no way to settle it.

Critical success factors

• A named plant sponsor — usually the Plant Head. Without one, OT access, reason-code cleanup, and supervisor adoption all stall.

  
  

• Downtime reason-code discipline. If operators do not key stoppage reasons, attribution degrades to "unattributed." Fixing this is often the cheapest early win — and the platform makes the gap visible enough that it gets fixed.

  
  

• Standard rates that are real. Many plants carry standard rates no line has achieved in years. Attribution against a fictional standard is meaningless. Reconcile in Phase 0.

  
  

• Supervisor involvement in design. She is the user. If she does not trust the root-cause output in the first two weeks, she will stop opening it, and the programme is over — no matter how accurate it actually is. Pilot with your most sceptical supervisor deliberately.

  
  

Part 8 — The Business Case, Honestly

For the reference enterprise — 6 plants, ~40 lines (of which ~14 are genuinely capacity-constrained), $1.2B revenue, ~62% OEE, ~120 supervisors:

Value driver	Annual range	Basis
Incremental throughput (constrained lines)	$11M–$19M	3–5 OEE points on ~14 constrained lines
Avoided scrap and rework	$2.0M–$3.6M	10–20% relative reduction on a 2.5% base
Reduced unplanned maintenance cost	$1.5M–$3.0M	Evidence-prioritized PM replacing run-to-failure
Recovered supervisory time	$2.2M–$3.2M	~120 supervisors × ~35 min/shift × 3 shifts × ~340 days
Recovered engineering / CI time	$1.0M–$2.0M	Loss taxonomy replaces manual data-gathering
Total	$17.7M–$30.8M	Payback 9–15 months

Now the part most vendors leave out.

Three ways this number is commonly inflated

1. Counting throughput you cannot sell. An OEE gain on a demand-constrained line converts to cost saving — less overtime, fewer shifts — not revenue. It is not worth the contribution margin of a sold unit. Our model counts only genuinely capacity-constrained lines, and that is why the throughput figure is $11M–$19M and not the $30M+ you could get by counting all forty lines. This is the single most common way manufacturing AI business cases are overstated, and we decline to overstate it.

2. Ignoring the reason-code prerequisite. In a plant where 40% of downtime is unkeyed, attribution — and therefore most of the value — is capped until that is fixed. Discoverable in Phase 0. Must be priced in.

3. Flattering the baseline. OEE baselines are frequently generous, because standard rates are soft or planned downtime is excluded inconsistently. A properly re-based baseline may show a lower starting OEE than the plant currently reports internally. This is a healthy outcome — but socialize it with leadership in advance, or your first honest measurement will look like a failure.

And one more, which is not about arithmetic at all: value accrues to behaviour change, not to software. The platform surfaces the action. A supervisor still has to take it. Adoption — not model accuracy — is the binding constraint on realized value. We have never seen this fail on the mathematics. We have seen it fail on the floor.

Part 9 — What It Looks Like in Use

The interaction model is best understood as a single shift.

08:12. Machine M12 on Line 3 stops. The platform sees the state change from the machine feed and correlates it with the andon reason code — tooling replacement — the moment it is keyed.

08:14. Line 3 moves to AT RISK on the supervisor's screen, with the projected shift impact already quantified. She did not have to be watching for this to reach her.

08:15. The platform notes that scrap on Line 3 had been rising for the previous thirty minutes — consistent with tooling wear — and attaches it as supporting evidence, explicitly labelled as a correlation, rather than firing it as a separate, unrelated quality alarm.

12:47. She asks, in plain language: "Why did Line 3 miss today's target?"

Line 3 is 119 units behind plan (76.7% attainment). Three causes, in order of impact: Machine M12 stopped for 42 minutes (08:12–08:54) carbide insert wear. ≈53 units lost. Operator changeover took 18 minutes longer than the 12-minute standard. ≈23 units lost. Material shortage delayed Batch B-142 by 26 minutes. ≈33 units lost. Also: the 14 scrap units logged 07:40–08:10 match the tooling-wear signature before the M12 stop.

Every number there is computed. Every claim cites a record. Nothing is generated.

12:48. She asks what to do, and gets ranked, quantified actions: reallocate one packer from Line 2 (which holds rate at reduced staffing for ~90 minutes) for ≈11 units recovered; expedite the raw stock for the next batch; raise a PM order against M12's inserts; coach the changeover crew against the standard.

13:55. She clicks Generate Shift Summary, reviews the drafted handover — output, OEE, event log, root cause, open risks, actions for nights — edits one line, and issues it. Two minutes, not forty.

That is the entire product. Everything in Parts 3 through 6 exists to make those six moments trustworthy.

Closing

The manufacturing sector does not have an AI problem. It has a decision-latency problem, wearing an AI-shaped costume.

The data is already there. The losses are already measurable. What has been missing is a system that reads all of it continuously, attributes the loss to a cause with evidence, and puts a ranked, quantified action in front of the one person who can still do something about it — while the shift is still running.

Building that is not primarily a modelling challenge. It is an architecture challenge: a unified plant model, a deterministic analytics engine, and a hard contract that keeps the language model on the right side of the line between phrasing an answer and inventing one.

Get that contract right, and a plant head will run a shift on it.

Get it wrong, and you will have built the most articulate liar on the factory floor.

Codersarts designs and delivers enterprise AI systems for manufacturing, including a working reference implementation of the AI Production Supervisor console described here — running a simulated plant, with every metric, insight, forecast and root-cause attribution computed live from the underlying data model. To discuss a discovery engagement for your plant network: build.codersarts.com · contact@codersarts.com