PACMAN AI Framework Moves Fast, but Hardware Safety Limits Stay in Charge

The PACMAN AI framework made control decisions every 20 milliseconds during five fusion experiments, while a separate output layer retained authority over hardware safety limits. That separation matters because the machine-learning models could influence heating, plasma density, rotation, and instability prevention in real time.

Developed by Princeton Plasma Physics Laboratory and Princeton University researchers, PACMAN stands for Prediction And Control using MAchiNe learning. It connects multiple machine-learning models to the control system of the DIII-D National Fusion Facility in San Diego.

The important story is not that AI operated scientific equipment. Researchers have already used machine learning for individual fusion control problems. PACMAN instead creates shared infrastructure for combining models without letting any model become the final authority over the machine.

That design places two goals in direct tension. AI needs enough freedom to react faster than humans, yet safety controls must remain predictable when the model encounters unfamiliar conditions. PACMAN’s answer is architectural separation: models propose actions, while deterministic control logic decides what the hardware can accept.

This approach does not eliminate human oversight. Researchers still set experimental goals, define operating parameters, and review results between experiments. Nor has PACMAN been demonstrated on routine laboratory instruments outside fusion research.

Still, the tests provide a concrete example for laboratories considering AI-driven automation. The safest deployment may depend less on making models perfectly reliable and more on limiting the consequences when they are wrong.

The PACMAN AI Framework Connects Several Models to One Control Loop

PACMAN turns separate machine-learning experiments into a coordinated control system without giving those models unrestricted access to the tokamak.

The framework was described in a peer-reviewed PACMAN control paper published in Nuclear Fusion. Its authors designed PACMAN for DIII-D, a tokamak operated as a US Department of Energy user facility.

A tokamak uses magnetic fields to confine plasma, an electrically charged gas heated to extreme temperatures. Researchers continuously adjust magnets, gas injectors, and heating systems to keep that plasma within a useful operating regime.

Those adjustments create a demanding control problem. Plasma conditions can change within milliseconds, while detailed physics simulations can require days or months. A model suitable for planning next year’s experiments cannot manage an instability developing during the current shot.

PACMAN addresses that timing mismatch with a repeating control loop. The system gathers measurements such as temperature, density, and magnetic signals. It checks those inputs for errors and packages them in a common format.

Machine-learning models then read the measurements relevant to their assigned tasks. Some models estimate the plasma’s present state, while others predict a future event or calculate an action.

Controllers convert those results into proposed commands. The commands can change heating power, move a gyrotron mirror, or adjust another available actuator.

The final stage is deliberately separate. It resolves conflicts when controllers request incompatible actions, applies hardware limits, and sends only acceptable commands to the tokamak.

That output stage changes the meaning of AI control. A model can recommend an action, but it does not receive unlimited authority to execute that action.

The architecture also keeps individual models independent. Researchers can add, remove, or replace one model without redesigning every other component. According to the PPPL project account, installing the first model took months, while adding the second took several days.

Faster integration matters at DIII-D because experimental access is limited. A model that requires months of custom control engineering creates fewer opportunities for testing, correction, and comparison.

PACMAN’s modularity reduces that integration burden. It also creates a stable boundary between experimental model code and established machine-control functions.

The five demonstrations covered more than one narrow prediction task. PACMAN let a reinforcement-learning controller operate heating systems, predicted edge energy bursts, and controlled waves driven by fast particles.

It also adjusted plasma density and rotation toward researcher-defined targets. Another configuration predicted a tearing mode and changed the plasma before that instability developed.

A tearing mode is a disturbance that alters the plasma’s magnetic structure and can terminate a fusion experiment. Conventional controllers often respond after the disturbance has already begun.

In one PACMAN experiment, a model predicted the event about 200 milliseconds in advance. That window gave the control system time to adjust the plasma before suppression became necessary.

The framework also coordinated all six gyrotrons at DIII-D. These devices deliver microwave heating to the plasma, and their mirrors and power levels can be adjusted during an experiment.

Coordinating those machines required the system to satisfy several goals simultaneously. The experiment therefore tested more than a single model connected to a single actuator.

The result remains a research demonstration, not a production certification. However, it shows that integrated AI control can operate on physical scientific hardware while preserving a separate enforcement point.

Twenty Milliseconds Changes Who Can Make the Decision

The speed advantage pressures laboratories to delegate immediate control, but it does not justify delegating safety policy.

A focused human operator reacts on the order of seconds, according to PACMAN co-lead author Andy Rothstein. The full PACMAN loop typically runs in about 20 milliseconds and repeats throughout an experiment.

