Automation, Remote Operation, and Autonomy: What the Terms Actually Mean

The three terms describe three different things

Start with plain definitions, because everything downstream depends on them. Automation is a machine performing a defined function: a condition is met, and logic fixed in advance executes a response. Remote operation is command and control exercised from outside the site boundary, by a qualified person who is not physically at the plant. Autonomous operation is a system acting across a range of conditions without an operator directing each action. Those are three separate properties, and a facility can have any one of them without the other two.

The confusion is not random. It runs in one direction, from the weaker claim toward the stronger one. Automation sounds like autonomy, autonomy sounds like nobody is on site, and nobody on site sounds like a settled fact. Each step in that chain is a separate claim requiring separate evidence, and collapsing them lets a speaker inherit the conclusion without doing any of the work.

Note what the table does not contain: a row where the accountable human disappears. Automation reallocates a task. Remote operation relocates a person. Autonomy changes how instructions are issued. None of the three, on its own, removes the requirement that a qualified person is answerable for safety-significant actions, and the human factors literature names offsite monitoring and remote operation as distinct research subjects for exactly that reason ^[3].

The words matter because they carry regulatory weight

The reason to be strict here is not linguistic hygiene. Each term maps to a different set of regulatory questions, and answering the wrong set is how a program discovers late that it assembled evidence nobody asked for.

Automation raises questions about whether the logic does what it is specified to do and how functions are allocated between machine and operator. Remote operation raises questions about the control room itself: where it is, whether it is co-located with the plant, and what happens when the link degrades. Oak Ridge found that autonomous control reaches past staffing into manipulation of controls, licensed operator provisions, technical specifications, cybersecurity, and notifications, with the control room possibly not co-located with the plant ^[4]. Brookhaven, working for the NRC, framed the safety question for facilities without main control rooms as verifying that important human actions can be accurately and reliably performed ^[8].

The evidence burdens differ in the same pattern. For automation, the burden sits largely inside the plant, where an operator can observe the function and an inspector can examine it in place. For remote operation, part of that burden moves onto a network, because the live questions become whether the command that was sent is the command that executed and whether the reported state is the real state, which is the problem we take apart in trusting a remotely operated reactor. For autonomy the burden shifts again, toward records that a party other than the operator can check, which is the whole distance between self-attestation and independent verification.

The obvious objection is that this is pedantry, and that everyone in the room knows roughly what is meant. Sometimes that is true. But precision matters when the words carry regulatory weight, and these words do. A claim of remote operation invites questions about staffing rules and control room location that a claim of automation does not raise at all. And if a developer uses the strong word in a sales deck and the careful word in a regulatory submission, that is not an inconsistency of style. It is a gap between two audiences, and the docket is permanent.

Automation is a machine performing a defined function, and it is not new

Automation is the least remarkable of the three words, which is precisely why it gets dressed up. A defined function executes when a defined condition is met, following logic fixed in advance by people who anticipated the condition. Reactors have run on that principle for decades. Protective functions, interlocks, and control loops are automation, and they were automation long before the word started appearing on slides.

Treating automation as a new capability inverts the actual design question. Sandia National Laboratories, examining human factors considerations for automating microreactors on behalf of the NRC, frames the work as how functions are allocated between people and machines rather than whether machines act at all ^[7]. Allocation is a design decision with consequences for workload, situational awareness, and what the operator is expected to notice. It is not a switch that gets flipped to on.

What automation is not is a staffing claim. Adding automation does not, by itself, change how many licensed operators a facility needs or where they are required to be. That is set by the license and by the rules, and under the current framework a licensed operator is required at the controls at all times ^[2]. A vendor can automate a great deal and still be subject to exactly the staffing requirements that applied before.

