When AI Gets Factory Scheduling Wrong, It Now Knows Why

When AI Meets the Factory Floor: How Language Models Are Learning to Schedule the Unschedulable

In a modern car factory, thousands of operations happen simultaneously. Robots weld while conveyors move, and multiple production lines compete for the same limited resources—shared加工中心, storage buffers, robotic arms. Getting this right requires solving what's called a reachability problem: can the factory reach a desired state from where it starts? And if so, what's the sequence of steps to get there?

This sounds abstract, but it isn't. It determines whether a factory can meet an order deadline, whether a production line will deadlock at a crucial moment, whether a scheduler can find a viable firing sequence in time to save a day's output. For decades, engineers have used mathematical tools called Petri nets to model these systems and search for solutions. But the search space explodes as factories grow more complex, and traditional methods—brute-force graph searches, hand-tuned heuristics—struggle to keep pace.

Now, researchers from Imperial College London are trying something different. They asked: what if a large language model could find these sequences? Not by being programmed with rules, but by reasoning about the problem in natural language?

The results are striking. Their framework—paired with a two-stage "reflection and reprompting" mechanism—achieved a 100% success rate across 30 independent test runs on an industrial-scale manufacturing scenario. On the hardest cases, where the AI's first attempt failed every time, the reflection mechanism salvaged the solution 100% of the time (Hu & Mercangöz, 2026).

This isn't a toy problem. It's a real-world-inspired manufacturing cell with three inbound lines, parallel processing routes, and a shared, capacity-limited resource pool—the kind of setup that causes genuine headaches on real factory floors. And the framework works across different AI models: GPT-4o, Deepseek-chat, and Gemini-3-Flash all achieve near-perfect or perfect success rates when paired with the reflection mechanism.

The finding flips a common assumption. AI systems are often dismissed as too unreliable for mission-critical industrial tasks—too prone to hallucination, too prone to confident nonsense. This paper suggests that the problem isn't the AI itself, but how we ask it to reason. Give it the right feedback loop, the right structure for self-correction, and it can navigate constraints that would baffle a simpler optimization routine.

The Science: Modeling a Manufacturing Cell as a Petri Net

Before understanding the solution, it helps to understand the problem. Petri nets are a formalism—essentially, a precise mathematical language—for describing systems where events happen in discrete steps and where multiple processes can run concurrently.

A Petri net consists of places (represented as circles) and transitions (represented as rectangles). Places hold tokens—think of them as resources or states. Transitions are actions that consume tokens from some places and produce tokens in others. When a transition "fires," it moves the system from one marking (the distribution of tokens across places) to another.

This maps naturally to manufacturing. A place might represent "Robot A is idle" or "Buffer has three widgets." A transition might represent "Robot A welds widget X" or "Conveyor moves widget Y to next station." The initial marking describes where the factory starts; the target marking describes where you want it to end up. The reachability problem is: find a sequence of transitions that gets you there.

The challenge is that the number of possible sequences grows astronomically with the size of the net. A factory with 20 places and 15 transitions might have millions of reachable states. Traditional methods—depth-first search, breadth-first search—must explore this state space explicitly. They work for small systems but hit a wall as complexity rises. Optimization-based methods like integer linear programming can find exact solutions, but they require significant computational time and expertise to set up. Heuristic approaches are faster but brittle; when the factory layout changes, the heuristics often need redesign from scratch.

LLMs offer a different paradigm. Rather than searching the state space explicitly, an LLM can potentially reason its way to a solution. Feed it a description of the Petri net and the desired goal, and ask it to generate a sequence of transitions. The appeal is flexibility: no hand-crafted search tree, no expert-tuned heuristics—just natural language and learned reasoning.