That difference is not merely convenient. It determines whether a controller can respond while a useful intervention remains possible.

A tearing mode can grow quickly enough to end a plasma discharge. Waiting for an operator to interpret several diagnostic signals and choose an action can consume the available response window.

Machine learning can evaluate those signals faster. It can also approximate plasma behavior without running the slower simulations used for offline scientific analysis.

This creates pressure on fusion facilities that rely on manually configured control paths or isolated automation. Faster models can coordinate more signals and actuators than operators can manage moment by moment.

The same pressure will emerge in other scientific environments. Automated chemistry, materials testing, microscopy, and bioprocessing all combine software decisions with physical equipment.

Yet speed also compresses the time available to notice a bad command. A controller repeating every 20 milliseconds can execute many actions before a person understands what changed.

That is why PACMAN’s speed cannot be considered separately from its constraints. The system gains operational authority only inside boundaries established by its human designers.

The distinction resembles the difference between a goal and a permission. Researchers can ask a controller to reach a target plasma state. Hardware rules determine which actions remain permissible along the way.

PACMAN’s control loop also preserves human involvement across a longer timescale. Physicists define goals before a shot, examine the results afterward, and adjust controller settings for later experiments.

Humans therefore govern the experiment without attempting to approve each millisecond-level decision. This layered timing model offers a more realistic form of oversight than placing an approval prompt before every command.

The pressure falls on laboratory managers as much as model developers. Managers must identify which decisions require instant automation and which policies must remain outside the model.

They also need to specify who can change those policies. A safety limit that exists in separate software provides little protection if routine model updates can silently rewrite it.

Change management becomes central under this architecture. Teams need distinct review processes for models, controllers, safety constraints, and physical equipment configurations.

Logs must preserve the same separation. An investigator should be able to determine what the model predicted, what the controller requested, and what command the output stage allowed.

That record becomes essential after an unexpected result. Without it, teams cannot distinguish model error from bad sensor data, a conflicting controller, or an actuator failure.

PACMAN does not supply a universal governance package for every laboratory. It does demonstrate why authority must be divided before automation moves faster than human reaction.

The Model Proposes, but the Safety Layer Decides

PACMAN’s central tradeoff gives machine learning room to optimize while denying it the final word on physical limits.

Machine-learning systems behave differently from conventional control rules. Their outputs depend on training data, model structure, input quality, and conditions encountered during operation.

A model can produce a syntactically valid command that remains physically inappropriate. It might request a change too quickly, misread an unusual signal, or extrapolate beyond its training range.

PACMAN places conflict resolution and hardware enforcement after the models and controllers. This location matters because every proposed action must cross the same boundary before reaching equipment.

The model does not need to understand every hardware limit. The output layer can reject or modify a request that violates an established constraint.

This division also protects safety controls during model replacement. Researchers can validate a new predictor without rebuilding the entire path that enforces actuator limits.

The principle applies beyond fusion, although PACMAN’s evidence does not. A liquid handler could have fixed volume and travel restrictions. A reactor could maintain independent temperature and pressure limits.

A robotic arm could preserve force, speed, and workspace boundaries. A microscopy platform could restrict stage travel or prevent unsafe contact between a probe and sample.

Those examples illustrate the architecture, not proven PACMAN deployments. The published demonstrations remain tied to DIII-D and its plasma control system.

Independent safety rules do not guarantee a safe laboratory either. Teams must choose the correct limits, test their implementation, and account for failures that occur outside the model.

A faulty sensor can make an acceptable command unsafe under the true physical conditions. A network delay can cause a command to arrive after its intended moment.

Two individually reasonable controllers can also conflict. One might request more heating to reach a performance target, while another reduces heating to avoid instability.

PACMAN’s output stage provides a place to arbitrate those demands. The researchers did not solve every possible conflict across autonomous laboratories, but they made arbitration an explicit system function.

That choice contrasts with architectures that treat model output as the command itself. Direct execution makes a laboratory depend on the model’s judgment and every upstream component feeding it.

Research on AI laboratory safety supports caution. A 2025 laboratory safety benchmark tested 19 language and vision-language models across hazard identification and realistic scenarios.

No evaluated model exceeded 70 percent accuracy on hazard identification. The benchmark included 765 multiple-choice questions and 404 scenarios containing 3,128 open-ended tasks.

That study did not evaluate PACMAN, which uses specialized machine-learning controllers rather than a general language model operating laboratory equipment. The comparison still exposes a broader reliability problem.

Model capability on structured questions does not establish safe performance in open physical environments. High scores in one format can also hide weak reasoning in less constrained situations.

