World Class
Manufacturing
in the Age of AI

Section 7Permalink

Products and their Build Sequence

The previous two sections settled who owns an outcome. This one is about what they build, in what order, and why the word product is doing real work in every case.

Why "product"? We don't sell software.

Four of the things this blueprint asks a plant to build carry the word product: a workflow product, a data product, an infrastructure product and a visualization product. The word is doing deliberate work in all four. It is not borrowed from software, and it is not a naming convention. It is the mechanism by which ownership survives the end of a project.

The concept originates in manufacturing, and specifically in automotive. Toyota's development system assigns a single senior engineer, the shusa or chief engineer, total accountability for a vehicle programme: what the car should be, who it is for, what it costs, and how every engineering trade-off resolves into a coherent whole. The structural detail that matters most is the one usually left out. Every functional department (body, chassis, powertrain, manufacturing, purchasing) contributes engineers to the programme, and none of them report to the chief engineer. Authority comes from technical depth, drawing sign-off, and direct engagement rather than from a position on the org chart.

Clark and Fujimoto's study of the world auto industry, published as Product Development Performance in 1991, named this structure the heavyweight product manager and contrasted it with the lightweight coordinator common in Western firms at the time: a role that held the meeting cadence, reconciled the functional plans, and owned no outcome. The difference in development performance between the two structures was the finding.

Fujimoto's choice of the word product over project was deliberate, and his stated reason is the whole argument of this subsection. He used product manager rather than project manager to emphasise a responsibility that is long-term and wide-ranging, and that continues after the development project has completed.

That is the distinction. A project has a finish date, a budget, and a team that disbands. A product has an owner who is still there afterward. Everything a project produces on its last day begins to decay from the day after, because responsibility for it has been formally discharged. This is the mechanism behind the most prominent failure pattern “pilot purgatory”: the pilot works because a sponsor owns it, and the rollout fails because a steering committee owns it, which is to say nobody does. It is also why the same plant can run a successful continuous improvement event every quarter and have nothing compound between them.

Clark and Fujimoto identified where heavyweight ownership matters most: where a commons exists that individual functional groups can each degrade in pursuit of their own optimum. That describes a manufacturing value stream exactly. Every function can improve its own metric at the expense of the flow, and the flow belongs to nobody in particular.

The software industry did not invent any of this. It imported it. Takeuchi and Nonaka's 1986 study of fast product development, drawn from Honda, Canon, Fuji-Xerox and NEC, supplied the rugby metaphor that later named Scrum. The heavyweight product manager became the software product manager. Two decades on, having refined the practice at speed, the industry began arguing for products over projects as though it were a new idea, funding durable teams around a persistent outcome rather than temporary teams around a scope document.

Manufacturing is therefore not adopting a software concept here. It is taking back its own, with one variable changed. The shusa's authority rested on technical depth accumulated over a long career across functions, which is why the structure never generalised beyond a small number of firms that could produce such people. AI supplies a usable share of that depth on demand, which is what makes the structure available to an operation that could not previously staff it.

So the naming is a commitment rather than a label. Calling something a workflow product asserts that it has a named owner, a published interface, a stated promise, and a life beyond the engagement that created it. If it does not have those, it is a project, it will decay, and the word should not be used.

A workflow product is one end-to-end process, rebuilt around what AI can now do, from the records the plant already keeps. Not a pilot and not a platform: a single flow (inbound RFQ to confirmed order, downtime log to shift report, setup sheet to a knowledge base the whole team can query) running in production against shift logs, quality sheets and ERP exports, with no new sensors and no wiring. What makes it a product rather than a tool is that it holds the whole flow, including the parts no process map shows. A quote-to-order process documented as five steps and 240 minutes usually hides most of its cost inside one of them: hunting the shared drive for a comparable past quote, re-keying BOM lines, rebuilding a margin sheet, correcting a version that went stale while it waited. Rebuilt AI-native, the reading, retrieval and record-writing move to the machine and the margin call stays with the person who is accountable for it, deliberately, because it is the only step in the flow that is a decision rather than a transcription. The measure of a workflow product is not that it uses AI. It is that one flow now has an owner, a documented current state, and a before-and-after number attached to it.

A visualization product is a decision surface, and the distinction from a dashboard is the entire point. A dashboard presents what is happening. A decision surface presents what is happening, what to do about it, and the means to do it. It is readable at the machine, by the person running the line, without leaving the work. The difference is legible in a single line of interface: an operator sees that the fixture change on R-02 is running long, that rebalancing the two robots recovers nine seconds, and three buttons, apply, ask why, escalate. The data was the same in both cases. In one, a decision was designed; in the other it was not. This is the same closed-loop test applied to the tables above: a surface nobody on the floor opens is a decision surface that makes no decisions, and it fails for the same reason detection without workflow fails. The corollary is that these products are built to the decision and the business outcome, not to whatever data happened to be available, and increasingly they have two faces, one human-readable for the person at the machine, one machine-readable for the next agent in the chain.

A data product is the shopfloor's own labelling discipline applied to information. Nobody accepts an unlabelled bin of parts with no count and no owner, and a spreadsheet export is the same object in a different medium: somebody's copy, from some day, that a person's memory is the only route to. A data product is the labelled rack, a business domain publishes what it generates through a defined interface, with one named individual accountable for it and a stated promise about completeness, freshness and accuracy. Six properties make it a product rather than a dataset, and each is a test a consumer can run before relying on it: discoverable without knowing who to ask, addressable at a path that survives a reorganisation, trustworthy in published numbers rather than adjectives, self-describing enough that no meeting is required to learn what a column means, interoperable with the identifiers everyone else uses, and secure by governed policy rather than a permission list. The failure modes are organisational rather than technical. Data owned by a department is owned by nobody; ownership named once drifts by the third quarter unless the promise is measured. Every plant's first data product already exists: downtime events, quality records, changeover times. It is not a product yet because nobody owns it, it has no published shape, and it makes no promise.

An infrastructure product is the shared plumbing (access, identity, deployment, monitoring) built once and consumed by every build after it. Its published promise is unusually easy to state and unusually easy to audit: the second build costs less than the first. That is the whole test. Where each solution re-solves authentication, access control, deployment and monitoring on its own, the second build costs what the first did, the third costs the same again, and the business case never compounds no matter how well any individual project performs. The sequencing point from earlier applies with particular force here, because this is the layer most often built first and it is the one that most needs to be built last: an infrastructure product should be shaped around what the first one or two domains actually needed, never speculatively ahead of them. A platform built before the first workflow is a guess about requirements nobody has stated yet, and it is the most expensive guess available.

Section 8Permalink

The Technology Stack

Any AI capability is built from three things: model, data and compute. Manufacturing’s maturity across the three is uneven, and being specific about where each stands changes what gets built first.

Data is usually described as the strong leg, on the grounds that a decade of investment already built historian, SCADA and MES layers. That is true of plants that completed the programme and untrue of the many that never did, and even where the layers exist the earlier sections apply: the data was collected without a consumer, so nobody specified it and nobody is held to it.

Compute is scarce at the frontier right now, with on-demand GPU capacity effectively sold out and power overtaking chips as the binding limit in several markets. For a plant that arrives as price and quota rather than as an inability to buy. The workload a plant needs is not the workload causing the shortage, so what actually binds here is where compute sits, and most plants have plenty of it on the wrong side of the seam between operational and information technology.

