Manufacturing (Non-Automotive)Future of AI & Visionary Thinking

AI in manufacturing and the quantum era: what changes, what does not, and what to do this year

The quantum era in manufacturing is the period in which quantum processors exist, publish roadmaps and accept pilot workloads, but do not yet beat the best classical method on any production decision. For a plant, that makes quantum-readiness almost entirely classical-readiness: state the constraints, baseline the solver, then watch.

Manufacturing (Non-Automotive) · Future of AI & Visionary Thinking

Atomic Loops EngineeringIndustrial AI practiceReviewed by Atomic Loops Solutions ArchitecturePublished 14 August 202658 min read

Key takeaways

Quantum-readiness in manufacturing is mostly classical-readiness. A quantum solver consumes a constraint model; a plant that cannot state its changeover rules, its sequence dependencies and its calendar has nothing to hand any solver, quantum or otherwise.
Three manufacturing workloads have a credible quantum story — combinatorial scheduling and sequencing, materials and reaction-kinetics simulation, and a small family of optimisation kernels. Process control, vision inspection and demand forecasting have none, and putting them on a quantum roadmap is a category error.
The published roadmaps are specific and modest. IBM states that Starling, its first large-scale fault-tolerant machine, arrives in 2029 with 200 logical qubits running 100 million gates; Google's roadmap ends at roughly a million physical qubits in a room-sized error-corrected machine. Neither commits to beating a classical solver on a named industrial problem.
Most published industrial 'quantum advantage' results are classically reachable at the scale actually demonstrated. The flagship 127-qubit utility experiment published in Nature in 2023 was reproduced more accurately by a tensor-network method on modest classical hardware within months.
One quantum-era item has a published deadline and it is cryptographic, not computational: NIST finalised its post-quantum standards in August 2024, and the UK NCSC tells organisations to complete migration by 2035 — a short window for PLCs, historians and shipped products with twenty-year service lives.

Abbreviations used on this page

