Redefining Technology

Manufacturing (Non-Automotive)AI Adoption & Maturity Curve

Manufacturing AI, lagging vs leading: the anatomy of a widening gap

The manufacturing AI gap is the widening divide between plants where every AI deployment makes the next one cheaper and plants where every deployment starts from zero. Lagging and leading are not budget levels — they are two operating loops, one that compounds and one that resets, and the loop can be changed.

Split factory scene contrasting a paper-and-clipboard production line with a sensor-instrumented, screen-guided line
Manufacturing (Non-Automotive) · AI Adoption & Maturity Curve

Key takeaways

  1. Lagging and leading manufacturers are separated by an operating loop, not a budget. Laggards run a pilot loop in which every project rebuilds its data, proves itself on a dashboard and evaporates; leaders run a deployment loop in which every use case leaves behind assets that make the next one cheaper.
  2. The gap compounds because the leading loop is self-funding: measured savings from one deployment pay for the next, the data exhaust of each use case trains the one after, and replication costs fall with every copy. A laggard standing still is therefore falling behind, even if nothing at its own plant has changed.
  3. The fork happens at the dashboard. Plants that stop when model output reaches a screen stay lagging regardless of model quality; plants that write output into the MES, CMMS or APS workflow — even with a human approving every action — enter the loop that compounds.
  4. You cannot leapfrog the connectivity floor. Buying a stage-5 AI platform for machines that publish no data is the single most common laggard error; the honest crossing starts with sensors, an OPC UA gateway and one shared downtime definition on one bottleneck line.
  5. The divide is observable in an afternoon. Where two teams get their OEE number, what a second deployment of the same use case cost, and what happens on the floor if the model stops — those three answers place a plant on one side or the other more reliably than any strategy document.

Abbreviations used on this page