Model capability is predominantly cloud-hosted today, which is adequate for many tasks but a constraint for manufacturing adoption within the operations network. That is the constraint most likely to change inside a roadmap’s horizon. Local models are closing the gap against frontier models faster than most plans assume, and the direction is specific: judgment moves inside the operational technology network rather than reaching across it each time.

Guiding principles. The stack starts from a small set of principles, deliberately built on the logic of data mesh while departing from it in a few specific areas. The outcome of the stack is a finished good and the workflow that adds value to it, not a data platform. The workflow owner owns the outcome and the interfaces they consume, including the obligation to specify what they need and to escalate when the contract is not met. The producing domain owns the data product and its quality contract: the interface, the freshness guarantee, the definition of what the field means. Each function then curates workflows and supporting datasets with the responsibility to keep the interface, freshness and definitions current. Two operations team members needing the same historian tag is then a contract negotiation with the AI companion that a function specialist curated.

The rest of this section walks the ISA-95 levels, because that is the map already on the wall in most engineering offices. Four things are changing, at four different speeds.

Level 0, sensors and signals, is where Industry 4.0 delivered. Change 1 will happen at Level 1. The PLC is at an inflection point after two decades of predictions that did not land. Change 2 will collapse levels 2, 3 and 4, meaning SCADA, MES and ERP, into a single layer. Change 3 will be a new layer appearing above all of them to do the coordinating, which this blueprint calls the industrial harness. Change 4 will be that time bands will dissolve towards real-time across the pyramid.

Level 0: sensors and signals

A signal has one job. It gives warning that something is going wrong early enough for somebody to act, so that a failure does not become a breakdown and a drift does not become a defect. Everything at this level is a risk reduction mechanism, and it should be selected the way any other risk control is selected.

Manufacturing already has the instrument for that selection, and it predates all of this. The machine FMEA and the process FMEA are a ranked inventory of what can go wrong, how likely it is, how bad it would be, and how likely anyone is to notice in time. That last column is the one that matters here. Detection is the third term in a risk priority number, and a sensor is a detection control. Adding one that lowers no detection rating is spending money to make no difference.

What Industry 4.0 delivered was the access to real-time data, and it deserves the credit for that.

The gap is not sensing. It is that nobody has built a structured way to connect a signal back to the failure it exists to catch, and through that failure to the only outcome that justifies any of it, which is a good part every time. A tag that cannot be traced to a failure mode is cost.

In today’s manufacturing environment the default is that each sensor has a vendor’s upsell product built around it, proprietary and built to capture continuous subscription fees. They support standard protocols like OPC UA, MQTT etc. but not a data standard. So you implement the sensors but have to engineer your own data standard. Standards like i3X started addressing this but we are still far away from an accepted industry norm. So your best bet is to go back to the process standard, the FMEAs, and build your workflows and data standards around them.

Level 1: the PLC

Almost every plant runs traditional hardware PLCs and will next year too. Siemens, Rockwell, Mitsubishi, Beckhoff and Schneider between them run most of the manufacturing world, the installed base is measured in decades, and the people who maintain it were trained on it. Nothing here argues for ripping that out.

Two things sit alongside it and they are routinely conflated.

A soft PLC frees the control logic from proprietary hardware. It is an IEC 61131-3 runtime executing on standard hardware, usually an industrial PC at the machine, often alongside visualisation and data collection on the same box. One runtime, one machine, still on the floor.

A virtual PLC frees the logic from location. The runtime moves off the floor to a server, in a container or on a hypervisor, while the physical I/O stays at the machine and is reached over industrial Ethernet. The defining property is fleet scale: one platform hosting dozens or hundreds of instances. That is the thing a soft PLC never did.

Start with data access, because that is where the real gating happens. Sensors you install yourself are yours, and the signals come back through your own network. The problem arrives with bought equipment. When a machine comes with the builder’s own PLC, the builder decides what you are allowed to read, through which interface, and at what price. Plants routinely discover that the parameters they actually need sit behind a service contract, and that discovery usually happens after the machine is installed. This belongs in the purchase agreement, not the integration plan. Ask in writing which tags you can read, over which protocol, and what it costs, before you sign.

The soft PLC has been disappointing for thirty years. It was introduced in 1995 and never gained widespread traction, and the reason is instructive. The industrial landscape of the mid-1990s was not ready for it. Machine builders were trying to consolidate everything into the PLC, which was never designed for data processing, and the industry solved that by pairing an industrial PC with the controller rather than by replacing the controller with software. The IPC took visualisation and data handling, the PLC kept control, and the problem the soft PLC existed to solve went away.

IoT Analytics put soft PLC share doubling from 3.5% to 7% of the controllers market by 2025 and framed it as an industrial innovator’s dilemma. Incumbents adapted instead.

The reason those forecasts kept missing was never the technology. A German manufacturer said it plainly in that research: they standardised on Siemens because it is what their people learned in school, so they go with what they know even when it costs more. Soft PLCs were built as software, by software organizations, and sold to organizations built around controls and automation. The barrier was the workforce.

The virtual PLC is a different bet, and it should be judged separately. The same house assessed the virtual PLC sceptically in late 2024, holding that it would not be an industry norm by 2030, limited by control task support, missing certifications, no code portability and no redundancy, while still projecting that a quarter of new PLC sales in 2030 could be virtual or soft. Three of those four limits have since moved.

Certification. CODESYS Virtual Safe Control SL was certified by TÜV Süd to IEC 61508 SIL3 in early 2025 for PROFINET and PROFIsafe, and in March 2026 became the first safety controller certified to SIL3 for EtherCAT Safety. Safety controllers no longer require certified hardware.

Redundancy. It reaches dual-channel operation in software through coded processing, so the second channel does not have to be a second box.

Portability. Existing CODESYS applications move onto it by switching the device description, on any architecture supporting containers or hypervisors.

And underneath those, the model of availability changes. This is what makes the virtual PLC a different proposition from its predecessor rather than a better version of it.

A hardware PLC is engineered not to fail, and that is what the price buys: an industrial box with a long life, sized for its own peak, doing one machine’s work, idle most of the time. Reliability is bought once per controller, and a soft PLC on an IPC at the machine keeps that arrangement. The virtual PLC breaks it. Once the runtime is on shared infrastructure, availability comes from redundancy instead. Components are allowed to fail because another instance picks up the work, and the question stops being how long this controller lasts and becomes how fast the workload restarts somewhere else.

The cost consequence is the strongest argument in the category. Ten controllers become ten instances sized for total load rather than ten separate peaks, with the cabinet and the controller hardware gone, the I/O reaching the server over industrial Ethernet. Manufacturing already holds this argument in physical form. Classical automation guidance prefers several small reliable machines over one large complex one, because several small machines give redundancy that one large machine cannot. This is that principle applied to the controller.

The workforce barrier is being dismantled by AI. Tools now generate structured text and ladder logic for CODESYS and the major vendor environments, some running local models for air-gapped networks, at a fraction of vendor pricing, and Siemens has put agentic assistants inside TIA Portal. Migration cost was the moat and migration cost is what is falling. As it falls, more logic moves onto shared infrastructure, which is where the security argument arrives from the opposite direction.