MES: Manufacturing execution system
ERP: Enterprise resource planning
APS: Advanced planning and scheduling system
PLC: Programmable logic controller (the plant's control hardware)
OEE: Overall equipment effectiveness
MILP: Mixed-integer linear programming — the classical scheduling workhorse
QUBO: Quadratic unconstrained binary optimisation — the form annealers and QAOA consume
QAOA: Quantum approximate optimisation algorithm
NISQ: Noisy intermediate-scale quantum — today's error-limited hardware
QPU: Quantum processing unit
DFT: Density functional theory — the standard classical method in materials chemistry
PQC: Post-quantum cryptography (NIST FIPS 203/204/205)

What the quantum era actually means for a factory

A definition, the three paths a quantum claim can travel through a manufacturing business, and the one of them with a published deadline.

The quantum era in manufacturing is the period in which quantum processors exist, publish roadmaps and accept pilot workloads, but do not yet beat the best classical method on any production decision a plant actually makes. It is a real period with real deadlines in it — just not the deadlines most roadmaps show. The computational promise sits years out on the publishers' own timelines; the cryptographic obligation is dated, published and running now.

Three manufacturing workloads have a credible quantum story. Combinatorial scheduling and sequencing can be posed as quadratic unconstrained binary optimisation and attacked with QAOA-style approaches (opens in a new tab) or with annealing. Materials, catalysis and reaction-kinetics simulation is the workload with the strongest theoretical argument, because simulating a quantum system on quantum hardware is the thing the machine is natively for. And a small family of optimisation and linear-algebra kernels may eventually gain asymptotic speedups. Everything else on a typical factory's AI roadmap — vision inspection, predictive maintenance, demand forecasting, real-time process control — has no quantum story at all, and putting it on a quantum slide is a category error that costs credibility later.

The honest current state is that all of this runs on noisy intermediate-scale hardware. Physical error rates mean useful circuits are shallow, embedding a real constraint model onto a device's connectivity costs qubits at a punishing ratio, and the instances that fit are routinely instances a laptop closes in seconds. This is not a criticism of the field — it is what the field itself says. The review literature on quantum optimisation explicitly frames advantage as an open question and proposes the benchmarking metrics that would settle it (opens in a new tab), rather than reporting that it has been settled.

The three paths a quantum claim travels through a manufacturer

Same technology, three completely different journeys through a manufacturing business. The top lane is where almost all quantum activity currently sits and where value leaks. The middle lane is what an honest pilot looks like — note that most of it is classical work. The bottom lane is the only one with a published deadline, and it is the one most quantum strategies omit.

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

The process, in words

The claim path: a supplier demonstrates a quantum result, the instance is quietly shrunk until it embeds on the hardware, the pilot produces a press release rather than a comparison, and the ungraded result enters the organisation's roadmap as evidence. Nothing on the line changes, and the next three genuine proposals are harder to fund.
The hybrid path: plant data becomes a written constraint model, the constraint model gets a classical solver baseline with a reported optimality gap, the same instance is mapped to QUBO, and every candidate solver runs under the same wall-clock budget. Whichever wins is written back into the APS or MES with a one-switch fallback. Note that five of the six steps are classical work, and that the classical solver is the expected winner.
The cryptographic path: controllers, historians and shipped products with twenty-year service lives are inventoried by algorithm and key lifetime, a migration plan is written against the published national timeline, and firmware signing and device identity move to the standardised post-quantum algorithms. This is the only lane with dates on it, and design data intercepted today is already exposed to decryption later.

Step-by-step insights

Why the claim path is so hard to leave: Nothing in the claim path is dishonest by intent. A supplier has to demonstrate on something, and only small instances embed on current hardware, so the instance shrinks for entirely practical reasons. The failure is on the buyer's side: nobody in the room can grade the demonstration, so it is remembered as a result rather than as an unfalsifiable event. Three of these accumulate into a corporate belief with no measurement underneath it, and the correction — usually delivered by an outsider during a budget review — costs more credibility than the pilots ever bought. The fix is procedural and cheap: no quantum demonstration enters the record without its instance size, its classical comparison and its wall-clock budget written on the same page.
The constraint model is the asset, not the solver: The written constraint model is the only artefact on this diagram that survives every technology change. Solvers come and go — commercial MILP engines, constraint programming, metaheuristics, annealers, whatever 2033 brings — but they all consume the same thing: an objective, a feasible region, and instances. In practice, writing it is also the highest-value week of the whole programme for reasons that have nothing to do with quantum: it forces the plant to make its scheduling rules explicit, and the disagreements that surface between the model and the scheduler are usually the single most useful output of the exercise.
What the QUBO mapping actually costs: Mapping a production schedule to quadratic unconstrained binary optimisation is not a translation, it is a re-modelling. Hard constraints become penalty terms whose weights have to be tuned; integer quantities become binary encodings that multiply the variable count; and the resulting graph then has to embed onto the hardware's physical connectivity, which on annealing devices costs several physical qubits per logical variable. Every one of those choices changes the difficulty of the instance. A result reported without its penalty weights and its embedding overhead is uninterpretable, which is why the harness records them alongside the objective value.
Same instance, same clock — the only comparison that means anything: The benchmarking rule is deliberately blunt because every softer version has been abused. One instance from the dated production archive, unedited. One wall-clock budget that matches the operational reality — if the schedule has to be out by 06:00, the budget is what is available before 06:00. Every candidate solver runs against that. Results are recorded whichever way they fall, including the runs that failed to embed, because 'did not fit' is a finding about the hardware and belongs in the record. This is close to what the quantum optimisation literature itself asks for when it proposes explicit metrics for comparison with classical techniques.
Why the classical branch is drawn as the likely path to production: The dashed edge from the classical baseline straight to write-back is not cynicism; it is the base rate. On plant-scale instances with real constraints, tuned mixed-integer and constraint-programming solvers remain extremely strong, and the classical state of the art keeps improving — several celebrated quantum demonstrations have been matched or beaten by better classical algorithms rather than by better hardware. A programme designed so that the classical win ships is a programme that delivers value in year one and stays quantum-ready for free. A programme designed so that only a quantum win counts delivers nothing until the hardware does.
The cryptographic lane runs on someone else's calendar: Every other lane on this diagram moves at the pace the plant chooses. This one does not. Standards are finalised, national guidance carries dates, and the assets in scope — controllers, gateways, historians, and especially products already shipped and still under support — have service lives measured in decades. The worst position is not being late to migrate; it is not knowing what you have. A crypto inventory that names the algorithm and the key lifetime for every OT asset and every shipped product line is a few weeks of unglamorous work that converts an open-ended anxiety into a dated, ownable plan.

Read the three lanes together and the page's thesis falls out. Almost everything a manufacturer needs in order to benefit from a quantum computer — a written constraint model, a dated instance archive, a solver baseline, a measured gap, a write-back path — is work that pays for itself immediately in classical form. Quantum-readiness is mostly classical-readiness, and the plants that will adopt a quantum solver fastest are the ones that got very good at optimisation without one.

The five rungs in detail: Unaware to Quantum-ready

For each rung: what it looks like on the plant floor, the diagnostic signals a reviewer can check in an afternoon, the anti-pattern that traps manufacturers there, and what leaving costs.

The ladder below measures readiness rather than quantum activity, which is why a plant with no quantum programme at all can outrank one with a cloud QPU account. Each rung is written for a practitioner: the hallmarks describe observable conditions, the diagnostic signals are checks you can run against your own systems this week, and the anti-pattern is the specific mistake most often made trying to leave that rung.

Two of the five rungs are entirely classical, one is cryptographic as much as computational, and only the fourth involves running anything on quantum hardware. That distribution is the argument. A manufacturer that climbs this ladder gets a better-scheduled plant on the way up whether or not a single quantum machine ever becomes useful to it.

Select a rung

Every rung'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

Unaware

34% of operators sit here

Quantum computing appears nowhere in the plant's plans — and neither does the classical constraint model that would make any solver usable.

Stage 1 is not ignorance of quantum computing; it is the absence of the substrate quantum computing would need. The plant runs, the lines change over, the schedule gets published every Friday afternoon — and none of that exists in a form a solver could read. The changeover matrix lives in a scheduler's head, the calendar lives in a shared drive, and the rules that actually bind (this reactor cannot follow that product without a clean, this line needs a validated operator on nights) live nowhere at all.

That is a perfectly stable place to operate from, and many good plants have run this way for decades. The reason it matters for a quantum page is that the distance from here to any solver — classical, quantum-inspired, or fault-tolerant in 2033 — is identical. Every one of them takes the same input: a stated objective, a stated feasible region, and real instances to test against. A plant at stage 1 has none of the three, so an announcement about logical qubits changes nothing about its position.

The tell that separates stage 1 from stage 2 is not attitude but artefact. Ask for last month's actual schedule and the constraints it had to satisfy. If what comes back is a spreadsheet and a conversation, you are here. That is cheap to fix and expensive to leave unfixed, because every year at stage 1 is a year in which the plant's real operating knowledge stays undocumented and ages with the people holding it.

In practice

The planner who is the model

A specialty chemicals plant runs eleven products across three reactors with sequence-dependent cleaning. One scheduler has done it for nineteen years and is genuinely excellent: changeover time per week is materially below what a naive sequence would produce. Nothing about how she does it is written down. When she took four weeks' leave, changeover minutes rose by roughly a third and nobody could say which rule had been dropped, because no list of rules existed to check against.

What it looks like

Production sequencing is done in a spreadsheet by one experienced planner
No written constraint model exists for any production decision
No optimality gap has ever been computed for any schedule
The cryptographic algorithms running in the OT estate are unrecorded

Diagnostic signals you can check this week

Ask for the sequence-dependent changeover matrix. If it does not exist as a table, you are here
Ask what the plant's scheduling objective is in one sentence — minutes, tonnes, margin — and see whether two people give the same answer
Check whether last quarter's published schedules were archived anywhere a solver could replay
Ask which cryptographic algorithm signs firmware on your PLCs. Silence is the answer at stage 1

Anti-pattern · Answering the board's quantum question with a slide

The board reads a headline about a fault-tolerant machine and asks what the company is doing. The instinct is to produce a strategy deck, join a webinar and put a line item in the three-year plan. It costs a fortnight and buys nothing, because the deck contains no problem statement. The far better answer to the same question is a single page: here is the one production decision worth optimising, here is what it currently costs us, and here is the constraint model we are writing this quarter. That answer is true whether quantum arrives in 2029 or 2039.

What holds you here

No production decision has been written down as an objective plus constraints, so there is nothing for any solver to consume.

Highest-leverage next move

Pick one line and one decision — usually changeover sequencing — and write its constraint model with the person who currently makes it by hand.

Cost of leaving

Effort: 2–4 months
Team: One process engineer and one scheduler, part-time
Risk: Low — the work is documentation and archiving; nothing in production changes
To next stage: 2–4 months

If this is you, the next step is

A two-week engagement: pick the decision, capture the constraints, archive real instances.

Write down one production decision

Stage 2

Watching

41% of operators sit here

Someone tracks quantum computing — a newsletter, a vendor briefing, a consortium seat — but no production problem has been written down in a form any solver could consume.

Stage 2 is the most populated stage and the most self-deceiving, because it produces the appearance of engagement. There is a slide. There may be a consortium membership, a cloud account with a quantum provider, an internal community of interest. What there is not is a problem. The organisation is watching a technology rather than watching a decision, and the two activities feel identical from the inside while producing entirely different outcomes.

The characteristic artefact of stage 2 is the vendor demonstration that nobody could evaluate. A supplier shows a scheduling problem solved on a quantum processor. It looks impressive. Nobody in the room can say what the instance size was, whether a mixed-integer solver was run on the same instance with the same wall-clock budget, or what the optimality gap was — so the demonstration cannot be graded, and it enters the organisation's memory as evidence. Three of these and a plant has a belief with no measurements underneath it.

Leaving stage 2 is not a quantum activity at all. It is picking one decision, writing its constraint model, and running a classical solver against real instances until you can state an optimality gap in plant units. That work is unglamorous, takes a quarter, and is the only thing that converts a quantum interest into a quantum position. It also pays for itself regardless of what any quantum vendor ships, which is the point.

In practice

The demonstration nobody could grade

A packaging manufacturer's innovation team was shown a quantum-annealing demonstration on a line-sequencing problem shaped like theirs. The result was described as a 22% improvement. Six months later, an engineer asked the obvious questions: against what baseline, on how many SKUs, in how much wall-clock time. The answers were: against a greedy heuristic, on twelve SKUs, unbounded. Their actual line runs sixty-plus SKUs, and a standard constraint-programming solver closed the twelve-SKU instance to proven optimality in under a second.

What it looks like

A named person or team follows quantum developments and briefs leadership
Vendor demonstrations have been seen; none was compared against a classical baseline
Quantum appears on the technology roadmap without a named problem attached
The plant's own scheduling problem is still solved by hand or by unaudited APS rules

Diagnostic signals you can check this week

Ask what problem the organisation would put on a quantum computer. A domain name rather than a decision means stage 2
Ask, for the last vendor demonstration seen, what the classical comparison was. Usually there was none
Check whether the quantum line item on the technology roadmap has an owner who also owns a plant metric
Ask how many real, dated production instances exist in an archive that anyone could re-solve. Fewer than ten means the baseline work has not started

Anti-pattern · Buying access before building the problem

The natural response to feeling behind is to procure — cloud QPU credits, a proof-of-concept with a quantum software house, sometimes a hire. It reliably produces a well-written report about a problem the plant does not have, because the vendor must invent an instance in order to have something to run. Instances have to come from the plant, dated and unedited. Buy access after the instance archive exists, and the same money buys a comparison instead of a demonstration.

What holds you here

Attention is on the technology rather than on a decision, so nothing accumulates: every briefing starts the organisation from the same place.

Highest-leverage next move

Convert the watching brief into one classical baseline — constraint model, dated instance archive, reported optimality gap — on a single production decision.

Cost of leaving

Effort: 3–6 months
Team: One optimisation or industrial engineer, one scheduler, a data engineer part-time
Risk: Low to medium — the risk is opportunity cost, not operational
To next stage: 3–6 months

If this is you, the next step is

We take one line, write the constraint model, and hand back a solver baseline in a quarter.

Turn the interest into a baseline

Stage 3

Baselined (classical)

18% of operators sit here

One production decision has a written constraint model, a dated archive of real instances, and a classical solver that reports an optimality gap in plant units.

Stage 3 is where the page's thesis becomes visible: nearly everything a plant needs in order to use a quantum computer one day is work it should have done anyway. A written constraint model, real instances, a solver, a reported gap. Every one of those artefacts pays for itself immediately in classical form, and every one of them is a precondition for any hybrid or quantum run being interpretable.

The reported gap is the artefact that changes the conversation. Once a plant knows that its published schedule sits, say, nine per cent above the best bound its solver can prove, two things become answerable that were not before. First, how much value is actually on the table — because nine per cent of changeover minutes is a number a plant manager already has an opinion about. Second, whether a better solver is worth anything at all: if the gap is under two per cent, no solver on any roadmap will change your week, and the honest quantum answer for that decision is 'never'.

Stage 3 is also where the vocabulary stops being borrowed. A plant at this stage can read a vendor's quantum claim and immediately ask the three questions that grade it: which instance, which classical baseline, which wall-clock budget. Vendors who have those answers become interesting; vendors who do not stop consuming the organisation's attention. That filtering effect, on its own, usually repays the quarter it took to get here.

In practice

The nine per cent that turned out to be two

A glass manufacturer built a constraint-programming model of its furnace campaign and colour-change sequencing, archived eight months of real instances, and ran them nightly. The published schedules turned out to be within roughly two per cent of the proven bound — its schedulers were, in effect, near-optimal. That result killed a proposed optimisation programme and redirected the budget to the maintenance window problem, where the same exercise showed a gap several times larger. Knowing where the gap is not is worth as much as knowing where it is.

What it looks like

A MILP or constraint-programming model exists for at least one production decision
Real, dated, unedited instances are archived and can be re-solved on demand
The optimality gap is reported alongside the objective value, not just the objective value
The gap is expressed in plant units — changeover minutes, OEE points, tonnes — not in solver units

Diagnostic signals you can check this week

Ask to see the optimality gap for last week's schedule. A number, with a date, means stage 3
Ask how many archived instances the model has been run against, and whether any were edited to make them solve
Check whether the gap is quoted in changeover minutes or tonnes rather than in objective-function units
Ask a scheduler whether the model's constraints match what they actually do. Disagreements found here are the most valuable output of the whole exercise

Anti-pattern · Tuning the model instead of shipping it

A solver baseline can absorb an unlimited amount of engineering affection. There is always another constraint to add, another objective term to weight, another instance to fix. Meanwhile the schedule the plant actually runs is unchanged, so the model produces no evidence and eventually no sponsor. Ship the baseline into the scheduler's screen while it is still imperfect and let the disagreements between model and human drive the next iteration; that feedback is worth more than any amount of solitary tuning.

What holds you here

The baseline exists but nothing is compared against it, so the plant still cannot grade a quantum, quantum-inspired or commercial-solver claim on its own problem.

Highest-leverage next move

Stand up a benchmark harness that runs any candidate solver on the same archived instance under the same wall-clock budget, and record the result whichever way it goes.

Cost of leaving

Effort: 6–9 months
Team: One optimisation engineer, one data engineer, a named scheduling owner in operations
Risk: Medium — the first write-back into the APS or MES needs an approval path and a rollback
To next stage: 6–12 months

If this is you, the next step is

We build the constraint model and the instance archive, then report the gap in plant units.

Get your optimality gap measured

Stage 4

Piloting hybrid

6% of operators sit here

Quantum and quantum-inspired solvers run against the same archived instances as the classical baseline, under the same time budget, and the comparison is recorded whether or not quantum wins.

Stage 4 is the first stage that is genuinely about quantum, and it arrives much later than most roadmaps imply. The defining capability is not access to hardware — that is a credit card — but the ability to map a plant problem into the form a quantum or annealing solver consumes, and to do it without quietly changing the problem. Penalty weights on constraints, variable encodings, embedding overhead on hardware topology: each of these is a modelling decision that can make a hard instance easy or an easy instance unsolvable, and each has to be recorded alongside the result.

The discipline that distinguishes a stage-4 programme from a stage-2 demonstration is the harness. Same instance, same wall-clock budget, every candidate solver, result recorded whichever way it falls. Programmes that publish only their wins produce a body of internal evidence that is systematically wrong, and the correction usually arrives at the worst possible moment — during a budget review, from someone outside the team who read the literature.

At this stage the honest expected outcome is that the classical solver wins nearly every time, and that this is fine. The quantum-inspired solvers built on the same QUBO formulation — annealing-style engines running on conventional or specialised classical hardware — sometimes win on very large, loosely constrained instances, and that win is bankable today. A stage-4 programme is therefore best justified internally as an optimisation programme that also happens to be quantum-ready, not as a quantum programme that also happens to optimise.

In practice

The comparison that was worth more than the win

An electronics assembler mapped its board-level setup-minimisation problem to QUBO and ran it three ways: a constraint-programming solver, a quantum-inspired annealing engine and a cloud QPU, all on the same twenty archived instances with a sixty-second budget. The QPU handled the four smallest instances and failed to embed the rest. The quantum-inspired engine matched constraint programming on the largest instances and beat it on two. The programme's most valuable output was a one-page table that settled three years of internal argument.

What it looks like

At least one production decision has been mapped to a QUBO or Ising formulation
A benchmark harness runs classical, quantum-inspired and QPU candidates on identical instances
Results are recorded and published internally regardless of outcome
Someone in-house can explain why a given problem is or is not a candidate

Diagnostic signals you can check this week

Ask to see the QUBO formulation and its penalty weights. If they are undocumented, the results are uninterpretable
Check whether losing runs are recorded in the same place as winning runs
Ask what the largest instance that embedded on hardware was, and how it compares to a production instance
Ask whether anyone in-house has said 'this problem is not a candidate' and been listened to

Anti-pattern · Shrinking the instance until the hardware fits

Hardware limits are real, so the tempting move is to reduce the problem — fewer SKUs, fewer periods, relaxed constraints — until it embeds. The run then succeeds and the result is reported as a scheduling result. It is not: it is a result about a different, easier problem, and the classical solver would have closed that one in milliseconds. Instances must come from the dated archive unedited; if none of them fits the hardware, that fact is itself the finding and belongs in the report.

What holds you here

The comparison exists for one decision only, and the mapping, harness and evidence are held by individuals rather than by the organisation.

Highest-leverage next move

Make the harness and the constraint models solver-agnostic assets — versioned, owned, re-runnable — so a better solver of any kind is a swap rather than a project.

Cost of leaving

Effort: 12–18 months
Team: Optimisation engineer, a quantum-literate researcher or partner, the existing scheduling owner
Risk: Medium — the risk is credibility, not operations: an ungraded pilot damages the next three proposals
To next stage: 12–24 months

If this is you, the next step is

Same instance, same clock, every solver — set up so the result is publishable internally either way.

Design the head-to-head harness

Stage 5

Quantum-ready

1% of operators sit here

The plant can adopt a better solver — quantum or classical — as a swap, because the constraint models, instance archive, benchmark harness and write-back path are solver-agnostic; and the cryptographic migration is running on the published timeline.

Stage 5 is deliberately unromantic. It does not mean the plant runs on a quantum computer; almost no plant will, this decade. It means the plant has arranged itself so that the arrival of a materially better solver is an operational event rather than a transformation programme — the model is already written, the instances are already archived, the harness already runs, and the write-back path into the APS or MES already exists and has a rollback.

The second half of stage 5 is the part most quantum strategies omit entirely. A manufacturer's exposure to quantum computing is not only computational; it is cryptographic, and that side has published deadlines while the computational side does not. Firmware signing keys on controllers, device identities in the plant network, keys embedded in products that will still be in service in the 2040s: all of it currently rests on RSA and elliptic-curve cryptography, and all of it is in scope for a migration that national bodies have already dated.

Sustaining stage 5 is a review discipline. Roadmaps move, standards get profiles, and the classical state of the art improves faster than most people expect — several celebrated quantum results have been overturned by better classical algorithms rather than by better hardware. A stage-5 organisation therefore re-runs its own comparison annually and treats last year's conclusion as provisional. The posture is not enthusiasm and it is not scepticism; it is measurement on a schedule.

In practice

The solver swap that took an afternoon

A pharmaceutical manufacturer with versioned constraint models and an automated harness added a new commercial solver release to its benchmark configuration on a Tuesday. By Thursday it had twenty instances of evidence showing a modest but consistent improvement on its campaign-planning problem, and by the following week the new solver was in production behind the same write-back path. Nothing about that sequence was quantum. Everything about it is what a plant would need in order to adopt a quantum solver the week one became worth adopting.

What it looks like

Constraint models are versioned assets with named owners, independent of any solver
The benchmark harness runs automatically and any new solver is a configuration entry
A crypto inventory covers PLCs, historians, HMIs and shipped product, with key lifetimes recorded
A named owner reviews the published roadmaps against procurement at least annually

Diagnostic signals you can check this week

Ask how long it would take to add a new solver to the benchmark. More than a week means the harness is not yet an asset
Ask whether the constraint model is versioned separately from the solver code
Ask for the crypto inventory's coverage percentage across OT and shipped product
Ask when the published roadmaps were last reviewed against the procurement pipeline, and by whom

Anti-pattern · Declaring readiness and stopping the measurement

Once the harness exists it is tempting to treat the conclusion as settled — 'we tested quantum, classical won' — and stop running it. The field moves in both directions: hardware improves, and so do the classical algorithms that keep overturning quantum claims. A conclusion that is not re-derived annually is a belief, and the organisation will discover it is stale at the moment a competitor or a regulator asks. Keep the harness on a schedule and keep the crypto inventory current; both decay quietly.

What holds you here

Readiness decays: roadmaps move, classical solvers improve, and the crypto inventory ages out of date faster than anyone expects.

Highest-leverage next move

Put the comparison and the crypto inventory on an annual calendar with a named owner, and treat every previous conclusion as provisional.

Cost of leaving

Effort: Continuous
Team: Optimisation owner, OT security owner, a standing annual review
Risk: Concentrated — the exposure is cryptographic and regulatory rather than computational

If this is you, the next step is

We re-run your harness against the current state of the art and audit the crypto inventory.

Stress-test your readiness posture

Where manufacturers actually sit on the readiness ladder

The distribution across the five rungs, and why the Watching-to-Baselined step is the one almost nobody takes.

Most manufacturers are at Watching. A large minority are at Unaware, a meaningful group has done the classical baselining work — often without ever framing it as quantum readiness — and the number running graded head-to-head comparisons against quantum hardware is very small. The shape matters more than the exact figures: the population is concentrated in the two rungs where nothing has been written down, and the step out of them is classical work.

Distribution of manufacturers across the five readiness rungs

Illustrative distribution. Watching is the mode: the rung where quantum is tracked but no production problem has been stated in solver-consumable form. The drop from Watching to Baselined is the largest transition loss on the ladder, and every part of it is classical work.

Share of manufacturers

34% — 1 · Unaware
41% — 2 · Watching (the plateau)
18% — 3 · Baselined
6% — 4 · Piloting hybrid
1% — 5 · Quantum-ready

Source: Illustrative distribution, synthesised from published industrial-consortium participation (QUTAC, QuIC) and the World Economic Forum's quantum economy programme

The figures above are a model, not a measurement, and they are labelled as such. What is externally observable is the participation: the German Quantum Technology and Application Consortium (opens in a new tab) and the European Quantum Industry Consortium (opens in a new tab) each publish member lists dominated by large chemicals, aerospace, electronics and industrial groups, and Fraunhofer's quantum technologies programme (opens in a new tab) exists precisely because mid-sized manufacturers cannot run this work alone. Counted against the number of manufacturers in those economies, the participating population is small — and participation is a Watching-rung signal, not a Baselined one.

That episode is the single most useful thing a manufacturing leader can know about this field, and it is not a scandal — it is how the science is supposed to work. IBM published a careful result on real hardware, in Nature (opens in a new tab); other groups then showed the same system could be simulated classically with better accuracy. The lesson for a plant is procedural rather than sceptical: any claim of industrial quantum advantage should be assumed to have a classical rebuttal in flight, and any internal decision that depends on such a claim should be re-derived annually.

The separation ledger: what quantum changes, and what already holds the record

Six manufacturing workloads, sorted honestly: what a fault-tolerant machine would change, what actually holds the record today, the current status, and the move available this year.

The single most useful thing a manufacturer can do about quantum computing is separate its workloads into the ones where quantum plausibly matters, the ones where it never will, and the one where the deadline is already published. The ledger below does that for six workloads a non-automotive plant actually runs. Read your rows, note that the right-hand column is available this year in every case, and note how rarely the middle columns point at quantum hardware.

Workload	What quantum would change	What holds the record today	Honest status	Your move this year
Changeover sequencing & finite-capacity scheduling	Sequence-dependent setup minimisation posed as QUBO and attacked with QAOA or annealing, in principle exploring a larger neighbourhood per unit time	Mixed-integer and constraint programming with tuned commercial or open solvers; strong metaheuristics for very large instances	No published plant-scale instance where a QPU beat a tuned classical solver under matched conditions; embedding limits real instances to a few hundred variables	Write the constraint model and report the optimality gap. Most plants cannot state their changeover matrix, and that — not the solver — is the binding constraint
Campaign planning, lot-sizing & network design	The same QUBO family at larger scale, with quantum sampling proposed as an escape from local optima	Rolling-horizon MILP with decomposition; the classical bounds are provable, which annealing results are not	Instances small enough to embed are closed classically in seconds; instances that matter do not embed	Measure what the current plan leaves on the table against a proven bound. If the gap is under two per cent, no future solver will change your year
Materials, catalysis & reaction kinetics	Exact ground-state and reaction-path energies for strongly correlated systems where classical approximations degrade — the workload with the strongest theoretical case	Density functional theory, coupled cluster, and tensor-network methods; classical simulation has repeatedly matched quantum hardware at demonstrated scale	The most credible long-run case, and it needs fault tolerance. Publicly funded programmes state their targets as ratios to the classical state of the art	Build the classical simulation and experimental-data pipeline. A plant that cannot run high-throughput DFT today cannot use a fault-tolerant machine in 2033
Real-time process control (kilns, reactors, extruders)	Nothing available in this era. Control loops need millisecond determinism; QPU access is queued, cloud-hosted and batch	Model-predictive control, physics-informed models, reinforcement learning trained in simulation	Not a quantum question. Placing it on a quantum roadmap is a category error that costs credibility when someone checks	Treat it as an instrumentation and MPC programme, and take it off the quantum slide entirely
Quality vision, predictive maintenance & demand forecasting	Quantum machine-learning proposals such as quantum kernels and QSVM variants; loading classical plant data onto a QPU consumes the theoretical speedup	Gradient-boosted trees and convolutional networks on labelled plant data, running on ordinary hardware	No demonstrated advantage on industrial data; the data-loading bottleneck is structural rather than an engineering detail	Fix labelling, traceability and drift monitoring. The constraint here has always been data, never compute
Cryptography protecting long-lived plant and product assets	A cryptographically relevant machine breaks RSA and elliptic-curve schemes — the sign flips, and quantum becomes a risk rather than a tool	RSA and ECC are embedded throughout OT: firmware signing, device identity, secure boot, keys shipped inside products with decade-long service lives	Standards are finalised and national migration timelines are published. This is the one row with dates that are not the plant's to choose	Run the crypto inventory across PLCs, HMIs, historians and shipped product, recording algorithm and key lifetime per asset

The separation ledger. 'What holds the record today' names the incumbent method a quantum claim would have to beat — the column most vendor material omits. 'Your move this year' is available now and pays for itself independently of any hardware timeline.

Three patterns run down the ledger. First, the incumbent classical method is strong and improving in every computational row — the MIPLIB benchmark library (opens in a new tab) has tracked instances moving from unsolvable to routine on classical hardware for three decades, and open toolkits such as OR-Tools (opens in a new tab) put constraint programming inside the reach of any plant with an engineer. Second, the right-hand column never says 'wait': every row has work available now. Third, the sign of the quantum question flips in the last row, and that is the row with published deadlines.

Quantum-inspired solvers are the row most manufacturers should read twice
Once a problem is expressed as QUBO, it can be run on classical hardware built specifically for that form — annealing-style engines on specialised silicon such as Fujitsu's Digital Annealer (opens in a new tab) or Toshiba's Simulated Bifurcation Machine (opens in a new tab). These are entirely classical, available today, and occasionally beat general-purpose solvers on very large, loosely constrained instances. Every hour spent producing a clean QUBO formulation is therefore bankable now, whatever happens to quantum hardware.
The asymptotic argument does not automatically survive contact with real instances
Grover's algorithm is the standard textbook basis for expecting a quadratic speedup on search-shaped problems, but the speedup is stated relative to an oracle whose internal structure is excluded from the accounting. Work published in 2023 and 2024 showed that a classical algorithm with access to the oracle's structure can perform Grover's task in far fewer calls (opens in a new tab), which is exactly the situation a manufacturer is in: you wrote the constraint model, so you have the source code of your own oracle.
Chemistry is the row worth taking seriously on a ten-year horizon
Simulating strongly correlated molecular systems is the workload quantum hardware is natively suited to, and it is where publicly funded programmes are concentrating. The preparation is unambiguous and entirely classical: high-throughput computational chemistry, a curated experimental dataset, and people who can pose a formulation question precisely. Manufacturers with materials or formulation R&D should be building that capability now on its own merits.
The cryptographic row is the one that will be audited
Every other row is a strategic choice. This one becomes a question from a customer, an insurer or a regulator, and the first thing asked will be for an inventory. NIST finalised the first post-quantum standards in August 2024 (opens in a new tab), and OT security frameworks such as the ISA/IEC 62443 series (opens in a new tab) already expect an asset inventory that a crypto inventory extends rather than duplicates.

Triaging a quantum claim before it reaches a roadmap

Plot any quantum claim — a vendor's, a partner's or your own team's — on these two axes. Three of the four quadrants tell you to go and get a classical number before doing anything else, and the fourth tells you the result is useful whichever technology wins.

Real physics, unmeasured claim

Chemistry and materials pilots with no DFT or tensor-network comparison
The theory is sound; the evidence is missing
Fix: demand the classical simulation baseline before funding a second phase

The genuine frontier

Reaction kinetics and catalysis with a stated classical comparison
Publicly funded programmes state targets as a ratio to classical
Fix: participate through a consortium; do not build it alone

Marketing

QUBO scheduling demos with no MILP or CP comparison
Where most vendor claims land
Fix: ask for the instance, the baseline and the wall-clock budget, then stop

Useful either way

Quantum-inspired and annealing engines benchmarked against MILP
You keep the win whichever technology produced it
Fix: run it — this is the quadrant with value available this year

Problem class — top: Simulating a quantum system, bottom: Heuristic combinatorial search

Classical baseline — left: No comparison was run, right: Tuned baseline, same instance, same clock

The matrix is deliberately blunt about where most claims land. It is not a scepticism device — the top-right quadrant is real, publicly funded and worth manufacturer participation. It is a routing device, so that a claim arriving on a Tuesday afternoon gets the same three questions every time, and so that the answer 'we do not have a classical number for that yet' is treated as a finding about the plant rather than as a defeat.

What the published roadmaps actually state

IBM, Google, NIST and the UK NCSC all publish dated commitments. Read side by side, they say something very specific — and something very specific is missing.

The credible roadmaps are public, dated and considerably more modest than the coverage around them. IBM and Google both publish theirs; NIST publishes finalised standards; the UK's National Cyber Security Centre publishes migration deadlines. Read together they describe a decade in which hardware capability is committed in engineering terms, cryptographic obligation is committed in calendar terms, and industrial advantage on a named problem is committed by nobody.

Publisher	Milestone	Stated date	What it states	What it does not state
IBM	Starling	2029	The first large-scale, fault-tolerant quantum computer: 200 logical qubits running 100 million quantum gates, built at IBM's Poughkeepsie facility	That any named industrial problem will clear a classical baseline on it
IBM	Blue Jay	2033+	2,000 logical qubits capable of running 1 billion gates, with intermediate processors (Loon, Kookaburra, Cockatoo) testing the architecture in between	A commercial application, a price, or an advantage claim
Google Quantum AI	Milestone 2 — below-threshold error correction	Achieved 2024	A logical qubit whose error rate falls as the surface code grows, demonstrated on the Willow chip and published in Nature	That any application runs faster as a result
Google Quantum AI	Milestone 6 — large error-corrected machine	No public date	Roughly one million physical qubits working together in a room-sized error-corrected computer, at error rates the programme describes as one-in-a-trillion	A year, and no intermediate industrial deliverable
NIST	FIPS 203, 204 and 205	Finalised August 2024	Standardised post-quantum algorithms — ML-KEM, ML-DSA and SLH-DSA — that organisations can deploy in production today	That existing RSA and ECC deployments remain safe indefinitely
NCSC (UK)	PQC migration timeline	2028 / 2031 / 2035	Discovery and a migration plan by 2028; highest-priority migrations complete by 2031; migration complete by 2035	An exemption for operational technology or for products already shipped

Published commitments, quoted from the publishers' own material. The final column is the discipline: what each roadmap conspicuously does not claim. Every figure here is the organisation's own published target, not a forecast by Atomic Loops.

2029

IBM's stated date for Starling, its first large-scale fault-tolerant machine

IBM Quantum roadmap

~1M

Physical qubits at the end of Google Quantum AI's published roadmap

Google Quantum AI

2035

Year by which the UK NCSC tells organisations to have completed PQC migration

NCSC

Two things follow for a manufacturing plan. First, the computational milestones are engineering milestones — logical qubits, gate counts, error rates — and translating them into 'our scheduling problem gets solved' requires an inference the publishers themselves decline to make. IBM's own explanation of the path to large-scale fault tolerance (opens in a new tab) and the accompanying announcement (opens in a new tab) are worth reading in full precisely because they are specific about architecture and quiet about applications. Second, Google's roadmap (opens in a new tab) and the Willow below-threshold result (opens in a new tab) — published in Nature (opens in a new tab) — are genuine scientific progress on error correction, which is the actual gate on everything else, and are not application claims.

We underscore the importance of benchmarking by proposing clear metrics to conduct appropriate comparisons with classical optimization techniques.
Abbas et al., Challenges and Opportunities in Quantum Optimization

That sentence, from a large multi-author review of quantum optimisation, is the field asking for exactly what this page asks a plant to build: a benchmark harness that compares against classical techniques under matched conditions. It is not a fringe position and it is not scepticism. It is the discipline the researchers themselves say the domain still needs — and a manufacturer that builds it gets a better-scheduled plant as a by-product. For the broader public framing of what governments and standards bodies are actually committing to, NIST's quantum information science programme (opens in a new tab) and the World Economic Forum's quantum economy work (opens in a new tab) are the reference points that do not sell hardware.

What manufacturers with real quantum programmes actually built

Three publicly reported programmes at aerospace and chemicals manufacturers, read against the ladder. In all three the durable asset turned out to be classical.

The manufacturers furthest into this field are not the ones with the most quantum hardware access — they are the ones that first wrote their problems down. Across the three programmes below, the recurring pattern is that the quantum activity forced a piece of classical rigour the organisation had never previously been obliged to produce: a formal constraint model, a high-performance simulation capability, or a stated classical benchmark to be measured against. The most concrete illustration is publicly readable: a submission to Airbus's challenge published the aircraft loading problem as an explicit QUBO model with its flight constraints, benchmarked across available solvers (opens in a new tab) — an artefact that exists because Airbus stated the problem precisely enough for someone else to formalise it.

Three publicly reported programmes, read against the ladder

Outcomes as reported by the operators and their public funders. None is an Atomic Loops engagement and we have not independently audited the figures — verify against the linked source before reusing them. Card images are generated industry scenes from our own library, not photographs of these operators' sites or endorsements by them.

Illustration of an aerospace assembly hall with large airframe structures on jigs

AirbusAerospace manufacturer · commercial aircraft, defence and space23

Challenge: Airbus wanted to know whether quantum computing could touch real aircraft problems. The obstacle was that the problems themselves — wingbox design, aircraft loading, climb optimisation — had never been stated in a form any external solver, quantum or classical, could consume.
Approach: Rather than procure hardware, Airbus published problem statements. It launched a global quantum computing challenge around five flight-physics problems, released with their constraints so external teams could formalise them, and later ran a joint challenge with BMW Group on mobility problems. The organising work was specification, not computation.
Reported outcome: Airbus reports the challenge attracted worldwide participation across the five problem statements and continues to run quantum technologies as a published research theme. Independently, submitted work formalised the aircraft loading problem as an explicit QUBO model with its flight constraints and benchmarked it across available solvers.; What it shows about the curveThe durable asset was the constraint model, not the hardware. A plant that can write its changeover sequencing problem down the way Airbus wrote its loading problem down has done the Baselined-rung work — and that model runs on a classical solver today, on any solver tomorrow.

Airbus — quantum technologies and the Airbus Quantum Computing Challenge (opens in a new tab)

Illustration of a chemicals process plant with computational chemistry workstations alongside

BASFChemicals manufacturer · global process plants and formulation R&D34

Challenge: Molecular, catalyst and formulation design where classical approximations degrade — the workload with the strongest theoretical case for quantum hardware, and one BASF was already spending heavily on classically.
Approach: BASF states that its quantum computing work sits inside an existing high-performance computing capability rather than replacing it, with named research partners including Google, Zapata Computing, Kipu Quantum, NVIDIA, Robert Bosch and HQS Quantum Simulations, academic collaborations, and membership of the German QUTAC and European QuIC consortia. Its published framing focuses on near-term use cases on noisy hardware.
Reported outcome: BASF publishes that it operates one of the chemical industry's most powerful supercomputers for molecular simulation, and positions quantum computing as a research programme running alongside that capability — sharing its people, its problems and its data.; What it shows about the curveSequence is the whole lesson. BASF built the classical simulation capability first; the quantum programme is an option written on top of it. A manufacturer without the classical capability has nothing for a quantum machine to accelerate and no team able to pose it a question.

BASF — Quantum Computing (opens in a new tab)

Illustration of an aerospace materials laboratory with corrosion test coupons and analysis equipment

BoeingAerospace manufacturer · commercial, defence and space34

Challenge: Corrosion, which Boeing states costs the industry $2.5 trillion a year globally. Corrosion kinetics is a chemistry problem that classical methods model slowly and approximately, which puts it in the one workload class with a genuine long-run quantum argument.
Approach: Boeing's QUICK project — QUantum Innovation for Corrosion Kinetics — was selected under the US Department of Energy ARPA-E programme for Quantum Computing for Computational Chemistry, with $2.5 million in funding. The project develops a hybrid quantum-classical workflow across the full stack, from applications down to algorithms, aimed specifically at corrosion use cases.
Reported outcome: Boeing reports it is the only aerospace company funded under the programme, and that the programme's stated target is a 100× performance improvement versus the classical state of the art — a benchmark expressed, explicitly, as a ratio to a classical number.; What it shows about the curveEven at the frontier, success is defined against a classical baseline. If you cannot state your own classical state of the art, you cannot state a quantum target, you cannot tell whether a supplier has met one, and you cannot recognise the moment when adoption becomes rational.

Boeing — quantum computing and the QUICK corrosion project (opens in a new tab)

Two structural observations from reading these together. First, all three organisations reached their position through consortia and public programmes — QUTAC (opens in a new tab), QuIC (opens in a new tab) and ARPA-E (opens in a new tab) — rather than by building quantum capability alone, which is the only affordable route for a mid-sized manufacturer. Second, none of the three describes a production process currently running on quantum hardware. Their programmes are options: cheap to hold, valuable if the technology lands, and structured so the classical spend was worth making anyway. Airbus (opens in a new tab) and Boeing (opens in a new tab) both publish their quantum activity as a research theme rather than as an operational capability, and that framing is the honest one to copy.

The hybrid stack, layer by layer

What actually has to exist for each rung — and why four of the five layers are classical infrastructure a plant should want anyway.

A quantum-ready manufacturing stack has five layers, and the order in which they are built decides whether the programme compounds or produces demonstrations. The architecture below is deliberately vendor-neutral: every layer is defined by what it must guarantee rather than by which product provides it, and each is annotated with the rung that first requires it. Notice how far up the stack you get before anything is quantum.

Layers required by rung

Layers one to three are classical and pay for themselves independently. Layer four is the only one that touches quantum hardware. Layer five runs on someone else's calendar and is the one most quantum strategies omit.

Plant data & constraint capture
Stage 2+
- MES / ERP / APS extractsRoutings, calendars, capacities, yields
- Changeover matrixSequence-dependent setup times, as a table
- Constraint registerEvery rule the scheduler applies that no system holds
- Dated instance archiveReal production instances, unedited, replayable
→
Classical optimisation core
Stage 3+
- MILP / CP modelObjective and feasible region, versioned separately from code
- Solver harnessRuns the archive on a schedule with a fixed time budget
- Optimality-gap reportingObjective and proven bound, converted to plant units
→
Delivery into the plant
Stage 3+
- Write-back to APS / MESThe sequence appears where the scheduler already works
- Approval and override logEvery accept and override, with reason
- Fallback sourceThe current sequence, one switch away
→
Problem mapping & hybrid execution
Stage 4+
- QUBO / Ising formulationWith penalty weights and encodings recorded
- Quantum-inspired solverAnnealing-style engines on classical hardware
- QPU accessCloud-hosted, queued, batch — never in a control loop
- Benchmark harnessSame instance, same clock, results recorded either way
→
Cryptography, governance & procurement
Stage 3+
- Crypto inventoryAlgorithm and key lifetime per PLC, HMI, historian, product
- PQC migration planDated against the published national timeline
- Claim triage in procurementInstance, baseline and time budget required before purchase
- Annual roadmap reviewNamed owner; last year's conclusion treated as provisional

Pipeline described

Plant data & constraint capture (stage 2+) — MES / ERP / APS extracts: Routings, calendars, capacities, yields; Changeover matrix: Sequence-dependent setup times, as a table; Constraint register: Every rule the scheduler applies that no system holds; Dated instance archive: Real production instances, unedited, replayable
Classical optimisation core (stage 3+) — MILP / CP model: Objective and feasible region, versioned separately from code; Solver harness: Runs the archive on a schedule with a fixed time budget; Optimality-gap reporting: Objective and proven bound, converted to plant units
Delivery into the plant (stage 3+) — Write-back to APS / MES: The sequence appears where the scheduler already works; Approval and override log: Every accept and override, with reason; Fallback source: The current sequence, one switch away
Problem mapping & hybrid execution (stage 4+) — QUBO / Ising formulation: With penalty weights and encodings recorded; Quantum-inspired solver: Annealing-style engines on classical hardware; QPU access: Cloud-hosted, queued, batch — never in a control loop; Benchmark harness: Same instance, same clock, results recorded either way
Cryptography, governance & procurement (stage 3+) — Crypto inventory: Algorithm and key lifetime per PLC, HMI, historian, product; PQC migration plan: Dated against the published national timeline; Claim triage in procurement: Instance, baseline and time budget required before purchase; Annual roadmap review: Named owner; last year's conclusion treated as provisional

Step-by-step insights

Plant data & constraint capture — the register matters more than the extract: The MES and ERP extracts are the easy half; every plant can produce them. The constraint register is the half that decides whether the model is usable, because the binding rules in a real plant are largely undocumented: this product cannot follow that one without a validated clean, this grade needs the senior operator, this reactor is derated in summer. Capturing them requires sitting with the scheduler for several days and writing down every objection they raise to a proposed sequence. That week is consistently the highest-value week of the entire programme, and it is the one most often skipped in favour of data engineering.
Classical optimisation core — version the model apart from the solver: The single most important architectural decision on this page is to hold the constraint model as an artefact independent of whichever solver consumes it. Objective, variables, constraints and instance format live in one versioned place; the solver is a configuration entry. Do that and adding a new commercial release, a metaheuristic, an annealing engine or a QPU is an afternoon. Fail to do it and every solver change is a rewrite, which is precisely why so many plants are still running a decade-old configuration inside a vendor's APS with nobody able to say what it optimises.
Delivery into the plant — the fallback is what unlocks approval: The component most often left out is the fallback source: the sequence the plant would otherwise have run, one switch away. It looks like engineering pessimism and it is actually the political key. Operations leaders will accept a new decision source they can instantly revert; they will not accept one they cannot. A write-back proposal with a drilled rollback ships in weeks, and the same proposal without one sits in a change queue for two quarters. The override log it produces is also the dataset that tells you which of your model's constraints are wrong.
Problem mapping & hybrid execution — record the modelling, not just the result: A QUBO run without its penalty weights, its variable encoding and its embedding overhead is an anecdote. The harness should store all three alongside the objective value and the wall-clock time, because those choices routinely change instance difficulty by more than the choice of hardware does. It should also record the runs that failed — the instance that would not embed, the run that hit the queue limit — since 'did not fit' is a genuine finding about current hardware and is exactly the sort of result that quietly disappears from internal memory otherwise.
Cryptography, governance & procurement — the layer with an external clock: This layer is drawn last and is the one with a published deadline. It has three jobs: know what cryptography is running in the plant and in shipped product, hold a dated migration plan against the national timeline, and make claim triage a mandatory procurement step so a quantum claim cannot enter a purchase decision ungraded. The asset inventory that OT security frameworks already require is the natural place to hang the crypto attributes, which makes this cheaper than it first looks — you are extending a register rather than creating one.

Read the fromStage annotations and the argument closes. Four of the five layers are required before a plant reaches the rung where quantum hardware is touched, three of them are pure classical optimisation infrastructure with immediate payback, and the fifth runs on an external calendar regardless of what the plant believes about quantum computing. A manufacturer that builds this stack has bought a better-scheduled plant and a free option on the technology at the same time.

A 90-day plan: the changeover baseline on one packaging line

The Watching-to-Baselined step made concrete on one manufacturing decision — sequence-dependent changeovers on a multi-SKU line. The quarter contains one week of quantum work, at the end, and it is a comparison rather than a bet.

Ninety days is enough to move one production decision from undocumented to baselined, and it is not enough to move a function. To make that concrete, the plan below runs on a specific and extremely common non-automotive manufacturing problem: sequence-dependent changeovers on a multi-SKU packaging or filling line, where the order products run in determines how much of the shift is spent cleaning, purging and re-setting rather than producing. Nothing in the first eleven weeks is quantum, and the plan produces a bankable classical result whether or not the final week's comparison is ever repeated.

Watching to Baselined on one line, in one quarter

One line, one decision, one owner. If a phase overruns its window, narrow the scope — fewer SKUs, one shift pattern — rather than extending the plan. The deliverable at day 90 is a signed classical baseline and a one-page solver comparison.

Days 1–20
Write the constraint model down
Pick one line. Pull routings, SKU families, cleaning and purge rules, tank and CIP constraints, and the labour calendar from the MES, ERP and APS. Then sit with the scheduler for three sessions and record every objection they raise to a proposed sequence — those objections are the constraints no system holds. Archive at least thirty real, dated, unedited production instances from the last six months.
A constraint register and a replayable instance archive
Days 21–45
Solve it classically and report the gap
Build the mixed-integer or constraint-programming model from the register. Run it against the whole archive under the wall-clock budget the schedule actually has — if the sequence has to be published by 06:00, that is the budget. Report the objective, the proven bound and the gap between them, converted into changeover minutes per week and OEE points.
A signed classical baseline with the optimality gap in plant units
Days 46–70
Put the recommended sequence in front of the scheduler
Write the model's recommended sequence into the APS or MES screen the scheduler already works in — not a separate tool. Keep their approval on every sequence and keep the current method one switch away as the fallback. Log every accept and every override with its reason, because the overrides are the fastest route to the constraints the register still misses.
Recommendations in the working screen, with an override log
Days 71–90
Run the honest quantum comparison
Take instances from the archive unedited. Map them to QUBO, recording penalty weights and encodings. Run three ways under the same wall-clock budget: the classical model, a quantum-inspired annealing engine, and whatever QPU access you can obtain. Record every result including the instances that fail to embed, and write the comparison to one page.
A one-page comparison that settles the internal argument for three budget cycles

The order matters

Constraints before solvers
The register is the asset and it takes the longest to produce, because it lives in people rather than systems. Every hour spent choosing a solver before the register exists is an hour spent optimising a problem you have not yet described. A mediocre solver on a correct model beats an excellent solver on a wrong one, every time, and the wrong model is not detectable from its output.
The gap before the ambition
Compute what the current schedule leaves against a proven bound before deciding anything about future technology. If the gap is small, the honest answer for that decision is that no solver on any roadmap — quantum or classical — will change your year, and the budget belongs somewhere else. Knowing where the gap is not is worth as much as knowing where it is.
Same instance, same clock
When the comparison week arrives, change nothing about the instances to make them run. If they will not embed on the hardware, that is the result. Record the losing runs in the same place as the winning ones — a programme that publishes only its wins accumulates evidence that is systematically wrong, and the correction always arrives at the worst moment.
Start the crypto inventory in parallel
The inventory is a different team and a different skill, so it costs nothing to run alongside. Ninety days is comfortably enough to record the algorithm and key lifetime for the controllers, historians and shipped product lines on one site, which is the artefact a customer or insurer will ask for first and the input every migration plan needs.

How manufacturing quantum programmes fail

Five failure modes account for almost all of it, and only one of them is about hardware.

Quantum programmes in manufacturing rarely fail because the hardware disappointed — they fail because the programme was structured so that nothing could be learned from it. The five modes below are ordered by how often we see them in technology plans, and each has a cheap preventive measure that costs less than the pilot it protects.

Likelihood: highImpact: high

The pilot that never had a classical baseline

A quantum or quantum-inspired pilot runs, produces a number, and there is nothing to compare it against — no tuned classical solver, no dated instances, no matched time budget. The result is uninterpretable in both directions: it cannot be claimed as a win and it cannot be dismissed as a loss, so it becomes an opinion. Two of these and the organisation has a quantum position built entirely on unfalsifiable events.

PreventionNo quantum pilot is funded without a named classical solver, a dated instance archive and a reported optimality gap already in place.

Likelihood: highImpact: medium

The instance that shrank to fit the hardware

Hardware limits are real, so the instance gets reduced — fewer SKUs, fewer periods, relaxed constraints — until it embeds. The run then succeeds and is reported as a scheduling result. It is a result about a different, much easier problem, and the classical solver would have closed that one in milliseconds. This failure is especially damaging because it is invisible in the write-up unless instance provenance was recorded.

PreventionInstances come from the dated archive unedited. If none fits the hardware, that is the finding, and it goes in the report.

Likelihood: highImpact: medium

The roadmap slide that quietly became a plan

A publisher's engineering milestone — logical qubits by a date — is copied into an internal three-year plan and, over two planning cycles, acquires an implied application and a business case nobody wrote. Capital and attention then get allocated against an inference the publisher explicitly declined to make. The correction usually arrives from outside the team and takes the credible items down with the incredible ones.

PreventionEvery quantum line item carries the publisher, the published date and the published caveat in the same cell. Items that cannot carry all three come off the plan.

Likelihood: mediumImpact: high

The crypto deadline treated as an IT problem

Post-quantum migration lands with corporate IT, which migrates servers and browsers on schedule and never touches operational technology or shipped product. Controllers, historians and products in the field — the assets with the longest lives and the weakest update paths — are precisely the ones the timeline was written for, and they are the ones outside the programme's scope.

PreventionThe crypto inventory explicitly covers OT and shipped product, and its owner is the plant or product engineering lead, not only IT security.

Likelihood: mediumImpact: medium

Talent bought before the problem exists

A quantum specialist is hired, or a quantum software house is retained, before any production problem has been written down. The specialist is capable and has nothing to consume, so the engagement generates an internal education programme and a proof of concept on an invented instance. When the budget is reviewed, there is no plant metric attached to any of it.

PreventionHire the optimisation engineer first. The quantum specialist becomes useful the week a constraint model and an instance archive exist, and not before.

Grover's algorithm does not have an a priori quantum speedup as soon as one is given access to the “source code” of the oracle.
Stoudenmire & Waintal, Opening the Black Box Inside Grover's Algorithm

That result is worth holding onto because it describes the manufacturer's exact position. A plant that has written its constraint model has, by definition, the source code of its own oracle — it knows the structure of the problem, and structure is what classical algorithms exploit. The textbook quadratic speedup is stated for a black box a factory never actually has. This does not make quantum uninteresting; it makes the naive extrapolation from a textbook speedup to a plant schedule unsound, which is a different and more useful thing to know.

Proving readiness: what to measure, and the checklist

Eight measurements readable from your own systems, and the checklist that decides whether you are genuinely ready to adopt a better solver of any kind.

Readiness is measurable from telemetry rather than from self-report, which matters because self-assessment on this ladder runs consistently optimistic — a single vendor engagement is easier to recall than the absence of a constraint register. Every measurement below reduces to something the MES, the APS, the solver logs or the asset register already record, and each is annotated with the rung at which it first measures something real.

Measurement	How it is read	Source	Honest from
Constraint completeness	Rules in the model ÷ rules the scheduler actually applies, sampled by interview	Constraint register vs MES/APS configuration	Rung 2
Instance realism	Archived instances taken from production, dated and unedited ÷ all benchmark instances	Instance archive	Rung 2
Optimality gap	(Incumbent objective − proven bound) ÷ bound, converted to changeover minutes	Solver logs	Rung 3
Time-to-schedule	Wall clock from data cut to published sequence	APS run log	Rung 3
Write-back coverage	Sequences carrying a model recommendation ÷ all sequences published	APS / MES	Rung 3
Override rate and reasons	Scheduler overrides ÷ recommendations shown, grouped by stated reason	Approval log	Rung 3
Head-to-head coverage	Quantum or quantum-inspired runs with a matched-instance, matched-budget classical run ÷ all such runs	Benchmark harness	Rung 4
Crypto inventory coverage	Assets with a recorded algorithm and key lifetime ÷ all PLCs, HMIs, historians and shipped product lines	Asset register	Rung 3

Readiness build sheet. 'Honest from' is the rung at which the measurement first means something — before that rung, the number exists but nothing is connected to it.

Two of these deserve more attention than they usually get. Override rate with reasons is the cheapest source of truth about the constraint register — every override is a scheduler telling you a rule is missing or wrong, in their own words. And crypto inventory coverage is the only measurement here that an external party is likely to ask for directly, which makes it the one worth being able to quote without preparation.

The quantum-readiness checklist (it is mostly a classical checklist)

Eight items. Tick honestly — six of them are classical optimisation hygiene, one is cryptographic, and only one involves quantum hardware. This list works with JavaScript switched off.

One production decision has a written constraint model, agreed with the person who currently makes itAgreed matters: a model the scheduler disputes is a model that will be overridden.
A dated archive of at least thirty real production instances exists, uneditedUnedited matters more than the count. Instances tuned to solve prove nothing.
A classical solver runs those instances on a schedule and reports a proven bound
The gap between the solver's answer and the schedule actually run is expressed in plant unitsChangeover minutes, OEE points, tonnes — not objective-function units.
Model output is written into the APS or MES the scheduler already uses, with a one-switch fallback
Every quantum or quantum-inspired run is paired with a matched-instance, matched-budget classical runAnd the losing runs are recorded in the same place as the winning ones.
A crypto inventory covers PLCs, HMIs, historians and shipped product, with key lifetimes recorded
A named person reviews the published roadmaps against procurement at least annuallyAnd treats last year's conclusion as provisional, in both directions.

0 of 8 ticked

Nothing ticked — and that is the most common honest answer

Zero is where most plants genuinely start, and it is not a problem to be embarrassed about; it is a quarter of work. Do not begin with tooling or with a vendor. Pick one line, write the constraint model with the scheduler, and archive thirty real instances. Everything else on this list falls out of doing that once.

Scope the 90 days with us

Glossary

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

NISQ: Noisy intermediate-scale quantum: the current generation of quantum hardware, with enough qubits to be interesting but error rates too high for deep circuits or error-corrected computation. Every industrial quantum result published to date runs on NISQ machines.
Logical qubit: An error-corrected qubit assembled from many physical qubits, so that its error rate falls as the code grows. Logical qubits, not physical ones, are the unit in which the fault-tolerant roadmaps state their targets — and the ratio between the two is the field's central engineering problem.
QUBO: Quadratic unconstrained binary optimisation: the mathematical form quantum annealers and QAOA-style algorithms consume. Converting a production schedule into QUBO means turning hard constraints into weighted penalty terms and integers into binary encodings, both of which change how hard the instance is.
QAOA: The quantum approximate optimisation algorithm — a variational method that alternates problem and mixing operations to search for good solutions to combinatorial problems. It is the most-studied route from a factory scheduling problem to a quantum processor, and its advantage over classical heuristics remains unproven.
Quantum annealing: A hardware approach that encodes a QUBO into a physical system and lets it relax toward a low-energy state. Distinct from gate-based quantum computing, commercially available today, and — unlike a mixed-integer solver — it returns no proof of optimality with its answer.
Quantum-inspired solver: A classical solver built to consume the same QUBO or Ising form as quantum hardware, often on specialised silicon. Entirely classical, available now, and occasionally competitive on very large, loosely constrained instances — which makes the QUBO formulation work bankable regardless of quantum timelines.
Optimality gap: The distance between the best solution a solver has found and the best bound it can prove, usually as a percentage. It is the single number that tells a plant how much value a better solver could possibly deliver — and if it is small, no future technology will change the answer.
Instance archive: A dated store of real, unedited production problems that any solver can be replayed against. It is what separates a benchmark from a demonstration, and its absence is the most common reason a quantum pilot produces an uninterpretable result.
Embedding: The mapping of a problem's variables onto a quantum device's physical qubit connectivity. On annealing hardware it typically consumes several physical qubits per logical variable, which is why a problem that fits on paper often does not fit on the machine.
Tensor network simulation: A family of classical methods that represent quantum states compactly when correlations are limited. Tensor-network simulations have repeatedly matched or beaten quantum hardware results at the scale industrial claims are demonstrated at, and are the standard classical rebuttal to a quantum advantage claim.
Post-quantum cryptography (PQC): Cryptographic algorithms designed to resist attack by a future large-scale quantum computer. NIST finalised the first standards — ML-KEM, ML-DSA and SLH-DSA — in August 2024, and national bodies have published migration deadlines that apply to operational technology and shipped products.
Harvest now, decrypt later: The practice of intercepting encrypted traffic today in order to decrypt it once a capable quantum computer exists. It is why long-lived confidential material — process recipes, formulation data, design files in transit — is already exposed, regardless of when the hardware arrives.

Frequently asked questions

The questions manufacturing leaders ask most often when a quantum headline reaches the board.

Should a manufacturer be doing anything about quantum computing this year?

Yes, and almost all of it is classical. Write the constraint model for one production decision, archive real instances, run a classical solver and report the optimality gap in plant units. That work is the precondition for using any future solver, and it pays for itself immediately. The one genuinely quantum-specific item is the crypto inventory: record which algorithms and key lifetimes are running in your controllers, historians and shipped products, because that is the only part of the quantum era with published deadlines.

Can a quantum computer optimise my production schedule today?

No. Instances small enough to run on current hardware are instances a classical solver closes in seconds, and plant-scale instances do not embed at all. The route from a schedule to a quantum processor also passes through a QUBO reformulation that turns hard constraints into weighted penalties, which changes the problem and removes the proof of optimality a mixed-integer solver gives you. Quantum-inspired solvers running on classical hardware consume the same formulation and are available now, which makes the reformulation work worth doing on its own merits.

Which manufacturing problems have a genuine long-run quantum story?

Three families. Combinatorial scheduling and sequencing, where the problem maps naturally to QUBO and Ising forms. Materials, catalysis and reaction kinetics, where simulating a quantum system on quantum hardware is the strongest theoretical argument in the field. And a small set of optimisation and linear-algebra kernels that may gain asymptotic speedups. Everything else on a typical factory roadmap — vision inspection, predictive maintenance, demand forecasting, real-time process control — has no quantum story, and listing it is a category error.

What do IBM and Google actually commit to in their published roadmaps?

IBM commits to Starling in 2029 — its first large-scale fault-tolerant machine, stated as 200 logical qubits running 100 million gates — followed by Blue Jay at 2,000 logical qubits and a billion gates from 2033. Google's roadmap runs through six milestones, ends at roughly a million physical qubits in a room-sized error-corrected computer, and carries no public date for that end point. Both are engineering commitments in qubits, gates and error rates. Neither commits to beating a classical method on a named industrial problem.

Why do published quantum advantage claims keep getting reversed?

Because the demonstrations run at scales classical methods can still reach, and classical algorithm research is very active. The clearest case is the 127-qubit experiment published in Nature in 2023 as evidence of utility before fault tolerance: within months, a tensor-network method reproduced the same system more accurately and to longer times on modest hardware. That is science working correctly rather than a scandal, but it has a practical consequence — assume any industrial advantage claim has a classical rebuttal in flight, and re-derive any decision that depends on one.

How much would a serious quantum readiness programme cost us?

The classical core is one optimisation engineer, one data engineer and a named scheduling owner for roughly two quarters per production decision — the same investment as any optimisation programme, with the same payback. Quantum hardware access itself is cheap and rarely the constraint. The expensive mistakes are the other direction: retaining a quantum software house or hiring a specialist before a constraint model exists, which reliably produces a well-written report about an invented instance and no plant metric.

Is post-quantum cryptography really a manufacturing problem rather than an IT one?

It is more urgent in manufacturing than in most industries, because of asset lifetimes. Controllers, gateways and historians stay in service for decades and often cannot be patched on an IT cadence, and products already shipped may carry embedded keys that must remain trustworthy into the 2040s. NIST finalised the standards in August 2024 and the UK NCSC publishes a timeline of discovery by 2028, priority migration by 2031 and completion by 2035. None of those dates exempts operational technology, and the first thing anyone will ask for is an inventory.

What is a QUBO, and why does everyone keep mentioning it?

Quadratic unconstrained binary optimisation is the input form that quantum annealers and QAOA-style algorithms accept, so any production problem heading toward quantum hardware must be rewritten into it. The rewrite is consequential rather than cosmetic: hard constraints become penalty terms whose weights need tuning, integers become binary encodings that multiply the variable count, and the result must then embed onto the hardware's connectivity. Recording those choices is what makes a result interpretable, and their absence is why many published comparisons cannot be graded.

How do we grade a supplier's quantum claim without a physicist in the room?

Three questions cover most of it. Which instance — how many SKUs, periods and constraints, and did it come from a plant or from the supplier? Which classical baseline was run on that same instance, and by whom? What wall-clock budget did each solver get? A claim that cannot answer all three is not gradeable and should not enter a roadmap. A supplier that answers all three willingly is worth continuing with, whatever the result was, because they are operating the same discipline you are.

Should we join a quantum consortium?

For most mid-sized manufacturers, yes, and for a specific reason: it is the affordable way to hold an option. Industrial consortia such as QUTAC in Germany and QuIC in Europe, and applied research organisations such as Fraunhofer, exist because no individual manufacturer can justify building this capability alone. Treat membership as a Watching-rung activity, though, not as readiness. Consortium participation without a constraint model and an instance archive leaves you exactly where you started, with a better newsletter.

What changes on our plans if a fault-tolerant machine arrives earlier than 2029?

Very little, which is the point of building this way. An earlier machine would move the date at which a solver swap becomes worth making; it would not change the constraint model, the instance archive, the benchmark harness or the write-back path, all of which are solver-agnostic. The plants that adopt fastest will be the ones that spent the interval getting very good at classical optimisation, because they are the only ones able to state a problem, run a comparison and put the winner into production inside a quarter.

Does any of this differ for process manufacturing versus discrete?

The ladder is identical; the first decision differs. Process plants — chemicals, food, glass, cement, pharmaceuticals — usually find their largest gap in campaign sequencing and changeover minimisation, where cleaning and grade-transition rules dominate and the constraint register is large and undocumented. Discrete manufacturers more often find it in setup minimisation and line balancing across a wide product mix. Materials and formulation simulation is a process-industry story almost exclusively, and it is the workload with the strongest long-run quantum argument.

About the author

Atomic Loops Engineering

Industrial AI practice

Atomic Loops builds production AI and optimisation systems for manufacturing, logistics and energy operators — scheduling, sequencing, quality prediction and decision support running against live plant data and written back into the MES, ERP and APS layer rather than delivered as dashboards.

· Production deployments across process, discrete and batch manufacturing
· Constraint models and solver baselines built with plant scheduling teams
· Integration-first delivery: MES/APS write-back, monitoring, rollback
· 34 cited sources on this page

Sources

AI-driven disruptions and innovations in manufacturingThe near-term technologies that will change a plant before any quantum machine does — and how to tell them apart.AI readiness and transformation roadmap for manufacturingSequencing the classical foundations — data, constraint models, integration — that every later capability depends on.Manufacturing industry practiceProduction AI and optimisation systems Atomic Loops has built for process, batch and discrete manufacturers.

Get the classical baseline that makes any future solver adoptable

We take one production decision, write its constraint model with your schedulers, archive real instances and report the optimality gap in changeover minutes and OEE points. It is the work that pays for itself now and makes a quantum solver a swap rather than a programme later. You keep the model and the baseline either way.

Book a readiness review See our manufacturing work

Published 14 August 2026 · Last updated 14 August 2026

Key takeaways

Abbreviations used on this page

Score your plant's quantum readiness

What the quantum era actually means for a factory

The five rungs in detail: Unaware to Quantum-ready

Unaware

Watching

Baselined (classical)

Piloting hybrid

Quantum-ready

Where manufacturers actually sit on the readiness ladder

The separation ledger: what quantum changes, and what already holds the record

What the published roadmaps actually state

What manufacturers with real quantum programmes actually built

The hybrid stack, layer by layer

Plant data & constraint capture

Classical optimisation core

Delivery into the plant

Problem mapping & hybrid execution

Cryptography, governance & procurement

A 90-day plan: the changeover baseline on one packaging line

The order matters

How manufacturing quantum programmes fail

The pilot that never had a classical baseline

The instance that shrank to fit the hardware

The roadmap slide that quietly became a plan

The crypto deadline treated as an IT problem

Talent bought before the problem exists

Proving readiness: what to measure, and the checklist

Glossary

Frequently asked questions

Should a manufacturer be doing anything about quantum computing this year?

Can a quantum computer optimise my production schedule today?

Which manufacturing problems have a genuine long-run quantum story?

What do IBM and Google actually commit to in their published roadmaps?

Why do published quantum advantage claims keep getting reversed?

How much would a serious quantum readiness programme cost us?

Is post-quantum cryptography really a manufacturing problem rather than an IT one?

What is a QUBO, and why does everyone keep mentioning it?

How do we grade a supplier's quantum claim without a physicist in the room?

Should we join a quantum consortium?

What changes on our plans if a fault-tolerant machine arrives earlier than 2029?

Does any of this differ for process manufacturing versus discrete?

About the author

Sources

Related reading

Get the classical baseline that makes any future solver adoptable