So when someone says the reactor is highly automated, the accurate reading is that it does what reactor instrumentation and control has done for a long time, hopefully well. That is a genuine engineering achievement and this is not a criticism of it. It is simply not a claim about autonomy, and it should not be permitted to become one in the following sentence. A useful probe: ask what the machine does when a condition arises that was not anticipated in the fixed logic. Automation has a clean answer. It does what it was told, or it trips.

Remote operation is command and control from outside the site boundary

Remote operation means the person exercising command and control is outside the site boundary. The boundary is the entire content of the word. Everything else about that person, the qualification, the accountability, the expectation that a human remains in the loop for safety-significant actions, is intended to survive the move rather than be dissolved by it.

The concept is not speculative. Oak Ridge has published on remote control of reactors as an active research direction ^[6], and in July 2026 Idaho National Laboratory reported that researchers achieved remote, autonomous power control of a research reactor in real time ^[9]. Read that carefully before repeating it. A research reactor, inside a research program. It shows the capability is technically reachable. It does not establish that a commercial power reactor may be operated that way, and the two should never be quoted as if they were the same result.

Because the current framework requires a licensed operator at the controls at all times ^[2], remote operation of a commercial plant is not something a developer can simply elect to do. Proposed Part 57 contemplates remote operation and reduced on-site staffing ^[1], which is why the proposal draws so much attention, and it remains proposed rather than final.

The verification consequence arrives immediately. When the operator is on site, a large amount of confirmation happens through presence: things are seen, heard, and walked past. When the operator is a network away, that confirmation has to travel as data, and data can be stale, mistaken, or altered without anyone in the loop noticing that it has been. Establishing that both the command and the reported state are genuine is a distinct engineering problem from operating the reactor, and it is the one taken apart in our piece on command and state in a remotely operated reactor.

Monitoring is not remote operation, and the difference is whether anyone can act

Monitoring is collecting and observing plant data. Remote operation is issuing commands that change what the plant does. The difference is whether anyone at that console has the authority and the means to act, and it is the single most useful distinction in this entire vocabulary.

The research community keeps them apart deliberately. The NRC and Idaho National Laboratory characterized the human factors of offsite monitoring and remote operation as two named topics inside one study, rather than as one topic with two labels for it ^[3]. That separation is not editorial fussiness. Observing a plant and commanding a plant place different demands on the person, the interface, and the network between them.

This is also where promotional language does its quietest work. A company describes a remote monitoring center, shows a wall of live plant data, and lets the audience conclude that the plant is being run from that room. Both descriptions can be simultaneously true of different systems, but they are different capabilities with different regulatory footprints, and one of them touches the controls while the other does not. The question to ask is blunt and it has a one-word answer. From that console, can anyone change reactor power?

The distinction gets sharper at fleet scale. Sandia, working for the NRC, described designs in which one control room supervises multiple microreactors ^[7]. Watching many units from one room is an operations and staffing design. Commanding many units from one room is a different proposition with different failure modes and a different evidence burden, which is why fleet-scale verification is a harder problem than the single-unit case rather than the same problem repeated.

Autonomous operation means acting across conditions without an operator directing each action

Autonomous operation means a system acts across a range of conditions without an operator directing each action. The load-bearing phrase is the range of conditions. Automation handles the conditions its designers enumerated in advance. Autonomy is a claim about behavior in conditions that were not individually enumerated, which is exactly why it is the harder thing to license and the harder thing to evidence.

Oak Ridge set out concepts for autonomous operation of microreactors and named the preconditions plainly, including sensor and instrumentation technologies capable of long-term unattended operation and complete system state awareness ^[5]. Neither of those is a small ask, and neither is satisfied by better software alone. The same laboratory mapped the licensing side separately, finding that autonomous control touches manipulation of controls, licensed operator provisions, technical specifications, cybersecurity, and notifications ^[4].