Two caveats. The failure domain moves. When control sat in the cabinet, the backplane was the critical path and the network was a convenience. On shared hardware the network becomes the critical path, and the plant depends on redundant switching and a failover that finishes inside whatever the process tolerates. That is a genuine engineering problem and a different skill set.

And portability is not independence. A virtual controller tied to one vendor’s management platform has moved the dependency rather than removed it. CODESYS is the stronger position on this count because its runtime is genuinely hardware-agnostic and applications move between platforms. What it lacks is market coverage, and the real brake on switching is the cost of retrofit rather than anything the runtime cannot do.

Levels 2, 3 and 4: SCADA, MES and ERP collapse into one layer

These three levels were drawn as separate systems because they were separate products, from different vendors, joined by defined handshakes: OPC UA carrying machine data up, B2MML carrying orders down and performance up. That separation is already breaking down. IIoT deployments routinely put edge devices straight onto the PLC and stream to analytics, skipping SCADA and MES entirely. MES itself is being rebuilt as composable services rather than one monolith.

The claim here goes further. All three collapse into a single semantic layer: an ontology that holds what a line, an order, a downtime event and a defect actually mean, with the four product types built against it and language models coordinating between them over a standard interface. ISA-95 survives this, but as the ontology rather than as the shape of the software. It already defines the relationships between equipment, materials, personnel and processes, which is the schema such a layer needs.

Why now, when people have wanted this for twenty years? Because the cost of leaving the incumbent has fallen. When replacing one MES function meant a licence, an integrator and eighteen months, lock-in held no matter how poorly the function fit. When a capable person can build a replacement for one function in a fortnight, the lock weakens for everything that was never worth what it cost.

This will take time. Qualification and validation are real brakes, and a regulated plant will not rebuild its batch record system because the ERP module irritates people. The likely path is uneven: the badly-served and lightly-regulated functions go first, the qualified core goes last or never, and plants run a hybrid for longer than either side of the argument admits.

The coordination layer: the industrial harness

Above all of it sits the layer this blueprint has been building toward: an industrial harness.

The vocabulary is arriving from software, and fast. The discipline has renamed itself three times in three years. Prompt engineering, when the constraint was phrasing. Context engineering, when the constraint became what the model could see. Harness engineering, once agents ran for hours and the constraint became the environment around the model. The formula in circulation is that an agent is a model plus a harness, and published benchmark work shows the same model scoring very differently depending on which harness wraps it, which makes the harness a bigger lever than the gap between model generations. Two further rungs are being named as this is written, loop engineering and graph engineering, both only months old. Treat those as direction, not doctrine.

There is already a version one of this, and most plants that have tried coordination have tried it. A unified namespace is a publish and subscribe architecture, usually built on MQTT, in which every system publishes what it knows to a common broker and anything that needs that information subscribes to it. The point is negative rather than positive: it removes the need for a direct interface between every pair of systems. Without it, connecting five systems means twenty relationships to build and maintain, and each new system multiplies the problem. With it, each system has one relationship, to the broker.

That is a genuine architectural advance and it is not new. It also does not need AI, which is worth saying plainly, because a plant that wants coordination and is not ready for agents can build this today and get real value from it.

Its deficiency is maintenance. The namespace has to be designed, meaning somebody decides what topics exist and what a message on each topic means, and then that structure has to be kept honest as the plant changes. Every new machine, every renamed line, every changed unit of measure is a decision somebody has to make and propagate. In practice the naming convention drifts, two systems publish the same thing under different topics, and within eighteen months the broker holds a large amount of data that nobody can reason about without asking the person who set it up. The complexity did not disappear. It moved from the interfaces into the semantics.

The AI harness is version two, and what it adds is precisely the part that failed. It carries the meaning alongside the message, holds the rules about what may act on what, and can reconcile two descriptions of the same thing rather than requiring a human to have prevented the divergence in advance.

In a plant, the harness is the layer that holds the codified rules, the state, the workflows and the enforcement, so an agent runs a path decided in advance and a run can be replayed rather than merely repeated. It carries the companions, their skills and their routines. It reaches everything below it through published interfaces, API and MCP over a standard such as i3X, rather than through a bespoke integration per system.

The harness will split in two phases. Phase 1 will be an IT-side harness, operating in a plant’s IT network where reasoning is expensive, latency matters less and only selected data points get integrated live. Phase 2 will be an OT-side harness inside the operations network, where the loop is tight and mistakes are physical. Real-time inference will increasingly demand implementations closer to the machine and we have already seen this requirement with current non-generative AI systems that run lineside on GPUs for vision and defect detection. As local models improve, more judgment will move to where the judgment is needed. The next subchapter covers why that shift is now a product decision rather than a forecast.

Local models inside the OT network

The split described above assumes that useful reasoning can happen inside the control network. Eighteen months ago that was a forecast. It is now a product decision, and it is the single change most likely to determine what the stack looks like in five years.

What has shipped, and what has been announced. Rockwell announced in November 2025 an edge-based generative AI capability built with NVIDIA, using the open-source Nemotron-Nano-9B-v2 model and the NeMo framework. The small language model is distilled to run in environments with less space and power than a data centre, fine-tuned with FactoryTalk Design Studio data, and supports both edge and air-gapped deployment, meaning it works with no external connection. It was demonstrated at Automation Fair the following week.

The more significant development is quieter, and it concerns the platform rather than the model. Siemens announced at Hannover Messe in April 2026 that its Industrial Edge platform will get IEC 62443-4-2-certified security functions in the second half of 2026, including air-gapped operation for critical infrastructure. That standard covers cybersecurity requirements for control system components, and its Industrial AI Suite runs on that platform, having reached general availability at the same event. UL Solutions has separately verified Industrial Edge and the virtual PLC across connectivity, control, resilience and cybersecurity.

A certification path is what turns a capability into something a plant IT lead can approve rather than resist. The technology arriving matters less than the compliance route arriving with it.

Four reasons this becomes the default rather than a niche, and only one of them is privacy.

Sovereignty. Inference on a local accelerator means production data, operator queries and sensor readings never leave the facility network. That matters in regulated production and in defence-adjacent work where sending operational data to a cloud endpoint is simply not permitted.

Latency. A decision at the point of work has a budget measured in milliseconds, and a round trip to a cloud endpoint does not fit inside it.

Availability. The plant runs when the network does not. This is the argument that lands hardest with anyone who has operated a site, and it is the one vendors lead with least, because it sounds unglamorous. A companion that stops working during an outage is a companion nobody will build a standard around.

Economics. Serving a small model costs an order of magnitude less than serving a frontier model, and local inference removes per-token pricing entirely. At the volume a plant generates from continuous monitoring rather than occasional questions, per-token pricing is what kills the business case long before capability does.

Small is a capability argument here, not a compromise. Gartner projects that by 2027 organizations will use small, task-specific models roughly three times more than general-purpose ones, and Dell has called 2026 the year of the small language model. The reason is that plant workloads are narrow. A companion that reads this plant's maintenance history and proposes a hypothesis does not need to be good at anything else, and the fine-tuning that makes it good at that is only possible because the model is small enough to tune.