A separate study of large language model agents for atomic force microscopy found that strong domain question-answering did not reliably translate into laboratory operation.

Researchers observed instruction deviations they described as “sleepwalking.” Multi-agent systems performed better than single agents, yet remained sensitive to prompt formatting changes.

Again, PACMAN is not a language-model agent. Its models perform bounded control and prediction tasks inside a purpose-built system.

The relevance lies in the design lesson. Teams should assume that an AI component can fail even when it has passed familiar evaluations.

Putting limits outside the model converts that assumption into architecture. It does not require developers to predict every way a model might produce an unsuitable output.

This is the article’s core reversal. More autonomous decision-making does not require more autonomous safety authority.

The faster and more adaptive the model becomes, the stronger the case for a simple enforcement layer it cannot override.

Fusion Control Is the Test Case, Not Universal Proof

Five successful experiments establish feasibility at DIII-D, but they do not establish portability across facilities or ordinary laboratory instruments.

PACMAN’s creators believe its modular design can support tokamaks with different shapes, sizes, and instrument sets. That claim remains a development goal rather than a demonstrated result.

Each fusion facility has its own diagnostics, timing constraints, actuators, operating regimes, and machine-protection systems. A common software pattern does not remove those differences.

Moving PACMAN to another tokamak would require teams to map local measurements into the framework. They would also need to validate every actuator interface and safety constraint.

The models themselves might require new training data. Plasma behavior observed at DIII-D will not necessarily transfer unchanged to another machine.

Even DIII-D results need careful interpretation. The framework supported five different experiments, which shows breadth across control tasks. It does not describe continuous operation across every expected machine condition.

Rare combinations of sensor errors, controller conflicts, and unfamiliar plasma states remain difficult to reproduce. Those combinations often determine whether a safety architecture is dependable.

The researchers also tested PACMAN on a research facility with expert operators and tightly planned experimental shots. Routine laboratories face different workflows and organizational pressures.

A production laboratory may run repeated procedures across shifts. It may combine instruments from several vendors, allow remote access, and depend on technicians with varying levels of automation expertise.

Those laboratories also handle maintenance states. Equipment can be recalibrated, temporarily bypassed, or operated with replacement components that change its safe envelope.

PACMAN offers no automatic answer for those situations. Its contribution is a structure within which teams can encode and enforce their answers.

The narrow evidence should prevent an inflated conclusion. PACMAN has not shown that a general AI agent can safely plan and execute arbitrary laboratory work.

It also has not eliminated the need for conventional emergency stops, guards, interlocks, or containment. Those protections must remain effective regardless of software requests.

The Lab Manager analysis appropriately treats PACMAN as a comparison point for broader automation rather than a universal instrument controller.

That framing is useful for enterprise buyers. The question is not whether they can install PACMAN beside a liquid handler or analytical instrument tomorrow.

The question is whether their chosen automation platform preserves the same separation of authority. Buyers should ask where model outputs become commands and what can still stop them.

They should also ask whether a new model can be validated independently. A system that requires complete recertification after every model update will slow experimentation.

The opposite extreme is equally risky. Swapping models without rechecking interfaces, timing, and failure behavior can undermine the protections modularity was intended to preserve.

For laboratory leaders, portability is therefore an engineering and governance claim. It must be demonstrated against each facility’s equipment, hazards, and operating procedures.

PACMAN has supplied evidence for the first environment. Other laboratories still need to produce their own.

AI Hardware Safety Limits Need More Than a Software Check

An independent output layer reduces risk only when its rules, inputs, and failure modes receive independent validation.

The phrase “hardware safety limits” sounds absolute, but the implementation remains a chain of software and physical components. Every link introduces assumptions.

A maximum heating command may be correctly encoded. Yet the rule still depends on accurate knowledge of the equipment state and a working actuator interface.

Safety limits can also interact. A command that stays below one threshold can create risk when combined with another command or sustained over time.

Teams need tests that cover those interactions, not only individual upper and lower bounds. They also need fault injection, which deliberately introduces failures to observe the system’s response.

Sensor validation deserves particular attention. PACMAN checks incoming values for errors before models consume them, but no validation method catches every incorrect reading.

A plausible but wrong signal can pass simple range checks. Redundant measurements, consistency tests, and physical models can improve detection.

Timing needs similar scrutiny. Real-time control depends on commands arriving within known deadlines. A delayed command may be valid for an earlier state but unsafe for the current one.

The system therefore needs defined behavior after missed deadlines. Possible responses include holding the last safe setting, moving to a safe state, or handing control to another system.

Conflict resolution must also be deterministic enough to test. If two controllers compete for one actuator, researchers should know which goal takes priority before the conflict occurs.