Capability in research settings is real and worth stating accurately. Idaho National Laboratory reported remote, autonomous power control of a research reactor in real time ^[9], and the Department of Energy reported that INL demonstrated a digital twin of a simulated microreactor that predicted heat pipe temperatures and then autonomously controlled the heat pipe ^[10]. Note the word simulated in the second one. Both are meaningful results. Neither is a licensed commercial reactor operating without an operator, and neither should be cited as though it were.

Autonomy is also not binary, which is why the yes-or-no question is the wrong one. There is a spectrum running from supervisory control, where a person approves what the system proposes, through to systems that select their own responses within a bounded envelope. The better question is which specific decisions the system makes on its own, and what evidence exists that it made them correctly. When no operator is directing each action, the record of what the system did becomes the primary account of what happened, so the record has to be checkable by someone other than the party that produced it. That is the argument developed in how to verify an autonomous microreactor.

Proposed Part 57 treats these separately, and it is proposed, not final

On May 1, 2026 the NRC published proposed 10 CFR Part 57, a licensing framework for microreactors and other reactors with comparable risk profiles ^[1]. Three qualifiers travel with every mention of it. It is proposed, not final. The comment period closed in June 2026. And no developer is licensed under it, because it is not yet a rule. Anyone describing Part 57 as the framework they operate under today is describing a document, not a permission.

The proposal sits on top of earlier staff work rather than appearing from nowhere. NRC staff set out policy and licensing considerations related to micro-reactors in SECY-20-0093 ^[12], and the agency maintains a public page tracking its microreactor regulatory activities ^[11]. The direction of travel is visible in that record. The destination is not fixed, and the difference between those two statements is where most overclaiming happens.

What has not changed is the current requirement. 10 CFR 50.54(m) requires a licensed operator at the controls at all times ^[2]. Human involvement in safety-significant actions is the operating baseline rather than an optional design choice, and no facility is licensed to operate unattended. Proposed Part 57 is worth reading closely, and we walk through it in Part 57 and autonomous operation, but reading a proposal is not the same as being governed by one.

Which brings us to the word that should be retired. Unmanned is not a regulatory category. It appears in no framework as a status a facility can hold, it maps to no defined set of requirements, and there is no application a developer can file to become it. When it turns up in a deck it is doing promotional work by borrowing the shape of a regulatory term without the substance of one. The same applies to fully autonomous, a phrase that sounds like a specification and functions as a mood. Both describe an end state that no operating framework currently recognizes, so both cost precision and buy nothing.

How to test a vendor's usage of these words in one meeting

Four questions will tell you, inside a single meeting, whether a developer is using this vocabulary carefully or decoratively. Ask them in order, because each one narrows what the next answer can be.

One. From your remote center, can anyone change reactor power, or only observe it? This separates monitoring from remote operation and it has a one-word answer, so hesitation is itself informative. Two. Which specific decisions does the system make without an operator directing them? Vagueness here is the clearest tell in the whole exchange. Three. Under what rule do you expect to operate that way, and what is that rule's status today? A careful answer names proposed Part 57 and volunteers, unprompted, that it is not final ^[1]. Four. Who other than you can check that the reactor did what you say it did? That question separates a story from an architecture.

An honest limitation applies to everything above. The definitions in this article are working definitions, assembled from national laboratory research and a proposed rule, not codified regulatory definitions lifted from a final framework. Reasonable engineers place the boundary between automation and autonomy in different spots, and if Part 57 issues in changed form some of this vocabulary will shift with it. Treat this as a usable framework for reading claims, not as settled terminology to quote back at a regulator.

Our own usage belongs under the same test. RankShield Energy is a pre-applicant engaged in early interaction with the NRC, holding no license, permit, or design approval, and nothing about our design has been demonstrated to or accepted by the agency ^[13]. We do not describe our work as unmanned or as fully autonomous, and we treat both descriptions as inaccurate rather than as aspirational shorthand. What we build is the assurance layer: evidence about what a reactor did that a party other than the operator can check. If you want these questions turned on developers generally, including on us, they are collected in our guide to evaluating a microreactor vendor.