What this does to the architecture. It is the second organizing principle arriving as hardware: capability mobilised to the problem rather than the problem shipped to the capability. It also changes the security conversation fundamentally. An agent that never leaves the OT network is a different risk object from one that reaches across the seam, and the zones and conduits question becomes tractable rather than contentious.

Two things it does not solve. Model management becomes a plant responsibility: versions, updates, evaluation, and knowing which model produced which recommendation. And the qualification point applies with more force, not less, because owning the model means owning the version. If a local model sits inside a qualified process, updating it is a process change, and the fact that it is running on your own hardware makes that easier to control and much harder to claim you did not notice.

Why there will not be a factory operating system

Two of the largest companies in this space are building something they describe as an operating system, and the description is worth taking apart, because it sets an expectation the thing cannot meet.

At CES in January 2026, Siemens and NVIDIA announced an expanded partnership to build what they call the Industrial AI Operating System. The commitment behind it is real. NVIDIA supplies AI infrastructure, simulation libraries, models, frameworks and blueprints. Siemens commits hundreds of industrial AI experts alongside its own hardware and software. The first site is Siemens’ own electronics factory in Erlangen, intended as the blueprint for fully AI-driven adaptive manufacturing, where an AI brain built from software-defined automation, industrial operations software and NVIDIA Omniverse libraries continuously analyses the plant’s digital twin, tests improvements virtually, and turns validated insights into changes on the shop floor. Separately, Siemens is GPU-accelerating parts of its electronic design automation portfolio using PhysicsNeMo and CUDA-X, targeting two to ten times speedups in verification and layout.

That is a serious multi-year engineering commitment and it will produce useful things.

It is also not an operating system, and the clearest evidence is what was not announced. No formal software architecture or executable specification was disclosed. The CES materials described an organising framework for aligning simulation tools, AI models and industrial software inside existing workflows, positioned as an integration layer rather than as a replacement for existing control and automation. Erlangen was characterised as a reference environment rather than a deployed production system.

So the word is doing marketing work rather than technical work. That matters less for what these two companies build than for what a plant expects when the next vendor uses the same phrase.

What an operating system actually does. It sits between hardware and applications and hides the first from the second. It manages shared resources, schedules them, and presents an interface that does not change when the hardware underneath it does. All of that produces one thing: portability. An application written once runs on any machine the operating system supports, which is why an ecosystem of applications becomes worth building at all.

Portability is the product. Everything else is mechanism.

The precondition is a stable abstraction underneath. Windows had x86. Linux had POSIX and a driver model. Android needed ARM and a hardware abstraction layer, and Google still had to intervene repeatedly to stop fragmentation breaking the promise. In each case the abstraction was possible because the hardware beneath it, however varied, did a small number of comparable things.

Robotics ran this experiment. Before ROS, robotics development was severely fragmented, with different sensors, motors, protocols and interfaces, and a navigation algorithm that worked on one platform needing substantial rewriting for the next. ROS was built to fix exactly that and it did, by supplying a hardware abstraction layer through drivers.

But despite the name, ROS is not an operating system. It is middleware, and it runs on top of a real operating system, usually Linux. It provides hardware abstraction, low-level device control, message passing and package management, which is most of what you would expect from an operating system, without being one. It took roughly fifteen years and a large community writing a driver per device to get there.

That is the answer to whether manufacturing could have one. You can build the abstraction where the hardware does not provide it. What you get is middleware, and the bill is a driver for every device and a community to maintain them.

Manufacturing is harder than robotics, for a reason that is not about hardware. Robotics converged on a modest set of sensor and actuator types doing comparable jobs. Manufacturing did not, but that is the smaller problem. The larger one is that in a plant there is nothing to port.

An operating system earns its cost because applications move between machines. In a plant, the thing that would move is the process, and the process is the differentiation. Two stamping plants running identical equipment run different processes, because the difference is the accumulated judgment of the people who built them, which is exactly what the fifth organizing principle argues is worth codifying rather than standardising away. A layer that made processes portable between plants would be removing the asset.

Semiconductor fabrication is the counter-example that proves the rule. Fab equipment converged, the process converged, and standards like SECS and GEM followed, which is why fab software looks more like a platform than anything in general manufacturing. Standardisation arrived because the process standardised first, not the other way around.

So what is a harness, if it is not an operating system?

An operating system abstracts the hardware so that many different applications can run on it. A harness does the opposite. It constrains one plant’s specific workflows so they run the same way every time. An operating system asks whether this program can run here. A harness asks whether this run did what we decided it should do, and holds the evidence either way.

An operating system is general by design and its value grows with the number of things running on it. A harness is specific by design and its value grows with how precisely it encodes one operation’s rules. Nobody would want a portable harness, because one that ran anywhere would be enforcing nothing in particular.

What this means commercially. Expect the Siemens and NVIDIA work to produce strong simulation and digital twin capability, which is real and worth having, sold under a word that promises something else. The question to put to any vendor using the phrase is one line: what exactly becomes portable, and between what. If the answer is that your processes become portable to another plant, ask why you would want that. If there is no answer, the word is marketing, and the product underneath may still be worth buying on its own terms.

What collapses with the pyramid

The pyramid is usually drawn with a time axis running up the left side: microseconds at the process, seconds at the controller, minutes at supervision, hours at operations management, days and months at business planning. Those bands were never a property of the decisions. They were a property of how long it took information to travel and how expensive it was to process on arrival. A monthly business review happened monthly because assembling it took most of a month.

Remove the travel time and the processing cost and the bands lose their basis. A routine may still run weekly because a weekly cadence suits the work, and cost review may still be a monthly meeting because people need to be in a room. But the capability is no longer bound to the level. A question that used to be a Level 4 question answered in months can be answered continuously, and the reason to keep it monthly becomes a choice about attention rather than a limit of the system.

That is why this section is organized by level and the rest of the blueprint is not. The levels remain a good description of where things physically sit and who is responsible for them. They have stopped being a description of how fast anything can be known.

Section 9Permalink

The Lights-Out Factory

There is a video worth watching before reading this section. A Wall Street Journal crew walks Zeekr’s flagship plant in China with the lights dimmed and hundreds of robots turning out dozens of electric vehicles an hour around the clock. The plant makes up to 300,000 cars a year, more than 800 a day, from a company founded in 2021. Tesla runs at similar volumes and took over a decade to get there. The crew is honest about the limits: cable assembly still needs a human touch, workers go in to maintain the robots, and most of those cars are sold domestically because Western markets have largely kept Chinese brands out. Labour costs in China have been rising for years, faster than the West expected, and automation was the obvious answer for a factory owner. Robotisation has grown sevenfold since 2015, and by 2023 every second industrial robot installed anywhere on earth was installed in China.

Zeekr’s own smart factory digital brain screen gives an insight into what has to come together for a lights-out factory.

Lights-out, or dark factory, which mean the same thing, is not a building. It is a condition a process reaches, section by section. Zeekr has reached it in the shop where the work is most repeatable and not in the one where it is not.

Two things have to be true for a process to get there. The equipment has to operate in a closed real-time loop between customer requirement, engineering specification and manufacturing reality, which is adaptive automation. And the plant has to operate at the speed of software to control the factory in real-time, which is software-defined steering. Neither is sufficient alone. A plant with excellent software and rigid equipment stops every time a part arrives wrong. A plant with vision-guided robots and no semantic layer works and does not scale.