MES
Manufacturing execution system
MOM
Manufacturing operations management
SCADA
Supervisory control and data acquisition
PLC
Programmable logic controller
HMI
Human–machine interface (the operator's screen)
OEE
Overall equipment effectiveness (availability × performance × quality)
CMMS
Computerised maintenance management system
ERP
Enterprise resource planning
APS
Advanced planning and scheduling system
OPC UA
Open Platform Communications Unified Architecture (the machine-data interoperability standard)
SPC
Statistical process control
DPM
Defects per million

Free · 8 questions · ~3 minutes

Which side of the divide is your plant on?

Eight questions, one at a time, about three minutes. Answer them and we build your gap report — which side of the divide your plant currently operates on, your score on each of the four dimensions that decide it, and the specific first crossing move for your weakest dimension — and send it to your inbox.

0 of 8 answered

Question 1 of 8Connectivity floor

What share of your production-critical machines publish data an application could subscribe to?

Everything on the leading side of the divide sits on machines that publish. No model can be fresher, broader or more trusted than the machine data underneath it.

How the score maps to a stage
  • 05 — Stage 1, Disconnected. Machines run well but publish nothing: production truth lives on paper, in spreadsheets and in the heads of long-serving operators.
  • 610 — Stage 2, Instrumented. Machines publish data into SCADA and a historian, but the data serves compliance and post-mortems rather than decisions: data rich, insight poor.
  • 1115 — Stage 3, Visible. The plant sees itself in near real time — shared OEE, live dashboards, first AI pilots — and stands at the fork where lagging and leading loops separate.
  • 1620 — Stage 4, Optimising. AI recommendations live inside the MES, CMMS and APS workflows of one site, savings are holdout-attributed, and the leading loop is running — locally.
  • 2124 — Stage 5, Compounding. The leading loop replicates across lines and sites with falling marginal cost — AI is standard work, and the plant's advantage grows while it sleeps.

What actually separates AI-lagging from AI-leading manufacturers

Not budget, not sector, not plant age — a loop. The definition, the divergence curve, and the two loops drawn side by side.

AI-leading manufacturers are separated from lagging ones by an operating loop, not by spending. A lagging plant runs a pilot loop: data is assembled by hand for each project, a model proves itself on a dashboard, attention moves on, and the assets evaporate — so the tenth attempt costs what the first did. A leading plant runs a deployment loop: model output is written into the MES, CMMS or APS workflow, the saving is measured against a holdout, the saving funds the next deployment, and every deployment leaves behind pipelines, definitions and templates that make the next one cheaper.

The distinction matters because the two loops have different mathematics. The pilot loop is flat: effort in, demonstration out, no residue. The deployment loop compounds: its outputs are also its inputs. That is why the gap between manufacturers widens rather than closes, and why it can widen while the lagging plant does everything conventionally right — runs pilots, hires data scientists, buys tools. The World Economic Forum and McKinsey, whose Global Lighthouse Network (opens in a new tab) documents the manufacturing frontier, found in the research that launched the network that more than 70% of industrial companies remain stuck in 'pilot purgatory' — the polite name for the lagging loop. The lighthouse plants are not running better pilots. They are not running pilots at all; they are running deployments.

Why the gap widens: value released against time in each loop

The curve is the leading loop's signature. Value stays near flat through the disconnected and instrumented stages, inflects when output first reaches a workflow, and steepens as replication costs fall — while the lagging loop's line stays flat at any level of pilot activity. Two plants of equal ability that make different wiring decisions at stage 3 are on different curves five years later.

Cumulative operational value released by stage

  • Stage 1 · Disconnected — 22% of operators. Machines run well but publish nothing: production truth lives on paper, in spreadsheets and in the heads of long-serving operators.
  • Stage 2 · Instrumented — 34% of operators. Machines publish data into SCADA and a historian, but the data serves compliance and post-mortems rather than decisions: data rich, insight poor.
  • Stage 3 · Visible — 26% of operators. The plant sees itself in near real time — shared OEE, live dashboards, first AI pilots — and stands at the fork where lagging and leading loops separate.
  • Stage 4 · Optimising — 14% of operators. AI recommendations live inside the MES, CMMS and APS workflows of one site, savings are holdout-attributed, and the leading loop is running — locally.
  • Stage 5 · Compounding — 4% of operators. The leading loop replicates across lines and sites with falling marginal cost — AI is standard work, and the plant's advantage grows while it sleeps.

Curve shape: logistic, plotted from the stage data above. Distribution: Consistent with WEF Global Lighthouse Network research.

The two loops, drawn end to end

The same plant, the same model quality, two different wirings. The lagging loop terminates at a screen and discards its assets; the leading loop terminates in a work queue and accumulates them. The fork is the third column.

  • Data & feeds
  • AI / model
  • Where value leaks
  • Human in the loop
  • System-of-record action

The process, in words

  • In the lagging loop, each project begins with a hand-built data extract, proves a model on backtest, and ships a dashboard because a dashboard needs no integration approval. Acting on it is a voluntary extra step, so adoption decays under production pressure; when the champion moves on, the code, mappings and lessons are discarded and the next pilot starts from zero. The loop can repeat indefinitely at constant cost.
  • In the leading loop, a connected line feeds a shared data layer with one agreed OEE and downtime definition. The model's output lands as draft work orders in the CMMS queue the maintenance planner already processes; every approval and override is logged. The saving is measured against a holdout, which makes it a number finance will sign, and by standing agreement it funds the next deployment — which installs the templated pipeline at a fraction of the original cost.
  • The fork is the third column. Everything upstream of it can be identical in both loops — same sensors, same historian, same model. The wiring decision at the dashboard is what assigns a plant to a loop, and the loop is what compounds or resets everything that follows.
Step-by-step insights
The hand-built extract — why the tenth pilot costs like the first
Every lagging-loop project starts by reconstructing the world: exporting historian tags, joining them to product and recipe context by hand, and encoding one engineer's private cleaning decisions that the next project will not inherit. The extract is stale on arrival and unrepeatable by design. This is why pilot count is such a poor maturity signal — a plant can run ten pilots and accumulate nothing, because the expensive first step is re-performed every time and thrown away every time.
The dashboard — the most expensive cheap decision in manufacturing AI
The dashboard is chosen because it is fast: no change control, no MES vendor conversation, no validation protocol. But it converts the model's output into an optional reading assignment for people whose day is already full. Optional steps are the first casualties of production pressure, and peak demand — precisely when the model is worth most — is when glancing at the extra screen reliably stops. No standard operating procedure changes because a chart exists; the plant's decision-making remains exactly as it was, now with better decoration.
The CMMS queue — why write-back changes the physics
Writing predictions in as draft work orders inverts the default. The planner does not have to remember to consult the model; the model's output is simply part of the queue their job already consists of processing. The burden moves from the human's discipline to the system's design, which is the same move manufacturing made when it put quality checks into the line rather than trusting end-of-line vigilance. A recommendation with a 70% acceptance rate inside the queue changes more maintenance decisions than a 95%-accurate model on a wall screen.
The override log — the leading loop's hidden asset
Every planner override, logged with a reason, is a labelled training example and a governance artefact at once. Over months the log shows exactly which prediction classes the human always accepts — the future candidates for bounded automation — and which they correct, which is where the next model version improves. Lagging-loop plants have no equivalent asset: a dashboard records at best that it was viewed. When leaders later automate narrow decision classes safely, the evidence justifying it is this log, accumulated as a by-product.
The holdout — the difference between a saving and a story
Attributing improvement in a live plant is genuinely hard: demand mix shifts, crews rotate, a changeover programme lands mid-quarter. The leading loop's answer is the holdout — a comparable line, bank or shift kept on the old process. The delta against it is a number a finance director will accept without goodwill, and that acceptance is what lets the saving fund the next deployment without a fresh capital case. Lagging-loop value claims, computed against last year's average, dissolve under the first serious budget challenge.
The template — where compounding becomes visible
The step most programmes never take is turning the first deployment into a package: the data contract, the gateway spec, the tag-mapping method, the CMMS adapter, the monitoring config, the holdout design, the runbook. It is unglamorous work with no demo at the end, which is why it is skipped — and it is the entire difference between linear and compounding economics. When the second line installs from the template at a fraction of the original cost, the plant has left the world where AI capability is proportional to effort and entered the one where it accumulates.

The five stages between lagging and leading

Disconnected, Instrumented, Visible, Optimising, Compounding — for each: what it looks like on the floor, the signals a reviewer can check in an afternoon, the anti-pattern that traps plants there, and what leaving costs.

The ladder below maps the ground between the two loops, and its shape explains the gap: stages 1 and 2 are the lagging mass, stage 3 is the fork where the wiring decision assigns a plant to a loop, and stages 4 and 5 are the leading loop running and then compounding. It is deliberately consistent with the structure of established manufacturing maturity frameworks — the acatech Industrie 4.0 Maturity Index (opens in a new tab) in particular, whose stages run from computerisation and connectivity through visibility and transparency to predictive and self-optimising operation — but it is drawn from the gap's point of view: what matters at each stage is which loop it feeds. Each stage is written for a practitioner; the diagnostic signals are checks you can run against your own plant this week.

Select a stage

Every stage's full detail is in the page source — the selector only changes which panel is visible, so nothing here depends on JavaScript to exist.

Stage 1

Disconnected

22% of operators sit here

Machines run well but publish nothing: production truth lives on paper, in spreadsheets and in the heads of long-serving operators.

Stage 1 is not a technology failure — most disconnected plants are competently run and some are very profitable. What defines the stage is that the plant produces no machine-readable record of its own behaviour. The PLCs cycle, the line runs, the product ships, and none of it leaves a trace an application could learn from. Every improvement conversation therefore starts with anecdote: the filler 'always' struggles on Mondays, the oven 'tends to' drift in summer, line 3 'never' hits rate on the thin-gauge material.

The economics of the stage are deceptive because the cost is invisible. Nothing fails loudly; the plant simply pays a permanent tax in the form of questions it cannot answer. Which machine loses the most availability? Nobody can say without a two-week clipboard study. Did last quarter's changeover programme actually reduce downtime? The data to answer was never captured. In a disconnected plant, every argument is settled by seniority rather than by measurement, and the improvement agenda belongs to whoever argues best.

The exit is cheaper than most stage-1 leaders assume, because it is deliberately narrow. The move is not a plant-wide digitisation programme — it is instrumenting one bottleneck line well enough to answer one question. Retrofit sensing on the three worst machines, an OPC UA gateway, a historian, one agreed set of downtime codes. Plants that frame the exit this way cross in a quarter; plants that frame it as 'Industry 4.0 transformation' write a strategy deck instead and are still at stage 1 two years later.

In practice

The Monday filler mystery

A mid-sized beverage plant knew its bottleneck filler underperformed on Mondays — every veteran operator agreed. When the line was finally instrumented, the data showed Monday availability was normal; the real loss was a slow creep in micro-stops every day after the Thursday CIP clean, invisible because each stop was under the two-minute threshold anyone bothered writing down. Years of Monday-focused interventions had been aimed at folklore. The clipboard had not lied; it had simply never been able to see events that small.

What it looks like

  • Downtime is logged on clipboards or reconstructed from memory at shift end
  • PLCs and machine controllers run isolated, with no route off the machine
  • OEE, if computed at all, is a monthly spreadsheet exercise with contested inputs
  • The most valuable process knowledge retires when a senior operator does

Diagnostic signals you can check this week

  • Ask for last month's downtime Pareto for the bottleneck line — if it takes more than a day to produce, the plant is disconnected
  • Walk the line and count machines whose only output is a stack light and an HMI nobody logs
  • Ask two shifts for the line's OEE and compare both the numbers and the definitions
  • Ask what would be lost if the most senior operator retired next month — if the answer is 'the line', the process knowledge is uncaptured

Anti-pattern · The transformation deck

The instinctive stage-1 response is a plant-wide digitisation strategy: every machine connected, a data lake, an AI roadmap, a three-year plan. It fails because it prices the whole journey before the plant has learned what its own data is worth, and the capital request dies in review — or worse, is approved and spent on connecting a hundred machines nobody has a question for. Instrument one line to answer one question. The plant-wide case writes itself once the first line has a number attached.

What holds you here

There is no machine-readable signal to learn from, so no AI of any sophistication has anything to work with.

Highest-leverage next move

Retrofit sensing and an OPC UA gateway on one bottleneck line, with one agreed set of downtime codes — a line, not a plant.

Cost of leaving

Effort
3–6 months for the first instrumented line
Team
One controls engineer and one process engineer, part-time; a gateway and sensor budget in the tens of thousands, not millions
Risk
Low — retrofit sensing is additive and touches no control logic
To next stage
3–6 months

If this is you, the next step is

A two-week engagement: pick the line, spec the retrofit, size the historian.

Scope the first instrumented line

Stage 2

Instrumented

34% of operators sit here

Machines publish data into SCADA and a historian, but the data serves compliance and post-mortems rather than decisions: data rich, insight poor.

Stage 2 is the largest single population in manufacturing and the easiest to misread from the outside, because the plant looks digital. SCADA screens glow in the control room, the historian ingests thousands of tags, quality records are electronic. The tell is what the data is for: it is written far more than it is read, and read almost exclusively backwards — for an audit, a customer complaint, a post-incident investigation. The plant has built the sensory apparatus of a leading operation and connected it to nothing that decides anything.

The structural problem is context, not collection. Historian tags carry values without meaning: pressure_04 spiked at 14:02, but which product was running, which recipe, which crew, whether the spike was during changeover — reconstructing that context takes an engineer half a day per question, so questions go unasked. Meanwhile every department that touches the data has evolved its own definitions. Production's OEE excludes planned maintenance, engineering's does not, finance computes a third number for the board pack. None of them is wrong; there is no shared definition to be right about, and every cross-department improvement discussion begins with an argument about whose number is real.

This is also the stage where AI pilots begin, and where the fork ahead is set up. A pilot built on hand-cleaned historian exports can absolutely produce a good model — that is precisely what makes stage 2 sticky. The model works, the deck lands, and the organisation concludes it is 'doing AI' while the loop that would make the second model cheaper than the first — shared definitions, contextualised data, a route into a workflow — remains unbuilt. Stage 2 plants do not lack proof that AI works. They lack anywhere for it to live.

In practice

Ten thousand tags, one spreadsheet

A speciality chemicals site had eight years of historian data across roughly ten thousand tags — and its batch-release decisions ran on a spreadsheet maintained by one senior process engineer, who exported a dozen tags each morning and applied judgement built over twenty years. When a data science consultancy asked for training data for a yield model, producing a clean, context-joined dataset for one production unit took eleven weeks. The model that followed was good. The eleven weeks were the actual finding.

What it looks like

  • A historian holds years of tag data almost nobody queries
  • Each department computes its own version of OEE, downtime and yield
  • Data leaves the historian as hand-cleaned exports for specific investigations
  • The gap between what is collected and what is used widens every year

Diagnostic signals you can check this week

  • Count historian read queries against write volume — a read:write ratio near zero is the stage-2 signature
  • Ask three departments for the site's OEE and count the distinct definitions
  • Time how long it takes to produce a context-joined dataset (product, recipe, crew, events) for one line for one month
  • Ask when the historian last changed a decision inside the same shift as the data

Anti-pattern · Collecting harder

The stage-2 reflex is more instrumentation: more sensors, more tags, a bigger historian, on the theory that insight will condense out of sufficient data. It will not. The binding constraint is shared meaning — one OEE, one downtime code set, context joined to tags — and no volume of additional collection supplies it. A plant that spends the next budget cycle on definitions and context modelling, guided by frameworks like ISA-95 and the acatech Maturity Index, gets more from the tags it already has than a plant that doubles its tag count.

What holds you here

Data is collected without shared definitions or context, so every use of it is a bespoke archaeology project.

Highest-leverage next move

Agree one plant-wide definition of OEE and downtime causes, and contextualise historian data for one value stream — meaning before more measurement.

Cost of leaving

Effort
6–12 months
Team
A process engineer and a data engineer as a standing pair, plus department leads for the definition work — the hard part is agreement, not technology
Risk
Low technically, moderate politically — shared definitions dethrone somebody's spreadsheet
To next stage
6–12 months

If this is you, the next step is

We facilitate the OEE and downtime-code agreement and build the context model around your existing historian.

Get the definition layer built

Stage 3

Visible

26% of operators sit here

The plant sees itself in near real time — shared OEE, live dashboards, first AI pilots — and stands at the fork where lagging and leading loops separate.

Stage 3 is a genuine achievement and a genuinely dangerous place to rest. The plant that reaches it has done the unglamorous work: definitions agreed, context modelled, dashboards trusted enough that the morning meeting argues about causes rather than numbers. Waste is visible, and visibility alone usually buys a real one-off improvement as the obvious losses get actioned. That improvement is also the trap, because it feels like the payoff when it is actually the entry fee.

This is the fork of the whole curve, and what forks is a wiring decision that looks minor at the time. The pilot's output can terminate on a dashboard, or it can be written into the system that runs the decision — a predicted-failure work order in the CMMS queue, a recommended setpoint in the MES, a revised sequence in the APS. The dashboard path is faster, needs no integration approval and no argument with the MES vendor, so it is the path most plants take. It is also, on the evidence of the whole industry, the path that leads back to the start: dashboard adoption depends on a person voluntarily adding a step to their day, that discipline decays under production pressure, the pilot's champion moves on, and eighteen months later a new pilot starts from zero. That is the lagging loop, and stage-3 plants run it with excellent data.

The plants that cross take the slower path: one model, one workflow, one write-back, with a human approving every action and a one-switch fallback to the old process. It is politically harder — writing into the MES means change control, validation in regulated environments, and a conversation with operations about trust. But it changes the physics of the programme. Output that lands in a work queue gets consumed as part of the job rather than checked as a favour; the approval log starts accumulating the evidence that later justifies autonomy; and the pipeline built for the first write-back is the template the second use case reuses. The gap between manufacturers does not open at stage 5. It opens here, at the dashboard.

In practice

Two plants, one pilot, two loops

Two sites of the same packaging group ran near-identical unplanned-downtime pilots on their corrugators, and both models cleared their accuracy targets. Site A surfaced predictions on a wall dashboard; operators glanced at it for a month, then peak season arrived and nobody looked again — two years later Site A commissioned a fresh 'predictive maintenance initiative' from a different vendor. Site B pushed the same predictions as draft work orders into the CMMS, where the maintenance planner approved or rejected each one. Site B's planner overrides fed the retrain set; its second use case, on the die cutters, reused the whole pipeline and shipped in six weeks. Same model. Different loop.

What it looks like

  • One agreed OEE and downtime definition, computed automatically, trusted across departments
  • Live line dashboards on the floor and in the morning meeting
  • At least one AI pilot has beaten its baseline on historical data
  • Model output still terminates on a screen — no MES, CMMS or APS write-back yet

Diagnostic signals you can check this week

  • Find the most advanced model on site and trace where its output physically lands — screen or system of record
  • Count standard operating procedures changed by any pilot in the last two years; zero means the lagging loop
  • Ask whether any model's recommendations appear in a work queue someone already processes as part of their job
  • Check whether the current pilot's data pipeline reuses anything from the previous pilot

Anti-pattern · One more pilot to build confidence

When a stage-3 pilot stalls at the dashboard, the common conclusion is that the organisation 'is not ready' and needs another, better pilot to build belief. Each successive pilot re-proves what the last one proved, consumes the goodwill of the operators asked to check yet another screen, and teaches the organisation that AI produces demonstrations rather than change. Confidence does not come from a fourth pilot; it comes from the first recommendation that arrives inside the CMMS queue with a fallback switch the planner controls. Integration is the confidence-building measure.

What holds you here

Model output terminates on dashboards, so acting on it is voluntary — and voluntary steps decay under production pressure.

Highest-leverage next move

Write one model's output into the MES, CMMS or APS workflow it serves, with human approval on every action and a one-switch fallback.

Cost of leaving

Effort
3–9 months for the first write-back
Team
One integration engineer, one ML engineer, the MES/CMMS owner, and a named production or maintenance owner whose KPI moves with the model
Risk
Medium — the first write into a production system needs change control, a validation path in regulated plants, and a drilled rollback
To next stage
6–12 months

If this is you, the next step is

We map the shortest path from your best existing model into the MES or CMMS workflow it belongs in.

Scope your first write-back

Stage 4

Optimising

14% of operators sit here

AI recommendations live inside the MES, CMMS and APS workflows of one site, savings are holdout-attributed, and the leading loop is running — locally.

Stage 4 is where the programme's character changes from analytical to operational. The questions that matter are no longer about model accuracy — they are about freshness alerting on the gateway feeds, drift behaviour across product changeovers, who is paged when the scrap-prediction service degrades, and how the quarterly saving is attributed when three initiatives touched the same line. Plants at this stage talk about their AI the way they talk about their utilities: mostly invisible, occasionally on fire, owned by someone specific.

The economics are now visibly different from the lagging loop. A deployed use case pays a measured, holdout-attributed return; that return funds the next deployment without a fresh capital case; and the operators' relationship with the system has shifted from being shown insights to processing recommendations — accepting most, overriding some, and generating with every override the labelled data that makes the next model version better. This is the compounding mechanism in miniature, and once a site has run it two or three times the internal argument about whether AI 'works here' simply ends.

What stage 4 has not yet solved is replication. The loop runs on one site because it was hand-built for that site: this historian's quirks, this MES vendor's API, this planner's queue. Copying the downtime use case to the sister plant means rediscovering all of it, and the copy costs eighty per cent of the original. That is the boundary between stage 4 and stage 5, and it is where most leading-loop programmes stall — not for want of ambition, but because templating your own work is nobody's urgent job. The plants that pull away are the ones that treat the second copy as a product decision: extract the template, standardise the interfaces, write the replication sheet, and make the next site a configuration exercise.

In practice

The saving that funded its successor

A food-processing site ran predicted-failure work orders into its CMMS for the ammonia compressors on its refrigeration plant, holding out one compressor bank on the old preventive schedule. Two quarters of attribution showed a meaningful availability gain and a maintenance-cost reduction on the covered banks, and the delta — signed off by finance because the holdout made it defensible — directly funded the next deployment, a changeover-sequencing model in the APS. No new business case meeting occurred. That is the leading loop working: the first use case bought the second.

What it looks like

  • Recommendations arrive in work queues operators and planners already process
  • Every deployed use case has a named operational owner and a holdout-attributed saving
  • Approval and override logs are monitored and feed retraining
  • Each new line or sister site is still a mostly hand-built project

Diagnostic signals you can check this week

  • Pick a deployed use case and ask for its holdout design and last quarter's attributed number
  • Check whether overrides are logged with reasons and whether the retrain set consumes them
  • Ask who was paged the last time a model or feed degraded, and when the fallback was last drilled
  • Ask what fraction of the last deployment was reused from the one before — below a third means replication economics are unproven

Anti-pattern · Scaling by heroics

The stage-4 mistake is copying use cases to new lines and sites by throwing the original team at each copy. It works for the first two copies, reads as momentum, and quietly turns the plant's best engineers into a bottleneck while every copy stays as expensive as the original. The tell is a roadmap that grows while delivery slows. The fix is unglamorous: stop deploying for one cycle, extract the template — data contract, integration adapters, monitoring, runbook — and re-price the next copy. If it is not markedly cheaper than the first, the template is not done.

What holds you here

Every copy of a use case is a hand-built project, so scale is bounded by the original team's capacity.

Highest-leverage next move

Template the best use case — data contract, adapters, monitoring, runbook — and prove the copy costs a fraction of the original.

Cost of leaving

Effort
12–24 months to proven replication
Team
A small platform team owning the template, plus site pairs (process engineer + operator lead) for each rollout
Risk
Medium — the template must survive contact with a second MES vendor and a differently-opinionated historian
To next stage
12–24 months

If this is you, the next step is

We turn your best deployed use case into the package the next line and next site install.

Design your replication template

Stage 5

Compounding

4% of operators sit here

The leading loop replicates across lines and sites with falling marginal cost — AI is standard work, and the plant's advantage grows while it sleeps.

Stage 5 is what the lighthouse plants documented by the World Economic Forum's Global Lighthouse Network have in common, and it is less futuristic than its reputation. The defining property is not autonomy or lights-out operation — plenty of compounding plants keep a human on every consequential decision. It is that deployment has become standard work: a template library holds the proven use cases, a replication sheet tells a new site what to install and what to measure, and the marginal cost of the next deployment falls with each one shipped. The plant has industrialised its own improvement, which is the most manufacturing-native idea imaginable — it is what the industry did to production itself a century ago, applied to its decision-making.

Autonomy, where it exists, is narrow and evidence-bound. A compounding plant lets specific enumerated decisions — a setpoint nudge inside SPC limits, a routine reorder, a schedule swap below a value threshold — execute without approval, because months of approval logs showed the human accepting effectively all of them. Everything else escalates. The decision policy is versioned and reviewed like code, the audit trail can reconstruct any automated action months later, and the kill switch is drilled. In regulated non-automotive sectors — food, pharma adjacent, aerospace suppliers — this evidentiary discipline is not overhead on the way to autonomy; it is the thing that makes any autonomy permissible at all.

The uncomfortable property of stage 5 is what it does to everyone else, and it is why this page is about a gap rather than a ladder. A compounding plant's advantage grows without further strategic decisions: each deployment cuts cost or lifts yield, funds the next, and enlarges the data and template estate that makes the next cheaper. A lagging competitor is therefore losing ground during quarters in which it makes no mistake whatsoever. The gap is not a ranking that updates when you act; it is a differential equation that runs continuously. That is the strategic case for crossing early, and for crossing on one line rather than waiting for the perfect plant-wide moment.

In practice

The eleventh deployment

A multi-site industrial group's eleventh deployment of its downtime-prediction template — at a plant acquired eighteen months earlier, running a different MES vendor than the original site — was installed by the receiving plant's own engineers from the replication sheet, with the central team advising for a handful of days. Gateway spec, tag mapping, downtime codes, CMMS adapter, monitoring, the holdout design for attribution: all of it arrived as a package. The first deployment, years earlier, had taken three quarters. The eleventh took five weeks, most of it waiting on the change-control calendar.

What it looks like

  • New deployments are configuration from a template library, shipped in weeks
  • A model registry, site playbooks and versioned decision policies govern the estate
  • Bounded decisions execute without approval inside audited thresholds; exceptions escalate
  • Cost per deployed use case falls year on year and is itself tracked as a KPI

Diagnostic signals you can check this week

  • Ask for cost per deployed use case over the last three years — flat or rising means stage 4 wearing a stage-5 badge
  • Check whether a new site could deploy from documentation alone, without the founding team
  • Ask for the decision policy's version history and the date of the last kill-switch drill
  • Check whether an auditor could reconstruct one automated action end to end from logs

Anti-pattern · Confusing the showcase for the estate

The stage-5 failure mode is the lighthouse that illuminates nothing: one magnificent site used for tours and press while sister plants run at stage 2, with no replication sheet because the showcase was built by heroics that were never written down. The group reports leading-edge capability and operates a lagging estate. The corrective is to measure the estate, not the exhibit — cost per deployment across all sites, share of sites on the template, time for the newest site to first attributed saving — and to fund the boring replication work with the same seriousness as the showcase.

What holds you here

Sustaining compounding is a governance discipline — thresholds drift out of validity, templates rot, and the estate quietly diverges from the showcase.

Highest-leverage next move

Track cost per deployment and estate coverage as first-class KPIs, and re-baseline decision policies on a fixed review calendar.

Cost of leaving

Effort
Continuous
Team
A platform team owning templates and registry, a standing governance forum for decision policies, and site-level owner pairs
Risk
Concentrated — governance drift and threshold complacency; low frequency, high consequence

If this is you, the next step is

We stress-test the template library, replication economics and decision-policy evidence against a real scenario.

Audit your compounding loop

Where manufacturers actually sit — and why the middle is emptying

The distribution across the ladder, the adoption-versus-impact paradox behind it, and the reason time makes the shape worse.

Most non-automotive manufacturers sit at stages 2 and 3 — instrumented or visible, running the lagging loop with increasingly good data. The paradox of the last few years is that AI adoption has become nearly universal while attributable impact has not: McKinsey's State of AI research (opens in a new tab) has tracked reported AI use climbing to more than three-quarters of organisations, while the share reporting material bottom-line impact remains a small minority. In manufacturing terms: almost everyone now has a pilot to point to, and few have a number finance has signed. The gap page's claim is that these are not points on one queue, with laggards simply further back — they are populations in two different loops, which is why the distribution's middle empties over time rather than flowing forward evenly.

Distribution of manufacturers across the five stages

Illustrative distribution, synthesised from McKinsey State of AI adoption research, WEF Global Lighthouse Network publications and MHI's annual industry survey — drawn to show the shape practitioners consistently report: a lagging mass at stages 2–3, a thin leading tail, and a fork rather than a queue between them.

Share of plants

  • 22% — 1 · Disconnected
  • 34% — 2 · Instrumented (the lagging mass)
  • 26% — 3 · Visible (the fork)
  • 14% — 4 · Optimising
  • 4% — 5 · Compounding (the leading tail)

Source: Illustrative, synthesised from McKinsey, WEF and MHI adoption research

Two further features of the distribution matter for anyone deciding what to do about it. First, the leading tail is thin but not exclusive: the Global Lighthouse Network (opens in a new tab) includes brownfield sites decades old and plants in every region and sector, and — as the Schneider Electric case below shows — a 1950s plant can cross. Second, the lagging mass is not idle; MHI's annual industry report (opens in a new tab) has tracked consistently high stated adoption intent across manufacturing and supply-chain operations for years. Intent and activity are abundant on the lagging side of the divide. What is scarce is the loop — and for smaller manufacturers without a platform team to build one, programmes such as NIST's Manufacturing Extension Partnership (opens in a new tab) exist precisely to make the crossing affordable at SME scale.

Where the gap actually lives: five layers of the plant stack

Lagging and leading practice compared layer by layer — sensing, connectivity, data, decisions, replication — with the afternoon tell for each, the decision map, and the leapfrog trap.

The gap lives in five specific layers of the plant stack, and at every layer the lagging and leading practices are concretely different — different enough that a reviewer can place a plant in an afternoon without a questionnaire. The layers follow the classic ISA-95 automation hierarchy (opens in a new tab) from the machine upward into the MES/MOM layer that MESA's model describes (opens in a new tab), plus a fifth layer — replication — that no automation standard covers and that decides more of the gap than the other four combined.

LayerLagging practiceLeading practiceThe afternoon tell
Sensing & machinesMachines run isolated; downtime and quality events logged on paper or at shift end from memoryCritical assets instrumented, including retrofit sensing on pre-digital machines; events captured as they occurAsk for yesterday's micro-stop count on the bottleneck line — leading plants answer from a system in minutes
ConnectivitySCADA islands; data stays in the control layer; exports are manual and per-requestOPC UA gateways route machine data continuously to a historian and onward, with freshness monitoredAsk what happens when a feed silently stops — leading plants name the alert and the person paged
Data layerEach department computes its own OEE, downtime and yield; context lives in engineers' headsOne governed definition per metric, aligned to ISO 22400; tags contextualised with product, recipe and crewAsk two departments for the same line's OEE — leading plants produce one number, laggards produce a negotiation
Decision layerAnalytics terminate on dashboards and in decks; acting on them is voluntaryModel output lands in MES, CMMS and APS work queues with approval, override logging and a drilled fallbackTrace the best model's output to where it physically lands — screen or queue settles the layer in one walk
ReplicationEach project is a one-off; assets are discarded between pilots; copies cost as much as originalsTemplates, adapters and replication sheets make each copy markedly cheaper; cost per deployment is trackedAsk what the second deployment of the same use case cost relative to the first — the answer is the loop
The gap, layer by layer. The 'afternoon tell' is a check a reviewer can run in a site visit without instruments or interviews beyond the floor.

Read the table bottom-up and the strategic point appears: the layers gate each other downward but pay upward. A plant cannot have leading decision integration on a lagging data layer, or a real data layer on disconnected machines — which is why leapfrogging fails. But the value concentrates at the top: sensing and connectivity are costs until the decision and replication layers exist to monetise them, which is why so many stage-2 plants feel they have spent heavily on digital and received nothing. They have built the bottom of a leading stack and wired it to a lagging loop.

DomainHigh-value decisionsSystem of recordKPI it movesCrossing order
Maintenance & reliabilityPredicted-failure work orders, PM interval tuning, spares triggeringCMMSUnplanned downtime, OEE availability1
QualityVision inspection dispositions, SPC limit tuning, scrap-cause attributionMES / QMSFirst-pass yield, DPM, scrap cost2
Process controlSetpoint recommendations, changeover recipes, drift compensationSCADA / MESRate, giveaway, energy per unit3
Planning & schedulingSequence optimisation, changeover clustering, labour rosteringAPS / ERPSchedule adherence, changeover hours4
Energy & utilitiesCompressor and chiller staging, peak-load shifting, idle-state enforcementSCADA / energy managementkWh per unit, peak demand charges5
Inventory & materialsReorder points, WIP buffer sizing, material substitution approvalsERP / MESStock turns, WIP value, stockouts6
Where the leading loop lands first in a non-automotive plant: the decision map. 'Crossing order' reflects typical approval friction and attribution speed — start where the system of record is yours and the KPI is undisputed.

The leapfrog trap: ambition against the connectivity floor

Plot the sophistication of what you are buying against the share of your machines that actually publish data. Three quadrants have honest exits; one is where lagging plants burn their credibility.

The leapfrog trap

  • Plant-wide AI platform bought for machines that publish nothing
  • Integrators discover the missing floor mid-project; scope collapses to a demo line
  • Exit: stop, and spend one quarter on the floor for one line instead

The leading loop

  • Ambition matched by a floor that can carry it
  • Deployments land in workflows and replicate
  • Keep: track cost per deployment so compounding stays honest

The honest laggard

  • Modest ambition, modest floor — the correct starting posture
  • One line, one decision, one quarter
  • Exit: the 90-day crossing plan below

The underreaching leader

  • Strong floor serving only dashboards
  • Common in well-instrumented process plants — stage 3 wearing stage 2 ambitions
  • Exit: pick the first write-back; the hard work is already done
Ambition of the initiative — top: Optimise the plant, bottom: Assist one decision
Connectivity floor — left: Machines publish little or nothing, right: Machines publish, contextualised

The divide in public: three plants read against the ladder

A three-decade leader, a 1950s brownfield that crossed, and the frontier's narrow edge — outcomes as reported by the operators and the WEF Global Lighthouse Network.

The public record of the divide is best read as three positions, not three anecdotes: what decades of compounding produce, what a lagging brownfield can do about it, and what the frontier's edge actually looks like up close. None of these is an Atomic Loops engagement; outcomes are as reported in the operators' own material or through the World Economic Forum's Global Lighthouse Network, which designated each site, and figures should be verified against the linked sources before reuse.

Three positions on the divide

Outcomes as reported by the operators and the WEF Global Lighthouse Network; we have not independently audited them. Images are illustrative industrial scenes from our generated library, not operator-supplied photography.

Electronics manufacturing line scene with automated placement machines and inspection stationsSiemens — Amberg Electronics PlantElectronics · PLC production, Germany35
Challenge
Producing an ever-wider variant mix of Simatic controllers on a fixed footprint without sacrificing the near-zero defect rates its own customers buy the product for.
Approach
Three decades of accumulated closed-loop digitisation on one site: product and process data captured at every station, quality decisions progressively automated, and AI applied where it pays — Siemens has publicly described AI-supported X-ray inspection scheduling and closed-loop process control among Amberg's use cases.
Reported outcome
Siemens has publicly reported that Amberg produces a large multiple of its early-1990s output on the same floor space with a broadly stable workforce, at quality levels above 99.99% — figures the company presents alongside the plant's designation to the WEF Global Lighthouse Network.
What it shows about the curveThe gap is loop-age, not budget. Amberg's advantage is thirty years of the leading loop running on one site — each improvement instrumented, retained and built upon. A competitor cannot buy that position; it can only start its own loop earlier rather than later.

Siemens press (landing) (opens in a new tab)

Retrofitted industrial plant scene with energy monitoring panels beside older production equipmentSchneider Electric — Lexington, KentuckyElectrical equipment · brownfield plant operating since 195824
Challenge
A plant more than sixty years old, full of pre-digital equipment, competing inside a group whose newest sites were built connected — the textbook lagging-brownfield position.
Approach
Retrofit rather than rebuild: Schneider publicly describes instrumenting the existing estate with its own EcoStruxure stack — power metering, connected sensors on legacy machines, predictive maintenance and digital lean tools feeding the workflows of the teams already running the plant.
Reported outcome
Schneider has publicly reported material reductions in energy use and unplanned downtime at Lexington, and the site was designated to the WEF Global Lighthouse Network — one of the network's demonstrations that decades-old brownfield plants can reach the frontier.
What it shows about the curveBrownfield is not destiny. The connectivity floor can be bought line by line on a 1950s estate, and the crossing move is the same as this page's 90-day plan — instrument, integrate into the existing teams' workflows, attribute, then replicate.

Schneider Electric blog (landing) (opens in a new tab)

Darkened automated production floor scene with robotic cells running under minimal lightingFoxconn — Shenzhen 'lights-out' factoryElectronics · precision components, China45
Challenge
Labour-intensive precision component production with high volumes and tight tolerances — the classic case where full automation is tempting and usually premature.
Approach
A bounded 'lights-out' operation: fully automated production lines running with minimal on-floor staffing, machine-learning-driven process control and automated optical inspection, applied to a deliberately constrained product scope where the process is stable enough to run dark.
Reported outcome
Through the WEF Global Lighthouse Network, which designated the Shenzhen site among its earliest lighthouses, Foxconn's reported results include production efficiency improvements of around 30% alongside reduced inventory cycles.
What it shows about the curveThe frontier is narrow, and that is the point: even the most automated lighthouse runs dark only where the product mix and process stability justify it, with humans on exceptions. Stage 5 is bounded decisions executing on evidence — not a dark building, and not a target for plants that have yet to run the loop once.

WEF Global Lighthouse Network (opens in a new tab)

The minimum leading stack, layer by layer

What actually has to exist at each stage of the crossing — defined by what each layer must guarantee, not by any vendor's product map.

The stack a lagging plant needs in order to cross is smaller than the stack vendors will quote for, and it is best defined by guarantees rather than products: each layer exists when the thing it must guarantee is true, whoever supplies it. The architecture below is annotated with the stage that first requires each layer — which is also the order to build in, because every attempt to build a higher layer before its floor exists ends in the leapfrog quadrant of the matrix above.

Layers required by stage

Build bottom-up, monetise top-down. A plant targeting the leading loop without the decision and replication layers is building a very well-instrumented lagging loop.

  1. Machines & sensing

    Stage 1+

    • PLCs & machine controllersThe signals that already exist, surfaced
    • Retrofit sensorsVibration, current, temperature on pre-digital assets
    • Operator event captureDowntime reasons at the HMI, not the clipboard
  2. Connectivity

    Stage 2+

    • OPC UA gatewayOne standard route off the machines
    • Historian / time-series storeContinuous capture with retention
    • Freshness monitoringA silent feed pages a named person
  3. Shared data layer

    Stage 3+

    • Governed definitionsOne OEE, one downtime code set — ISO 22400-aligned
    • Context modelTags joined to product, recipe, crew and events
    • Lineage & ownershipEvery metric has a named owner
  4. Decision layer

    Stage 4+

    • Served modelsDrift-monitored, retrained on a calendar the plant recognises
    • Workflow write-backCMMS work orders, MES holds, APS sequences
    • Approval & fallbackOverrides logged; the old process one switch away
  5. Replication layer

    Stage 5+

    • Template libraryData contracts, adapters, monitoring configs, runbooks
    • Model registry & decision policiesVersioned, reviewed, auditable
    • Replication sheetWhat the next line or site installs, and what it must measure

Pipeline described

  1. Machines & sensing (stage 1+) — PLCs & machine controllers: The signals that already exist, surfaced; Retrofit sensors: Vibration, current, temperature on pre-digital assets; Operator event capture: Downtime reasons at the HMI, not the clipboard
  2. Connectivity (stage 2+) — OPC UA gateway: One standard route off the machines; Historian / time-series store: Continuous capture with retention; Freshness monitoring: A silent feed pages a named person
  3. Shared data layer (stage 3+) — Governed definitions: One OEE, one downtime code set — ISO 22400-aligned; Context model: Tags joined to product, recipe, crew and events; Lineage & ownership: Every metric has a named owner
  4. Decision layer (stage 4+) — Served models: Drift-monitored, retrained on a calendar the plant recognises; Workflow write-back: CMMS work orders, MES holds, APS sequences; Approval & fallback: Overrides logged; the old process one switch away
  5. Replication layer (stage 5+) — Template library: Data contracts, adapters, monitoring configs, runbooks; Model registry & decision policies: Versioned, reviewed, auditable; Replication sheet: What the next line or site installs, and what it must measure
Step-by-step insights
Machines & sensing — the floor is cheaper than its reputation
The lagging plant's mental price for connectivity is set by plant-wide programme quotes, and it is wrong at the line level. Retrofit vibration and current sensing on the three worst machines of one line, plus downtime-reason capture at the HMI, is a tens-of-thousands purchase, not a transformation budget. The discipline that matters is honesty about what to instrument: the bottleneck line's biggest availability losses, not the newest machine or the easiest port.
Connectivity — one standard route beats five clever ones
The OPC UA gateway earns its place by being boring: one standard way for machine data to leave the control layer, one place to monitor freshness, one integration pattern every later use case inherits. Plants that instead accumulate per-project extraction methods — a CSV here, a vendor API there, a PLC block someone scripted — rebuild the connectivity conversation with every deployment and can never say with confidence what is actually flowing. Freshness alerting is the layer's non-negotiable: a feed that silently stops is worse than one that visibly fails, because everything downstream keeps computing on stale truth.
Shared data layer — ISO 22400 settles the OEE argument
The definition work is political, and the standard is the way through the politics: ISO 22400's KPI definitions for manufacturing operations management give the plant a neutral authority for what OEE, availability and quality rate mean, so agreement stops being a contest between departments' spreadsheets. Context is the other half — tags joined to product, recipe, crew and event windows — and it is what turns eleven weeks of dataset archaeology into a query. This layer is where stage-2 plants should spend the budget they are tempted to spend on more sensors.
Decision layer — the write-back is smaller than the fear of it
The MES and CMMS write-back is where lagging plants expect the project to be hardest, and the fear is usually mis-priced. A draft work order in the CMMS queue, or a recommended setpoint field on the HMI the operator already watches, is a bounded integration with a clean fallback — the previous process, one switch away. What makes it approvable is the fallback being drilled, not theoretical; what makes it valuable is the approval log it starts accumulating from day one. In regulated environments the validation protocol adds calendar time, not uncertainty — the human approval step keeps the regulatory position conservative.
Replication layer — the layer no standard covers and no vendor sells
Nothing in the automation stack forces a plant to template its own work, which is why this layer is the rarest and the most decisive. It is mostly documents and discipline: the data contract for the use case, the adapter code for this MES vendor, the monitoring config, the runbook, the holdout design for attribution, all versioned in one place with an owner. The test is brutal and simple — could a sister site's engineers install the use case from the package alone? Until the answer is yes, the plant has a very good project, not a compounding capability.

The stack also explains why the gap is hard to close by acquisition. A lagging group can buy tools for every layer in a quarter — but the shared data layer's agreed definitions, the decision layer's accumulated override logs and the replication layer's proven templates are all artefacts of the loop having run, and the loop only runs in calendar time. This is the honest version of the 'future-readiness is present-readiness' argument: the only preparation for the compounding stage that cannot be purchased later is starting the loop now.

Why lagging plants stay lagging

The trap is structural, not intellectual — four mechanisms hold competent plants in the lagging loop, and none of them is a modelling problem.

Lagging plants stay lagging because the lagging loop is locally rational at every step, not because anyone is failing to understand AI. Each pilot is individually cheaper than an integration; each dashboard is individually faster than a write-back; each deferral of the definition work avoids a real political fight this quarter. The loop is a series of sensible decisions that compound into an insensible position — which is why exhortation does not break it, and structural moves do.

  • The pilot is always cheaper than the deployment

    Every individual funding decision favours the demonstration: it is faster, needs no change control, and produces a deck for the quarter. The costs of the pilot loop — discarded assets, operator cynicism, the widening gap — land diffusely and later, so they never appear in any single decision. Plants that break this pattern do it by changing the funding rule, not the arguments: no AI initiative is approved without naming the workflow its output will land in and the owner whose KPI moves.

  • The savings are real but unattributed, so the loop never self-funds

    Lagging plants often genuinely improve during pilots — attention alone moves numbers — but without a holdout the improvement cannot be separated from demand mix, crew changes and the season, so finance discounts it, so the next round needs a fresh capital case, so momentum dies in the funding queue. The leading loop's self-funding property is not a cultural trait; it is a direct consequence of holdout attribution making savings bankable.

  • The people who could cross are consumed by the loop itself

    The controls engineer who could build the gateway is hand-pulling historian exports for pilot number six. The best operators are being asked to check dashboards as a favour. The lagging loop consumes exactly the capacity that would build its exit, which is why the crossing has to be scoped small enough — one line, one decision, one quarter — to run inside the capacity the loop leaves over.

  • Waiting for the perfect moment is always locally defensible

    The new MES next year, the plant extension, the ERP migration — there is always a coming event that makes now seem like the wrong time to instrument anything. Meanwhile the compounding plants' advantage grows quarterly, which is invisible from inside the lagging plant precisely because nothing there is deteriorating. Being an AI laggard can be a deliberate, priced strategy — fast-follower is real — but it is only a strategy if the price is being tracked. Drift is not a strategy.

Likelihood: highImpact: high

The leapfrog purchase

A plant-wide AI platform is bought for machines that publish no data. Integrators discover the missing connectivity floor mid-project, scope collapses to a demo line, and the write-off poisons the next three years of proposals — the plant concludes AI failed when the purchase order simply skipped two layers of the stack.

PreventionGate any platform purchase on a connectivity audit: what share of in-scope machines publish today, verified from the historian, not the slideware.

Likelihood: highImpact: medium

Pilot amnesia

Assets are discarded between projects — tag mappings, cleaning code, context joins, lessons — so each pilot re-pays the full entry cost. Three vendors later the plant has bought the same first mile three times and owns none of it.

PreventionMake asset handover a contractual deliverable of every pilot: data contract, mapping tables and pipeline code land in the plant's own repository before final payment.

Likelihood: mediumImpact: medium

The showcase line

One instrumented line is maintained for tours and board visits while the rest of the plant runs on clipboards. The showcase consumes the digital budget, proves nothing about replication, and lets the organisation report progress while the estate stands still.

PreventionFund line two before polishing line one — the second installation is worth more evidence than any refinement of the first.

Likelihood: mediumImpact: high

Waiting for the greenfield

Investment in the existing estate is deferred because a new, born-connected plant is planned. The greenfield slips — they always do — and arrives staffed by teams who have never run the loop, while competitors compounded through the waiting years. Schneider's Lexington case is the public counter-example: the brownfield crossed without waiting.

PreventionRun the 90-day crossing on the existing estate regardless of greenfield plans — the loop, once learned, transfers to the new plant; the waiting does not.

A 90-day crossing: downtime prediction into the CMMS on one line

The lagging-to-leading move made concrete on one common non-automotive problem — unplanned downtime on a bottleneck filling line — from retrofit sensors to a holdout-attributed number.

Crossing the divide takes about 90 days when it is scoped to one line and one decision, and multiple years when it is scoped as a transformation. To make it concrete, the plan below runs the crossing on a specific, common problem: unplanned downtime on the bottleneck filling line of a food or beverage plant, where the line's three worst machines are pre-digital, downtime reasons live on a whiteboard, and the maintenance planner runs a calendar-based PM schedule in the CMMS. The quarter deliberately contains minimal model development — a standard anomaly-and-failure-pattern approach is sufficient — because the crossing is a wiring achievement, not a modelling one. (For what comes after the crossing — the phase-by-phase sequencing of a full digitisation programme — see the transformation phases for factory digitisation page in this knowledge base.)

Lagging loop to leading loop on one line, in one quarter

One line, one decision, one owner. If any phase needs more than its window, narrow the scope — fewer machines, one failure mode — rather than extending the plan.

  1. Days 1–15

    Instrument the three worst machines and baseline the losses

    Pick the bottleneck line. Fit retrofit vibration and current sensors on its three worst availability offenders, route them through an OPC UA gateway into a historian, and switch downtime-reason capture from the whiteboard to the HMI with one agreed code set. In parallel, reconstruct six months of downtime history from the CMMS and shift logs to baseline minutes lost by cause. Name the maintenance planner as owner — unplanned downtime is already their number.

    Live signals from the bottleneck, one code set, a baseline by cause

  2. Days 16–40

    Attribute causes and agree the one definition of downtime

    Run the instrumented line for three weeks while building the context join: which product, which recipe, which crew, which cleaning cycle each stop belongs to. Publish the line's downtime Pareto weekly from the system, and retire the competing spreadsheet versions in the same meeting — the definition argument is had once, with the data on the wall. This is the shared-data-layer work of the stack, scoped to one line.

    A trusted, contextualised downtime picture the whole plant argues from

  3. Days 41–70

    Write predictions into the CMMS queue with a drilled fallback

    Deploy the failure-pattern model on the instrumented machines and write its output as draft work orders into the CMMS queue the planner already processes — never a separate dashboard. The planner approves or rejects every order; rejections are logged with reasons. The calendar-based PM schedule remains fully active as the fallback, one switch away, and the revert is exercised once, deliberately, on a quiet shift. Freshness alerts on the gateway feeds page the named owner.

    Predictions inside the planner's queue; fallback drilled; overrides logging

  4. Days 71–90

    Attribute against the sister line and write the replication sheet

    Hold the comparable sister line on the unchanged PM schedule and report the delta in unplanned downtime minutes and OEE availability — not model accuracy. Close the quarter by writing the replication sheet while the knowledge is fresh: gateway spec, tag mapping method, code set, CMMS adapter, monitoring config, holdout design. The sheet is the difference between a successful project and a started loop.

    A holdout-attributed downtime delta, and the package the next line installs

The order is the strategy

  1. Floor before models

    The sensors, gateway and code set come first because nothing downstream can outrun them. A moderately good model on live, contextualised data beats an excellent model on hand-cleaned exports — permanently, because only one of them can run every day without an engineer in the loop.

  2. Queue before dashboard

    The output lands in the CMMS queue from day one of deployment, even though a dashboard would be quicker to ship. The queue is what makes consumption part of the job rather than a favour, and the approval log it generates is the asset the whole leading loop is built on.

  3. Holdout before headline

    The sister line stays on the old schedule for the whole quarter, however tempting early results make it to convert. The holdout is what turns the quarter's result into a number finance signs — and the signed number, reinvested, is what makes this a loop rather than a project.

  4. Replication sheet before celebration

    The sheet is written in week 13, not 'when there is time' — there is never time later, and an untemplated success is how showcase lines are born. The crossing is complete when the second line's installation is priced from the sheet and comes in markedly cheaper than the first.

The tells: how to recognise which side a plant is on

Seven observable signals that separate the loops — each readable from systems and behaviour, none requiring a maturity workshop.

A plant's side of the divide can be read from observable tells — artefacts and behaviours that exist or do not, independent of what anyone believes or presents. The seven below are the ones we find most discriminating, and they deliberately avoid self-report: each is readable from a system, a log or ten minutes on the floor. They are also, in aggregate, a more honest executive dashboard for an AI programme than any adoption percentage, because each one is a direct measurement of the loop rather than of activity.

TellWhere to read itLagging answerLeading answer
Where the best model's output landsTrace it physically from serving to consumptionA dashboard, a deck, an inboxA CMMS, MES or APS work queue
OEE agreementAsk two departments for one line's OEETwo numbers and a negotiationOne number, one ISO 22400-aligned definition
Cost of the second copyCompare deployment one and two of the same use caseNo second copy, or same cost — rebuiltA fraction — installed from a template
What a silent model failure changesAsk when a model or feed last degraded, and what happenedNothing — nobody noticed for weeksA named owner was paged; the fallback engaged
Override handlingAsk what happens when an operator rejects a recommendationNothing is recorded; workarounds spreadLogged with reason; feeds the retrain set
Downtime history accessRequest one line's last month by causeDays, hand-assembled, contestedMinutes, from the governed store
What survived the last projectAsk to see the previous initiative's assetsSlides and memoriesPipelines, adapters and a runbook in the plant's repository
The seven tells, where to read each one, and what each loop's answer looks like. All are readable without interviews beyond the floor.

The leading-loop checklist

Seven ticks, one per tell, for your own plant — answered from evidence, not intention. This list works without JavaScript; tick as you verify.

0 of 7 ticked

0 of 7 — the lagging loop, honestly identified

No ticks does not mean no capability — it means nothing yet accumulates. That is the most valuable thing a zero can tell you, because the fix is not a bigger programme; it is one line, one decision and one quarter. The 90-day crossing above is written for exactly this position.

Glossary

Hover a term for its definition — or expand the map full screen. The full definitions are written out below.

Lagging loop
The pilot-shaped operating pattern in which each AI project hand-builds its data, proves itself on a dashboard, and evaporates — leaving no assets, so every subsequent project costs as much as the first.
Leading loop
The deployment-shaped operating pattern in which model output lands in an operational workflow, the saving is holdout-attributed and reinvested, and each deployment leaves templates that make the next one cheaper.
Pilot purgatory
The industry term — popularised by World Economic Forum and McKinsey lighthouse research — for the state of running successive AI pilots that never become operational deployments; this page's lagging loop, measured at industry scale.
Connectivity floor
The share of production-critical machines that publish usable data. The floor caps everything above it: no model, workflow or platform can outrun the signals the machines actually emit.
Write-back
Delivering model output into the operational system of record — a CMMS work order, an MES hold, an APS sequence — rather than displaying it on a separate dashboard. The wiring decision that assigns a plant to a loop.
Replication sheet
The package that lets the next line or site install a proven use case: gateway spec, tag-mapping method, code set, integration adapters, monitoring configuration, holdout design and runbook, versioned together.
Replication economics
The cost of the second and subsequent copies of a use case relative to the first. Falling copy cost is the clearest single tell of the leading loop; flat copy cost means every deployment is a one-off.
Holdout
A comparable line, machine bank or shift deliberately kept on the previous process so an improvement can be attributed rather than asserted — the discipline that makes savings bankable and lets the leading loop self-fund.
OEE
Overall equipment effectiveness: availability × performance × quality, with standard definitions given in ISO 22400. On the lagging side of the divide it is a contested spreadsheet; on the leading side, one governed number.
Historian
The time-series store that captures machine and process tags continuously. The stage-2 signature is a historian that is written constantly and read almost never — collection without consumption.
Lighthouse factory
A site designated by the World Economic Forum's Global Lighthouse Network as demonstrating advanced-manufacturing adoption at scale — the documented frontier of this page's compounding stage.
Brownfield retrofit
Adding sensing, connectivity and decision integration to an existing, often pre-digital plant rather than building new — the crossing path demonstrated publicly by sites like Schneider Electric's Lexington plant.

Frequently asked questions

The questions manufacturers ask most often when they suspect they are on the wrong side of the divide.

What separates AI-leading manufacturers from lagging ones?

An operating loop, not a budget. Leading manufacturers wire model output into the workflows that run the plant — CMMS work orders, MES holds, APS sequences — measure the saving against a holdout, and reinvest it, so every deployment makes the next one cheaper. Lagging manufacturers run pilots whose output terminates on dashboards and whose assets are discarded, so every project costs what the first did. Plant age, sector and spending levels correlate far less with the divide than that single wiring difference.

Is the AI gap between manufacturers actually widening?

The mechanism says yes, and the research is consistent with it. The leading loop compounds — savings fund deployments, data exhaust improves models, templates cut copy costs — while the lagging loop is flat, so the distance between plants in different loops grows without anyone making a new mistake. World Economic Forum and McKinsey lighthouse research has described most industrial companies as stuck in pilot purgatory while a documented frontier population scales, and McKinsey's State of AI surveys show adoption climbing far faster than attributed bottom-line impact — the statistical signature of a fork rather than a queue.

Can a lagging manufacturer realistically catch up?

Yes — crossing is realistic; overtaking on the leader's own ground is not the right goal. A lagging plant cannot buy a leader's accumulated loop-years, but it can start its own loop in about a quarter: one bottleneck line instrumented, one model writing into the CMMS or MES queue, one holdout-attributed number. Schneider Electric's Lexington plant — operating since 1958 — reached WEF lighthouse designation through exactly this retrofit-and-integrate path. What does not work is leapfrogging: buying frontier tooling before the connectivity floor and definition layer exist underneath it.

Do we need to replace legacy machines to adopt AI?

No. Pre-digital machines can almost always be brought onto the connectivity floor with retrofit sensing — vibration, current and temperature sensors routed through an OPC UA gateway into a historian — without touching control logic. The retrofit for one line's worst three machines is a tens-of-thousands purchase, not a capital programme, and it is additive: nothing in production depends on it until you choose to. Machine replacement decisions should be driven by production economics; the data layer can be built on the machines you have.

What is pilot purgatory, and how do we know if we are in it?

Pilot purgatory is the state of running successive AI pilots that never become operational deployments — the term the World Economic Forum and McKinsey used when their research found more than 70% of industrial companies stuck there. The test is not pilot count but residue: trace where your most advanced model's output lands, and ask what survived your last project. If the output terminates on a screen and the previous project's assets are slides, you are in the loop this page calls lagging — regardless of how good the pilots were.

Which use case should a lagging plant start with?

Unplanned downtime on the bottleneck line, in most non-automotive plants. It scores highest on the three criteria that matter for a first crossing: the system of record is yours (the CMMS), the feedback cycle is short enough to attribute inside a quarter, and the KPI is one nobody disputes. Quality inspection and process-control use cases are close seconds where downtime is already well controlled. What matters more than the choice is the wiring: whichever use case goes first must land in a work queue with an owner, a fallback and a holdout.

How long does crossing from the lagging to the leading loop take?

About 90 days for the first pass, when scoped to one line and one decision — the plan on this page runs from retrofit sensing to a holdout-attributed downtime number in a quarter. Reaching the optimising stage across a site typically takes one to two years of repeating and templating that loop, and proven multi-site replication longer again. The numbers that matter are directional, not absolute: time from data to decision falling, and cost per deployment falling. Scoping the first crossing as a plant-wide transformation is what turns 90 days into three years.

Why do dashboards keep failing to change anything on the floor?

Because a dashboard makes acting on the model a voluntary extra step, and voluntary steps are the first casualty of production pressure. The operators and planners it is aimed at already have a working process and a full shift; consulting another screen is a favour, and favours stop at peak — exactly when the model matters most. Output written into the queue they already process inverts the default: consumption becomes part of the job, overrides become data, and no discipline is required. No standard operating procedure changes because a chart exists.

Is deliberately staying a fast follower a viable AI strategy?

It can be — if the price is tracked and the floor is built anyway. A genuine fast-follower strategy keeps the connectivity floor, shared definitions and integration capability current so that proven use cases can be adopted quickly once de-risked by others; it buys the option and defers only the model risk. What usually wears the fast-follower label, though, is drift: no floor, no definitions, no loop, and a widening differential to compounding competitors that never appears in any quarterly report. The strategy is viable precisely to the extent that it is a funded decision rather than a description of inaction.

How do leading plants keep operators on side rather than routed around?

By making operators the loop's sensors rather than its audience. In the leading pattern, operators and maintenance planners are consulted during the build, every override they make is logged with a reason and visibly feeds the next model version, and the fallback to the old process stays one switch away under their control. That combination — influence, evidence their judgement matters, and an exit — is what converts scepticism into ownership. Plants that instead announce a tool and mandate its use get workarounds, and the workarounds destroy exactly the data the models need to improve.

What should a small or mid-sized manufacturer do without a data team?

Run the same crossing at smaller scale — the loop does not require a platform team. One line's retrofit sensing, a gateway, a historian and a write-back into the CMMS is within the reach of a controls engineer working with an integration partner, and the 90-day scope on this page was designed to fit inside that capacity. In the United States, NIST's Manufacturing Extension Partnership exists specifically to support smaller manufacturers through this kind of adoption, and equivalents operate in most industrial economies. The SME advantage is short decision paths: the fork that takes a corporation a year of governance can be crossed in a meeting.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI systems for manufacturing, logistics and energy operators — vision inspection, predictive maintenance, scheduling and decision support running against live plant data, integrated into the MES and CMMS layer rather than delivered as dashboards.

  • · Production deployments across electronics, process and discrete manufacturing
  • · Brownfield retrofits: OPC UA gateways and historians on pre-digital lines
  • · Integration-first delivery: MES/CMMS write-back, monitoring, rollback
  • · 12 cited sources on this page

Sources

  1. acatech — National Academy of Science and EngineeringIndustrie 4.0 Maturity Index (update 2020) (opens in a new tab)
  2. International Society of AutomationISA-95 — Enterprise-control system integration (opens in a new tab)
  3. OPC FoundationOPC Unified Architecture (opens in a new tab)
  4. MESA InternationalThe MESA Model (opens in a new tab)
  5. National Institute of Standards and TechnologyManufacturing at NIST (opens in a new tab)
  6. National Institute of Standards and TechnologyManufacturing Extension Partnership (opens in a new tab)
  7. World Economic ForumGlobal Lighthouse Network (opens in a new tab)
  8. MHIAnnual Industry Report (opens in a new tab)
  9. ISOISO 22400-2 — KPIs for manufacturing operations management (opens in a new tab)
  10. McKinsey & CompanyThe State of AI (opens in a new tab)
  11. SiemensSiemens press — newsroom (opens in a new tab)
  12. Schneider ElectricSchneider Electric blog (opens in a new tab)

Find out which side of the divide you are on — then cross it

We run the gap assessment with your engineering and operations leads, trace where your models' output actually lands, and leave you with a costed 90-day crossing plan for one line. You keep the plan whether or not we build it.

Published · Last updated

Benchmark request

Tell us where to send it

Benchmark for this page

Used once, to send this benchmark and follow it up personally. No newsletter, no automated sequences.