But there's a catch. "Potentially" is doing a lot of work in that sentence. As Hu and Mercangöz note, direct use of LLMs for Petri net reachability "remains unreliable." The AI might propose a transition that isn't enabled (the necessary tokens aren't in the right places), might trigger a deadlock, or might simply output a sequence that doesn't reach the target marking. For manufacturing systems, where a wrong schedule can shut down a production line, "unreliable" isn't good enough.

The Imperial College researchers tackled this head-on. Their experimental setup uses an industrial case study modeled as a Petri net with 10 places and 10 transitions. The system receives workpieces from three heterogeneous inbound lines, processes them through parallel routes, and merges them at a shared workstation with capacity 1—meaning only one product type can use it at a time. This creates genuine resource contention, the kind that causes real scheduling headaches.

To evaluate their method, they constructed six "reachability configurations": different combinations of initial and target markings that share the same net structure. These range from relatively straightforward (case01, where the LLM succeeds on the first try 100% of the time) to genuinely difficult (case05, where first-pass success drops to 0% and the system requires an average of 2.4 retries per run).

Each configuration was run five times, for 30 total runs. The metrics tracked: overall success rate (did the system eventually find a valid sequence?), first-pass success rate (did it work on the first try?), repair success rate (when the first attempt failed, did the reflection mechanism eventually fix it?), and average retries required.

What They Found: Reflection Transforms Reliability

The headline result is clean: across all 30 runs on the six configurations, the framework achieved a 100% overall success rate. Every single run eventually produced a verified firing sequence that reached the target marking exactly. This wasn't a cherry-picked dataset or a trivial problem—it was a multi-product manufacturing cell with genuine concurrency and resource contention.

But the deeper story lies in what happened before that final success. The first-pass success rate tells a more nuanced tale.

First-Pass vs. Repair Success Rates Across Cases

Label	Value
case01	100
case02	80
case03	60
case04	80
case05	0
case06	20

First-pass success drops to 0% on harder cases, but repair mechanism recovers 100% of failures on case05. Aggregated first-pass rate: 56.67%.

On easier cases—case01 through case04—the LLM frequently nailed the solution on the first attempt. case01 had a 100% first-pass success rate; case02 and case04 sat at 80%. These are configurations where the target marking is relatively close to the initial state, where the required sequence is shorter and the resource contention less severe.

The interesting cases are case05 and case06. In case05, the LLM's first attempt succeeded zero percent of the time. Without any correction mechanism, this would be a complete failure. With the reflection and reprompting framework, the repair success rate hit 100%—every initial failure was eventually fixed, and the system found a valid sequence. The cost was an average of 2.4 retries per run, but the problem was solved.

case06 tells a similar story, albeit less extreme. 20% first-pass success, 80% repair success, 0.8 average retries. The pattern is clear: when the problem gets hard enough that the LLM can't solve it immediately, the reflection mechanism acts as a reliable backstop. It doesn't guarantee success on the first try—that's not the point. It guarantees that failures become recoverable.

Aggregating across all cases, the overall first-pass success rate was 56.67%, with a repair success rate of 43.33%. Nearly half of all successful solutions came through the reflection mechanism. The average number of retries per run was 0.67—meaning most runs needed fewer than one retry on average, but those that needed retries could count on the system to deliver.

To test whether this was specific to GPT-4o, the researchers ran the same pipeline on Deepseek-chat and Gemini-3-Flash.

Cross-LLM Comparison of Overall Success Rate

Label	Value
GPT-4o	100
Deepseek-chat	100
Gemini-3-Flash	96.67

GPT-4o and Deepseek-chat achieved 100% overall success; Gemini-3-Flash reached 96.67%. Repair mechanism salvaged failures across all models.

The framework is not tied to any single model. Deepseek-chat achieved 100% overall success with 66.67% first-pass rate and 0.33 average retries—actually better than GPT-4o on some metrics. Gemini-3-Flash came in at 96.67% overall success, 70% first-pass rate, and 1.13 average retries. The slight miss on overall success (one run out of 30 failed to converge) is worth noting, but even there, the repair mechanism salvaged 26.67% of failed first attempts.

The comparison reveals something important: different LLMs have different raw capabilities (GPT-4o and Deepseek needed fewer retries than Gemini), but the framework provides a consistent boost. The reflection mechanism is a structural improvement that works across model architectures.

Why This Changes Things: Beyond the Factory Floor

The immediate application is industrial scheduling, and it's not hard to see why this matters. Manufacturing systems are increasingly dynamic—orders arrive mid-shift, machines go down, priorities shift. Traditional scheduling approaches require either significant computational time (for optimization-based methods) or significant expert time (for heuristic approaches that need retuning when conditions change). An LLM-based scheduler that can generate and verify firing sequences in natural language could adapt faster and with less human intervention.

But the deeper significance goes beyond any single application. What Hu and Mercangöz have demonstrated is a pattern for making LLMs reliable enough for constraint-heavy tasks: structured self-correction with closed-loop verification.

The framework has two stages. When a generated sequence fails verification—because a transition wasn't enabled, or the final marking doesn't match the target—the system doesn't just ask for another guess. Instead, it first asks the LLM to reflect: diagnose the failure, identify what went wrong, and propose a repair plan. This reflection output then becomes part of the prompt for the next attempt. The LLM isn't just told "you're wrong"; it's given a structured analysis of why it's wrong and how to fix it.

This is a meaningful shift. It treats the LLM not as an oracle that should know the answer immediately, but as a reasoning agent that can improve its output when given the right context. The verification loop provides ground truth; the reflection stage translates that ground truth into actionable guidance.

The manufacturing context is demanding—it involves strict constraints, exact solutions, and real consequences for failure. If this pattern works there, it suggests it could work elsewhere. Logistics, supply chain optimization, workflow scheduling in healthcare or software deployment, any domain where a sequence of actions must satisfy a set of hard constraints could potentially benefit from a similar approach.

The authors are careful not to overclaim. They note that their evaluation is on a single industrial case study, and the six configurations share the same net structure. The framework's performance on fundamentally different net topologies remains an open question. There's also the matter of the single failure case with Gemini-3-Flash—at scale, where hundreds or thousands of reachability problems need solving, even a 3.33% failure rate might be unacceptable, and understanding why one model occasionally fails to converge matters.

What's Next: Scaling, Generalizing, and the Question of Deployment

The natural next questions are scalability and generalization. The case study is industrial-scale but not industrial-sized. A real factory might have hundreds of places and transitions, not ten. The state space of such systems is astronomically larger, and it's an open question whether the reflection mechanism scales gracefully or whether computational costs become prohibitive.

There's also the question of whether the framework can handle unsolvable problems. The paper evaluates only on "solvable reachability configurations"—cases where a solution is known to exist. In practice, a scheduler also needs to know when a goal is impossible: when the target marking can't be reached no matter what sequence is tried. Detecting infeasibility is a different problem from finding a solution, and whether the LLM can reliably distinguish "this is hard" from "this is impossible" is an important direction for future work.

Another open question is how the framework handles evolving systems. Manufacturing cells change—new machines are added, production routes are modified, capacity constraints shift. The paper notes that this adaptability is a motivation, but the evaluation holds the net structure fixed. If the Petri net itself changes, does the framework need retraining, or can it generalize from the description of a new net?

There's also a more practical question: what does "temperature set to 0" mean in deployment? The experiments use deterministic sampling (temperature 0 means the model always picks its most likely next token), which reduces variance but also reduces creativity. For genuinely novel problems, some randomness might be beneficial. Understanding the tradeoff between determinism and exploration is a implementation question that matters for real-world use.

The broader research agenda the paper opens up involves treating LLMs not just as text generators but as components in verified systems—agents whose outputs are checked, whose failures are diagnosed, and whose reasoning can be steered by structured feedback. This is a growing area of research, but the Petri net domain offers a clean testbed: precise formal semantics, clear success criteria, real-world motivation. It's the kind of domain where progress is measurable and applications are concrete.

For now, the core finding stands: a two-stage reflection and reprompting mechanism turns an unreliable LLM into a reliable solver for industrial-scale reachability problems. The reflection stage costs a extra LLM call per retry, but it transforms the success rate from "sometimes works, mostly doesn't" to "works every time, eventually." That's a meaningful difference for any domain where correctness matters more than speed.

The factory floor is one of the hardest places to schedule: strict constraints, multiple concurrent processes, shared resources that can't be in two places at once. If AI can learn to navigate that complexity reliably, the implications extend well beyond manufacturing.