This section is for the reader who wants to get ahead of the curve. The following sequence walks through the order to get there.

01 An AI-ready organization and workforce

Covered in the organization papers.

What it produces. One person accountable for a flow end to end. Functions that publish their expertise as callable capability rather than answering the same questions one conversation at a time. Operators who focus on decision-making.

Why it comes first. Conway’s Law. A siloed plant builds siloed systems, so an organization that has not changed will get the same result as before.

There is a second reason specific to this section. Everything that runs unattended runs on somebody’s judgment about when to continue and when to stop. Those bounds are not vendor parameters. They come from the people who currently make those calls in person, and if that knowledge has not been captured before the equipment arrives, the equipment gets defaults nobody in the building agrees with.

02 AI-native workflows

Covered in the products and build sequence paper.

What it produces. Business processes (workflows) built around AI capability. Your specific business knowledge encoded and made repeatable with the human’s role shifting from data hunting to management by exception.

Why it comes second. It proves value and organization capability before any platform spend, at a cost a plant can absorb if it is wrong. And it creates the consumer that makes the next step possible, because data products built before a workflow needs them have nobody on the other end of the contract.

The workflow also does something specific for this section. It is where a plant finds out which of its processes are genuinely understood and which are held together by somebody’s memory. That is the same distinction that decides which processes can eventually run unattended.

03 An AI-native technology stack

Covered in the technology stack paper.

What it produces. Software-defined steering. You likely already have a few of the building blocks. Sensors publishing data, access to equipment data and systems like SCADA, MES and ERP. They are not the target state but the starting point. What you need to build is an agentic harness around your workflows carrying the rules, the state and the enforcement, reachable through published interfaces.

Why it comes third. It is built from what the first two produce. The ownership from step one decides who publishes what. The workflows from step two specify what the data products have to promise. Building this layer first is the platform-first error this series has argued against from the start.

04 Automated material flow

What it produces. Material moving to plan without somebody driving it. The first meaningful block of labour freed, and the least tolerance-critical thing to hand over.

Mobile robots come in two kinds and the distinction is commercial rather than pedantic. An AGV follows a predefined path set by markers or external guidance. An AMR navigates, using sensors to route around an obstacle rather than stopping in front of it. That is adaptive behaviour at its simplest, and the safety consequence follows: an AGV’s protective zones can be fixed because its path is fixed, while an AMR varies its detection zone with speed and direction, extending it when travelling fast to allow braking distance and narrowing it when slow or cornering to avoid nuisance stops.

The standards are still converging. ISO 3691-4 governs driverless industrial trucks and is the more demanding international instrument, requiring performance-level-rated personnel detection along with redundant control and independent monitoring. ANSI/A3 R15.08 covers industrial mobile robots in North America, classifying them as Type A, a bare platform, Type B, a platform with non-manipulator attachments, and Type C, a platform carrying a manipulator. As of 2025 ISO 10218 defers to ISO 3691-4 for the mobility behaviour of mobile manipulators.

The standard has to exist first. For material movement that standard is PFEP and a value stream map. Plan For Every Part records how each part arrives, in what quantity, in what container, to which point of use, how often. It is unglamorous and most plants do not have one. A fleet deployed without it automates the current chaos at speed and produces a fleet management problem on top of a material flow problem. With it, the routes are already defined and the robots run a plan that already worked.

Why it comes fourth. It is the first physical step and the most forgiving because material transport is essentially not value adding. A tote arriving three minutes late is a different order of problem from a weld placed wrong, so this is where a plant learns to run equipment nobody is watching.

Where the density gap shows. Geek+ has delivered around 56,000 mobile robots into roughly forty countries, and its scheduling system coordinates 5,000 of them in a single warehouse, which no other vendor has matched. Quicktron has more than 42,000 robots deployed for over a thousand customers across more than twenty countries, and its Dongguan site was among the first anywhere to run a thousand AMRs in one coordinated deployment. Hikrobot has shipped roughly 150,000 units to more than 2,500 customers, and Chinese market research puts its largest single deployment at over a thousand robots inside one CATL gigafactory, cleanroom-certified throughout and integrated with the plant’s MES for cell-level material traceability.

Set that against the baseline most plants are working from. The median new AMR deployment was fifteen robots in 2024 and around thirty-five per facility in 2026. Fleet orchestration at a thousand units and above is a solved problem somewhere, and a plant treating a twelve-robot deployment as a research project is measuring itself against a number that moved.

05 Flexible Production Systems

What it produces. A line that runs more than one product, and can be changed to run the next one without being rebuilt. At the far end of the same argument, a production system with no line in it at all.

The asset now outlives the product

Flexibility has been technically possible for thirty years. Most plants did not buy it, because the numbers did not work. A dedicated line is cheap per unit and expensive per model change, and that was an acceptable trade as long as the product ran long enough to pay the line back.

That is changing. SAIC-GM-Wuling quantified it. Xiao Xiao, who runs their planning and operations management, says the average vehicle lifecycle used to be 36 months and is now around 10 to 12. Meanwhile three of their production lines have to cover 24 models. The problem that creates is not the cost of the line. It is the time to build one. A new line took about two years to stand up. If the product it was built for lives twelve months, the line arrives after the product it was meant to make.

Those numbers come from the Chinese EV market, which moves faster than anywhere else, and they are the company’s own. The numbers will not be yours. The direction will be. Program lives are getting shorter, quoted volumes are less certain than they were, and re-sourcing under tariff pressure arrives with less notice than a capital cycle. Flexibility used to be a question of how you preferred to run the plant. It is now a basic design requirement.

Start with the model, not the steel

Virtual commissioning is usually sold as a way to shorten commissioning. That is true and it is the smaller reason to do it.

The real reason is that a flexible line cannot be proven any other way. A dedicated line runs one product and you can test it. A line running six variants, with tooling swapping between them, has a number of states nobody can walk through on the floor before start of production.

So the model comes first. Real control code, tested against a simulated cell, before any physical installation. Every variant, every changeover sequence, every collision case, run against a digital version of the line while the steel is still a drawing. Commissioning stops being where the problems are found and becomes where they are confirmed absent.

What makes a line inflexible

Historically, product-specific tooling held the parts and joined them to tolerance. It worked, and it made changeover expensive enough that the investment only paid on a long production run.

The problem was never the robots. Robots are general-purpose and always were. The problem is everything wrapped around them, meaning the gates, the fixtures, the pallets, the grippers, all of which are cut for one product and worth nothing when that product ends.

The design principle

Separate what is general-purpose from what is program-specific, and make the program-specific part the only thing that changes.

General-purpose, amortised across programs. Robots. Transfer and conveyance. Controls, network, safety. Cell structure and enclosure. These stay across model generations and should be specified as though they will.

Program-specific, sized to be swapped. Framing gates. Geometric pallets and adapters. Grippers and weld guns. The programs themselves. These are consumables on a product timescale.

The ratio between those two is what a new program costs. A plant that lets program-specific content creep into the general-purpose layer pays for the whole line again every model cycle, and usually does not notice until the quote arrives.

The island architecture in the next subsection is this principle taken as far as it goes. Each station is built to a process rather than to a product, so a new model consumes programs and tooling but not structure.