That priority structure is policy. It should not emerge accidentally from execution order, network timing, or model confidence scores.

Cybersecurity adds another boundary. A model that cannot override a limit still offers limited protection if an attacker can change the limit or bypass the output stage.

Permissions should distinguish model developers, equipment engineers, safety officers, and operators. Critical rule changes should create reviewable records.

Versioning is equally important. Each experiment should record the model version, controller configuration, safety-rule set, and equipment state used during execution.

This is where laboratory automation meets knowledge management. Teams need a durable connection between experimental intent, software configuration, observed data, and later analysis.

A searchable technical knowledge base can help engineers trace those relationships. It cannot replace formal control-system logs or safety validation.

Human oversight must also be specific. Saying that a person remains “in the loop” reveals little about that person’s actual authority or available response time.

PACMAN assigns humans meaningful control before and between experiments. Researchers set goals, establish parameters, review results, and tune later runs.

During the fastest control cycles, the architecture relies on preapproved constraints. That is closer to supervisory control than continuous human approval.

This arrangement creates a clear responsibility for laboratory management. People must decide which choices are safe to automate before an experiment begins.

They must also define conditions that suspend automation. Examples include missing sensor data, unexpected equipment states, repeated rejected commands, or communications failures.

The system’s ability to stop safely deserves as much testing as its ability to optimize performance. A controller that reaches targets efficiently but fails unpredictably remains unsuitable for physical deployment.

PACMAN’s published results demonstrate successful operation, not complete assurance. The project should be evaluated as evidence for an architectural pattern, not proof that the pattern cannot fail.

That distinction strengthens the result rather than diminishing it. Useful safety engineering begins with explicit limits and testable authority boundaries.

Three Signals Will Show Whether PACMAN Becomes Shared Infrastructure

The next phase depends on cross-facility deployment, longer operational evidence, and proof that modular upgrades preserve safety behavior.

The first signal is a deployment on another tokamak. PACMAN’s creators argue that its building-block design can travel beyond DIII-D, but another facility would test that claim directly.

A successful transfer would require more than running the software. The framework would need to connect with different diagnostics, actuators, and protection systems without losing its timing guarantees.

Such a demonstration would strengthen the argument that PACMAN is infrastructure for fusion research. Failure or extensive custom rebuilding would reveal how much of its flexibility depends on DIII-D.

The second signal is broader operational evidence at DIII-D. Five experiments cover several important tasks, yet reliability depends on repeated performance across changing conditions.

Future reporting should identify how often the framework runs, how many proposed commands its safety layer alters, and what failure modes appear during use.

Rejected-command data would be especially informative. It could show whether the output layer serves mainly as a precaution or regularly prevents unsuitable model actions.

Researchers should also report missed deadlines, bad input detections, controller conflicts, and transitions into safe states. Those details would make the safety claim measurable.

The third signal is the upgrade process. PACMAN’s strongest practical promise is that researchers can add models quickly without disturbing the rest of the system.

That promise will gain credibility if teams document independent validation for several model replacements. They should show that safety behavior remains stable after each change.

A clear upgrade protocol would matter beyond fusion. Laboratories need ways to adopt better models without reopening every certified or validated component.

Conversely, a model swap that changes timing, data formats, or actuator behavior can reveal hidden coupling. Such coupling would weaken the framework’s modularity claim.

Researchers should also clarify how the architecture handles models that pursue competing objectives. Coordinating heating, stability, density, and performance becomes harder as more controllers join the loop.

The earlier fusion AI research provides a useful benchmark. In 2024, a Princeton-led team predicted tearing instabilities up to 300 milliseconds ahead.

That work focused on predicting and avoiding a particular instability. PACMAN expands the story from one successful controller toward a shared environment for multiple controllers.

The distinction will matter if the platform continues to absorb new models. A collection of demonstrations becomes infrastructure only when teams can reuse its interfaces, rules, and validation methods.

Laboratory buyers should watch these signals before generalizing PACMAN’s results. They should also apply its core question to their own automation projects now.

Where does the AI’s recommendation become a physical command? Which component can reject that command, and who controls the limits used for rejection?

If those answers remain vague, adding a more capable model increases uncertainty. If the boundaries are explicit and testable, faster automation becomes easier to govern.

The PACMAN AI framework offers a credible design direction because it treats model intelligence and machine authority as separate properties. That separation deserves testing across more facilities, tasks, and failures.

For teams evaluating AI laboratory automation, the immediate action is straightforward: map every path from model output to physical movement. Then confirm that a reviewed, independent control layer can interrupt each path before the hardware acts.