For a smaller manufacturer there is a purchasable version of the same argument. KUKA’s flexibleCUBE is a pre-engineered modular welding cell available in nine configurations, with positioners from stationary tables through turntables to ferris wheel systems, meant to be dropped into a line rather than engineered into one. Buy a standard cell and change the tooling, rather than commission a bespoke cell and own it forever.

The three degrees, and what each costs

Flexibility is not one purchase. It is engineered across three levels.

At the machine. Sensing and correction. Vision locating a part that was not fixtured. Force control seating a component rather than driving it to a programmed position. In-process compensation for tool wear. Zeekr’s wheel installation is this: two robots fitting wheels to a moving vehicle, located by vision. This is what makes the levels above affordable, because a cell running mixed builds cannot carry dedicated fixturing for every one of them.

At the line. Operational flexibility inside a planned envelope. Change the sequence, swap tooling, reroute material, load a different program, vary the batch. A framing station that carries five or six variants by rotating model-specific adapters into position sits here. The flexibility was designed in advance for variation somebody anticipated, which is its strength and its limit. Throughput is lower than a dedicated line and that is the price.

At the system. Structural reconfigurability. Add, remove or rearrange modules to change what the system does or how much of it. The design principles are modularity, integrability, scalability, convertibility and diagnosability, and the aim is flexibility on demand rather than flexibility anticipated.

When the line itself is the constraint

A line is a commitment: fixed sequence, balanced to takt, efficient at volume and expensive to change. The alternative replaces it with stations that a product visits in whatever order its build requires, with material brought to it.

The first serious attempts failed or stayed small. Arrival made the most complete bet, designing a vehicle specifically to be built in small robotised microfactories, and went under. The failure was not the concept. Arrival attempted a new vehicle, a new production system, a new supply base and a new company at once, so every problem it met was novel and nothing could be validated against something that already worked. Hyundai’s Innovation Center in Singapore is the same idea attempted by a company that already knows how to build cars: cell-based production rather than a conveyor, robotic arms in specialised cells, AGVs and AMRs moving material, and a digital twin of the operation. It works, and the reason it was built that way is footprint. It sits in one of the most expensive and land-constrained cities in the world, and the cell-based layout is what made production viable where a conventional plant would not have fit.

The volume proof arrived at the end of 2023, at SAIC-GM-Wuling’s Baojun base in Liuzhou, under the name Intelligent Island Manufacturing System.

What it is. The conveyor is gone. The long line has been cut into 78 independent islands across four shops, with two automated warehouses feeding them. Each island is an automated station built around a process rather than a model: a glass island, a tyre island, a fluids island, a quality island. Final assembly alone runs 34 of them. Bodies ride on intelligent guided vehicles that carry the work and route themselves to whichever island is free, driving around congestion instead of queueing behind it. More than 280 IGVs work the final assembly shop. Twenty-four models are built in the same space at the same time, and the plant turns out 40 to 45 vehicles an hour, taking about eleven hours to go from parts to a finished vehicle. Their own phrase for how it flows is that the car goes looking for the station and the material goes looking for the car.

The mechanism worth copying. If a vehicle is missing a part, the IGV parks it at a tidal station until the material arrives, then puts it back into the flow. No other vehicle is affected. On a conveyor the same event stops everything downstream. That single behaviour explains most of the throughput gain.

What they claim it delivered. Time to stand up a new production line down from about two years to about one month. Duplicate investment for a new model introduction down 33 per cent and introduction lead time down 60 per cent. Production efficiency up 30 per cent, logistics efficiency up 80 per cent, unit manufacturing cost down 31 per cent, main-line station count down 40 per cent, part buffers down 30 per cent, on-time order completion at 99 per cent, and complete lifecycle data traceability. The demand forecasting horizon extended from four weeks to sixteen. Automation runs around 50 per cent, which is worth noting because it is lower than most readers assume, and the flexibility rather than the robot count is what the system is for. The programme produced 110 patents and 67 software copyrights, and in November 2025 it was named to the first national pilot-level smart factory list by six ministries, the only complete-vehicle manufacturer in that group. Investment is stated at over ten billion yuan.

These are company and state-media figures, not audited ones. A reported equipment utilisation of 98.82 per cent is almost certainly availability rather than OEE as normally defined. None of the percentages name a baseline, so you cannot tell whether the comparison is to their own previous line or to a notional greenfield conveyor. The improvement is probably real. The figures are not precise enough to plan against.

How they got there, which matters more than the numbers. At the start only twelve islands were technically feasible. They built the tyre island first because it was the easiest one. Then the glass island, which needed millimetre-level control of the adhesive bead. Then the seat island, which needed 3D perception instead of 2D and robot payload raised from 10 kg to 30 kg. They took the easiest job first and spent what they learned on the next one. There was no cutover. That sequence works at any size, and it is the part of this case a smaller manufacturer should study.

They have since extended the same architecture upstream into body construction, under the name Body Flexible Intelligent Manufacturing Centre. Assembly was the easier half. Joining carries tighter tolerance and stiffer precedence, so watch what happens there before believing the model generalises across a whole plant.

It was not invented in Liuzhou. Audi has run the same idea under the name Modulare Montage since the late 2010s, with technicians assembling at production islands independently of the assembly cycle and AGVs bringing parts to them. Their pilot sat in interior door panel pre-assembly at Ingolstadt and claimed about 20 per cent higher productivity. KUKA’s matrix production concept is the same family. Western OEMs kept the idea in pre-assembly and pilot cells for close to a decade. What Wuling did was take it to full vehicle final assembly at volume, and getting something to work at production volume is usually harder than proving the concept. They describe this as the third revolution in automotive manufacturing, after Ford and Toyota. That is a marketing line. Look at what they built instead.

What decides whether it applies to you

Island logic does not replace a line everywhere. Four conditions have to hold at the same time, and if one of them fails the approach does not work.

The station has to be cheap enough relative to the system that you can afford two or three of them just for routing. Switching a station from one variant to the next has to be a program change rather than a hardware change. Precedence between operations has to be loose enough that the order can vary. And station cycle times have to be within the same order of magnitude, or the scheduler has nothing to balance.

Assembly meets all four, which is why that is where this has landed. A glass island is robots, a fixture and a vision system, so you can afford several. It changes variant by loading a different bead path. Glass, tyres and seats can mostly be done in any order. Every station runs at about a minute.

A stamping press meets none of them. A large press requires a foundation, a pit and a capital number that rules out buying a second one for routing convenience. Changing variant means changing dies, which is physical work and consumes minutes of the most expensive asset in the building. The cycle time is out by two orders of magnitude.

Why it comes fifth. It is expensive, and the bounds it runs within come from step one. Buying this before the judgment has been captured means somebody writes the tolerances from a manual. The system-level version has a second dependency. Its behaviour lives in the scheduler, and the scheduler is built from step three. A plant that buys islands without the stack underneath has bought floor space and autonomous transport, and it will run them on a spreadsheet.

06 Advanced networking

What it produces. A connection that real-time agentic systems and mobile equipment can rely on.

This is the enabler most likely to be dismissed as an IT matter, and the reason it is not is specific. Wi-Fi’s problem is not bandwidth, it is roaming. Wi-Fi uses make-and-break handoff: when an AMR crosses between access points it disconnects from one before connecting to the next, and during that gap it has no contact with its control system. It stops, for safety. Then the robots behind it stop. LG’s Clarksville plant in Tennessee, which runs around 200 AGVs and AMRs, added a private 5G network alongside its 250 Wi-Fi access points in 2023 and put the mobile robots on it first, citing Wi-Fi reliability. Tesla, Ford, Hyundai, Toyota, Foxconn, Whirlpool and BASF have made the same move for the same reason.

The second problem is variance. Wi-Fi latency swings between roughly 5 and 50 milliseconds and occasionally drops a packet entirely, which is why it cannot carry closed-loop motion control. 5G’s ultra-reliable low-latency mode targets sub-millisecond latency at 99.9999% reliability, which approaches what a hardwired PROFINET or EtherNet/IP connection delivers. Control signals that currently require a cable become wireless, which is what makes a genuinely reconfigurable layout possible rather than a layout with cable trays in it.

Wi-Fi 6 and 6E have closed part of this gap and their vendors argue they have closed all of it. Private 5G also costs several times more up front, offset by needing far fewer access points. The argument is live, and the deciding question is whether anything in your plant has to keep moving while it stays connected.

A factory floor is also a hostile radio environment. Dense shelving, multi-level operation, high electromagnetic noise, very little line of sight, and people and robots moving through it constantly. Signals arrive by several paths at slightly different times, and that multipath is also what limits wireless positioning to metres rather than centimetres. The same conditions cause both problems, which is why networking sits immediately before spatial anchoring in this sequence.

Spectrum is no longer the barrier in any of the three markets that matter here. In the US the CBRS band at 3.5 GHz lets a manufacturer run a private network without buying spectrum. In Canada, ISED licensed 80 MHz at 3900 to 3980 MHz for local private networks, aimed explicitly at smaller users needing spectrum in one location, with manufacturing named as a target industry, and Rogers, Bell and Telus will build and run the network if you would rather not hold the licence yourself. In Germany, enterprises have been able to license 3.7 to 3.8 GHz directly since 2019, with 484 assignments by November 2025 and manufacturing the largest single category. Most of Western Europe now has some version of the same arrangement.

Why it comes sixth. Because the plant in the video runs on it. Zeekr’s Hangzhou Bay site is a 5G fully connected factory and one of the first Future Factory projects in Zhejiang province. The factory-wide connection is what lets vehicle configurations be adjusted, errors corrected, processes updated and quality checked across the whole plant rather than machine by machine. That is not a fleet-size question. Coverage across the entire floor is what makes an unattended plant possible at all.

Timing. Early deployments through 2025 and 2026 have been in large plants, typically over 100,000 square feet, already running serious industrial Ethernet. Vendors are expected to ship 5G-native robots, vision systems and controllers from around 2027, which removes the gateway cost. Mid-size economics are expected toward the end of the decade. Wi-Fi 7 promises deterministic latency through multi-link operation and may close part of the gap, though it stays in unlicensed spectrum without SIM-based authentication or true slicing.

07 Spatial anchoring

What it produces. A plant that knows where things are, continuously and accurately enough to act on.

This is the weakest link in the sequence and the one that currently caps how far the rest can go.

Real-time location systems exist and are deployed. The technology choice is a set of trades where nothing wins outright.

Accurate is expensive and affordable is coarse. Nothing gives a plant a continuous, centimetre-accurate picture of everything and everyone at a price that justifies tagging the whole operation.

The physics is the same one that troubles the network. Multipath from steel structures and racking means a signal arrives by several routes at slightly different times, and every technology in that table degrades in those conditions. A vendor demonstration in a clear space is not evidence about your building.

Adaptive equipment handles variation in the part in front of it. It cannot handle a plant where it does not know what is around it. A machine working a genuinely dynamic floor needs what a mapping application gives a driver: not a static plan but a live picture of where everything actually is right now. Without it, every autonomous machine gets a protected space, and protected spaces are what make a flexible layout inflexible again. So a plant can buy reconfigurable production in step five and then anchor it in place because nothing knows where anything is.

The robots do not solve this. Some AMRs localise themselves through SLAM, but plenty of mobile robots run on magnetic tape, QR codes or reflectors, and the ones that do localise keep the picture to themselves.

5G positioning is not ready. The standard is moving that way, from cell-level accuracy in Release 15 to under three metres in Release 16, a sub-metre target in Release 17 aimed at industrial use, and carrier-phase methods in Release 18 reaching centimetre level under favourable conditions. A literature review of RTLS in automotive production put the current position plainly: the maturity is not there for industrial use, current capability does not meet the requirement, the specifications exist mainly in theory, and practical pilots using 5G as a local positioning source are only starting in controlled environments. Accuracy also scales with signal bandwidth, and the low-cost device classes a plant would tag things with have the least of it.

BMW investigated this properly and did not pick a technology. That literature review was funded by BMW and written alongside a doctorate on the question, completed in 2024 after three years of test fields with several network and hardware vendors, including a 5G localisation setup.

What they built instead is IPS-i, a localisation platform they have been extending since 2016. It takes UWB, GPS and RFID and delivers standardised position data to one layer, so any service in the plant consumes location without knowing what produced it. Their stated reason for the open architecture is the one this blueprint keeps arriving at: most localisation products are proprietary and tied to specific hardware, so committing to one commits you to its vendor. The aim is to locate every object in the production process regardless of what does the locating.

Buy the layer, not the radio. UWB goes where centimetres matter, BLE where metres are enough, RFID at the read points, and 5G gets added when it is ready without anything above it changing.

The open standard for that layer is omlox. An industry consortium started it in 2018 and handed governance to PROFIBUS and PROFINET International in 2020, which is the same body behind PROFINET and IO-Link. It has two parts: a hub that presents location from UWB, BLE, RFID, Wi-Fi, 5G and GPS through one interface, and a core zone that lets UWB hardware from different manufacturers work in a single locating zone. TRUMPF, MANN+HUMMEL and Liebherr are running it, with more than sixty partners in the ecosystem.

For now this is a step to watch. When location becomes accurate and cheap at the same time, the constraint on floor autonomy stops being the robot.

08 The closed engineering loop

What it produces. A plant where a change is proven in simulation before it reaches the floor, and where what the floor learns reaches the next design.

The loop is already half closed in most plants that do virtual commissioning. The control code is tested against a simulated cell before anything is installed, so the debugging happens against a model rather than against a line that is supposed to run the week after. What usually happens next is that the model is abandoned once the cell is running, which turns an operating asset into a project artifact.

Kept alive, the model becomes where changes get tried. That progression has four stages and the difference between them is the difference between a demonstration and something a plant uses.

A model is a geometric or physics representation built during design. Accurate the day it is built, diverging from the day the plant changes.

A shadow receives data from the real system in one direction. It shows what is happening and can be inspected. This is where most manufacturing digital twins actually sit, whatever they are called, and Zeekr’s control room screen is one.

A twin is bidirectional. It receives state from the plant and can push changes back, which is the first version that changes how work is done rather than how work is watched.

An active twin runs continuously and evaluates options before they are attempted. The plant tests a change against the model, validates it, and only then applies it to the floor.

Siemens and NVIDIA are building toward the fourth at Siemens’ own electronics factory in Erlangen, where an AI brain built from software-defined automation, industrial operations software and Omniverse libraries continuously analyses the plant’s digital twin, tests improvements virtually and turns validated insights into changes on the shop floor. NVIDIA supplies AI infrastructure, simulation libraries, models and frameworks. Siemens commits hundreds of industrial AI experts alongside its hardware and software. Erlangen is described as a reference environment rather than a deployed production system, and no executable specification for the platform has been published, which Section 8 treats at length. The simulation capability is real. The word they have wrapped around it promises more than it delivers.

The half usually forgotten. Closed properly, the loop runs the other way too. Design informs production, and production informs design. What the process actually holds, which tolerances cost money, which features cause rework, which fixture is always the one that slips: none of it reliably reaches the person drawing the next part. The equipment builders paper makes this the central opportunity, and it is the same opportunity inside a plant that designs what it makes.

A twin fed by real state needs the technology stack underneath it and the network to carry it, which is why this comes after both. Most plants buy an active twin and get a shadow, and the question that separates them is whether anything the model produces is ever applied without a person retyping it.

09 The agentic factory brain

What it produces. The technology stack running at plant scale, coordinating rather than reporting.

Zeekr already calls its control room screen a digital brain, and it is worth being precise about what that is. It is a very good shadow. It shows takt, precision, availability, utility consumption and shop layout, and a person reads it and acts. Nothing on that screen decides anything.

The agentic version is the same picture with the harness underneath it. Published capability from every function, reachable as skills and routines. Rules about what may act and what may only propose. A record of what ran and on what evidence. An operations manager consuming all of it rather than convening meetings to assemble it.

The record so far is poor, and the reason matters. Deloitte’s analysis found 60% of enterprises that piloted multi-agent systems failed to move them into production, with orchestration complexity named as the primary blocker. Other counts of pilot-to-production attrition run higher, and they measure different populations, so the direction is the finding rather than any single rate.

That reads like an integration problem and it is not. It is a scaling problem, and it is the same one the Global Lighthouse Network has spent seven years documenting. McKinsey calls it the scaling slump: plenty of pilots, very few that spread. What separated the sites that scaled was not size, sector or geography.

The method that works is waves. Stack-rank what could be built, pick a small subset, run it in a time-boxed wave of eight to twelve weeks with named owners and a target, then take what you learned into the next one. Three to six weeks up front to set the ambition and build the backlog. Six to eighteen months for the whole programme. The discipline is in the refusal: launching thirty workflows at once produces thirty half-finished workflows.

What makes wave two cheaper than wave one is packaging. The Lighthouse sites that scaled turned each solution into a reusable asset rather than a bespoke build, which is the same test the infrastructure product has to pass. If the second build costs what the first did, the wave produced a deployment and not an asset.

The constraint to plan around is people rather than technology. Waves stall when the same few experts are in all of them, which in most plants means the person holding workflow engineering. Sequence the waves to protect that capacity, and accept that this sets the pace whatever the budget says.

Nobody sells this layer yet. Several vendors describe something close, including the Siemens and NVIDIA partnership in the technology stack section, and what has been specified is an integration framework rather than an executable system.

What this is worth

Which brings the section back to the plant it opened with, and to what is actually worth taking from it.

Not the dark building. The thing worth having is more output from the same footprint and the same people. That funds the next shift and the next line rather than shrinking the current one, and it is the only version of this destination a workforce will help you reach.

It is also the part of the China story worth refusing. Thirty million manufacturing jobs did not relocate, they were automated away, and that social cost is the one thing a Western operator should resolve not to repeat. The method is worth studying. The framing of automation as labour substitution is worth rejecting outright.

The operator’s job

The role does not disappear and it does not stay the same. Three things change.

From performing to deciding. The operator who once ran the cycle now rules on what the system proposes, which is a harder job and a better paid one. The operations manager paper works through what that does to every function.

From one station to one flow. A person supervising an unattended process is not tied to a machine. The unit of responsibility becomes a stretch of the value stream rather than a station in it.

From reacting to teaching. The most valuable thing an experienced operator does here is codify what they know, because that is what the system executes when they are not there. A plant’s best operators become its most valuable employees rather than its most tired ones.

That last change bears directly on flexible production. The bounds an adaptive machine works within are somebody’s judgment written down: how much gap is acceptable, when a correction becomes a defect, when to stop and ask. Those are not vendor parameters. They are the operator’s knowledge in a form the machine can act on. The guardrail on companions applies here more strictly than anywhere else, because an unattended process supervised by someone holding four uncoordinated agents is not a lights-out factory. It is an unmonitored one with a dashboard.

How far away this is

Final assembly in Western Europe runs between 20 and 35%, so the dark factory’s assembly shop is no more automated than a plant in Bavaria. Body shops run at 95 to 98% because the work there is repeatable, and final assembly has lagged for thirty years because variant diversity is highest, tolerance stacks up, and the joining still needs hands and judgment. Semiconductor fabs are far more automated than any car plant, and they got there because the product is uniform and every tool speaks the same handshake, so automation followed standardisation rather than causing it. Which is why the equipment is not what separates Zeekr from a European plant at the same rate. The difference is underneath it: a plant connected end to end, modelled in a twin, and changeable from software rather than from a toolroom.

Lights-out is achieved section by section, never plant-wide. The documented position at Hangzhou Bay is roughly 1.3 million square metres, up to 300,000 vehicles a year, a workforce of about 1,700, and in the welding facility approximately 100 people alongside about 900 robots. That is a remarkable ratio and it is not zero. Management describes the welding shop as near lights-out, press access has been restricted, the claim is not independently verified, and reporting notes that cable assembly still requires a human touch and that workers enter to perform robot maintenance. What transfers is the sequencing: start where the process is most standardized and the variability lowest. The pattern is not new to China either. Fanuc has run robot production with minimal human input for roughly a month at a time since 2001, and Philips runs a razor plant with more than 120 robots and fewer than ten workers focused on quality assurance. The idea itself dates to the 1950s and had its first serious attempt under GM in the 1980s.

Humanoids are further away than the coverage suggests. Figure’s deployment of its 02 robot at BMW Spartanburg ran eleven months and has concluded, contributing to more than 30,000 X3 vehicles and placing over 90,000 sheet metal parts at above 99% accuracy on an 84-second cycle, with more than 1,250 hours of runtime. That last figure averages about 25 hours a week against a nominal ten-hour, five-day schedule, so the parts count sits on a half-time denominator. As of June 2026 BMW is deploying Figure 03 on logistics sequencing at the same site. Agility Robotics has documented more than 65,000 operating hours across nine commercial facilities, with RoboFab in Oregon designed for up to 10,000 units a year at capacity. Tesla’s Optimus had an estimated 1,000 to 1,200 units deployed internally across Fremont and Giga Texas as of mid-2026, with zero external sales and no published uptime, described on the Q4 2025 call as primarily for internal learning rather than productive work. Fremont was converted for Optimus assembly with production targeted for late July or August 2026, so any reader should date-check that. Unitree ships more units by volume than any Western competitor at roughly a tenth of the price. For planning, the most useful anchor is Goldman Sachs’ projection that humanoids could fill only around 4% of US manufacturing labour shortages by 2030.