How the NRC Pre-Application Process Actually Works

Pre-application is engagement, not approval

The plainest version is this: pre-application is a conversation. A developer tells the NRC what it intends to build and how it intends to license it, and the NRC uses that interaction to become familiar with the technology and the plan before any application is submitted ^[1]. Nothing in that conversation issues a license, a permit, a construction authorization, a design approval, or a safety finding.

The confusion is structural rather than accidental. The label "pre-applicant" reads like an early rung on an approval ladder, as though a regulator had looked at a design and advanced it one step. It is not a rung on that ladder. It is the stage before the ladder, and the NRC organizes it as general guidance on how to interact productively ahead of a submittal ^[3], not as a grading exercise.

Read the bottom row of that table carefully, because it is the honest case for the process. Pre-application has real value, and serious developers use it. The value is informational and procedural. It is not a credential. When a reader treats it as a credential, the error is expensive in a specific direction: money, land, offtake conversations, and community expectations all get committed against a status that carries no regulatory finding at all. That is why this post exists, and why we apply the same test to ourselves in the closing section. If you only remember one sentence, remember that the NRC becoming familiar with a design is not the NRC accepting it ^[1].

A pre-applicant is a developer in conversation, not one the NRC has cleared

A pre-applicant is a developer that has begun interacting with the NRC about a design or project it may later seek to license, but that has not necessarily submitted an application and certainly has not received one back approved. The NRC maintains public pages describing the advanced reactor developers it is working with in this posture ^[1]. Appearing there means the interaction exists. It says nothing about whether the design is sound, whether the schedule is credible, or whether the developer will ever file.

It helps to hold three distinct statuses in your head. A pre-applicant is talking to the regulator. An applicant has filed something the NRC has docketed and is reviewing, which puts the submittal into a formal review process with defined acceptance criteria ^[3]. A licensee has been granted a license and has become subject to ongoing regulatory oversight, which for operating power reactors runs through the Reactor Oversight Process and its inspections and performance indicators ^[13].

Those are not shades of the same thing. They are three different legal positions, and the distance between them is measured in years of technical review, not in press releases. A pre-applicant is two full transitions away from being an overseen operating plant. Anyone describing pre-application status as evidence that a reactor is "on track for approval" is compressing a gap that the regulator itself does not compress ^[1].

This also explains why the oversight regime you may have read about does not yet apply to any pre-applicant. The Reactor Oversight Process is a framework for plants that already hold licenses and are already operating ^[13]. It is a useful thing to understand early, because it tells you what real regulatory scrutiny of an operating plant looks like, and it makes the comparatively light weight of a pre-application conversation obvious by contrast.

The mechanics: intent, project number, engagement plan, meetings, topical reports

The process has recognizable machinery, and knowing the pieces makes vendor claims much easier to parse. A developer that wants to engage generally notifies the NRC in writing of its intent to interact, which allows the staff to set up a project and plan the resources the interaction will consume ^[3]. Assignment of a project number is an administrative act. It is a filing-cabinet label, and it is one of the most commonly over-read artifacts in this whole space.

The substantive document is the Regulatory Engagement Plan. The NRC asks developers to lay out what they intend to submit, in what order, and on what schedule, so the staff can anticipate workload and the developer can see the sequence of its own regulatory obligations ^[2]. This is the artifact that most rewards honesty, because a plan that promises a heavy stream of submittals a developer cannot actually produce becomes visible fast.

From our own side of that exercise, the useful part was not the document but what writing it forced. Sequencing planned submittals made it immediately obvious which technical questions we had actually closed and which we had merely deferred, because you cannot schedule a topical report on a subject you have not yet decided. That is an uncomfortable and genuinely valuable output, and it happens before anything is filed.

The interaction itself runs through pre-application meetings with the staff and, where a developer chooses, through topical reports and white papers that isolate a single technical or methodological question ahead of a full application ^[3]. Related guidance for microreactor developers specifically is collected on the NRC pages tracking microreactor regulatory activities ^[7]. None of these steps produces an approval of a design. A topical report review can produce a staff conclusion on the narrow question the report addresses, which is a real and useful thing, and it is still not a license.

Developers engage early because late regulatory surprises force redesign

If pre-application grants nothing, why bother? Because the alternative is discovering a regulatory expectation after the design is frozen. The NRC frames pre-application interaction as a way to identify and resolve issues before an application is submitted ^[3], and the practical translation is that a question raised in year one is a design input, while the same question raised in year four is a costly redesign.

The staff has also been thinking about the deployment problem beyond a single unit. SECY-25-0052 examines licensing and deployment considerations for microreactors on an nth-of-a-kind basis, which is the question of what happens when the same design is built repeatedly rather than treated as a bespoke project each time ^[12]. A developer that understands where the staff is heading on standardization can design toward it instead of against it, and pre-application is where that alignment is cheapest to achieve.

There is also a resourcing reality. NRC review work is generally subject to fee recovery, and the agency publishes how its fee structure applies to advanced reactor activities ^[9]. Congress addressed the efficiency of advanced reactor licensing directly through the ADVANCE Act, which the NRC summarizes on its own governing-laws pages ^[8]. The point for a reader is not the dollar figures. It is that regulatory engagement consumes real agency effort and real developer effort, which is precisely why a developer with nothing to submit tends not to engage for long.

Our position, stated so it can be argued with: the honest reason to engage early is to have your assumptions contradicted while contradiction is still affordable. Developers who treat pre-application as a marketing milestone get the opposite value, because they optimize for the announcement rather than for the correction. The process rewards the developer who arrives with specific unresolved questions and is willing to hear an unwelcome answer.

Which framework applies: Part 53 is final, Part 57 is proposed and not final

A developer engaging today faces a genuine framework question, and the two options are at very different stages of maturity. The NRC published its risk-informed, technology-inclusive regulatory framework for advanced reactors, 10 CFR Part 53, as a final rule in the Federal Register on March 30, 2026 ^[4]. That is a completed rulemaking and a real licensing pathway.

Separately, the NRC published proposed licensing requirements for microreactors and other reactors with comparable risk profiles, designated 10 CFR Part 57, in the Federal Register on May 1, 2026 at 91 FR 23628 ^[5]. Part 57 is proposed. It is not a final rule, no developer is licensed under it, and its content may change before any final version exists, if a final version exists. Anyone describing a design as compliant with Part 57 is describing compliance with a proposal.

The supporting guidance carries the same caveat. The NRC issued NUREG-2271, guidelines for preparing and reviewing applications under 10 CFR Part 57, in April 2026 as a draft for comment ^[6]. Draft guidance attached to a proposed rule is doubly provisional, and it is worth reading precisely because it shows the direction of staff thinking, not because it settles anything. The NRC also maintains a running summary of microreactor regulatory activities that ties these threads together ^[7].

The practical consequence for a developer is that engagement has to be framework-aware without being framework-dependent. A design premised entirely on a proposed rule surviving unchanged is carrying a risk that belongs on the risk register rather than in the marketing. For readers trying to understand what the proposed microreactor rule actually contemplates around staffing and remote operation, we walk through it separately in our explainer on Part 57 as proposed, including the qualifiers that get dropped when the topic is summarized elsewhere.

How to check a developer's claimed status against the public record

You do not have to take a developer at its word, including us. The NRC publishes pages describing the advanced reactor developers it is engaged with in pre-application, which is the natural starting point for confirming that an interaction exists at all ^[1]. The microreactor regulatory activities pages give the adjacent picture for this class of design ^[7].

Then apply four questions to whatever the developer has claimed. One: is the claim about engagement, or about a regulatory action? Engagement means a conversation exists. A regulatory action means the NRC issued something. Two: if a framework is named, is that framework final? Part 53 is a final rule ^[4]; Part 57 is a proposal ^[5], and a claim keyed to Part 57 inherits every uncertainty of a rule that is not finished.

Three: is any document identified specifically enough to look up? A named topical report on a stated subject is checkable. "Ongoing NRC engagement" is not. Four: does the developer distinguish between a staff conclusion on a narrow question and an approval of a design? That distinction is where most overstatement lives, because a narrow favorable conclusion is genuinely good news and is genuinely not a license.

A point on visibility that cuts in the developer's favor, and that we had originally been too cautious to state. The NRC's own description of the pre-application process includes a kickoff public meeting, held so a developer can introduce its project to NRC staff and to the public, and a later public outreach meeting near the vicinity of a proposed site as a submission date approaches ^[3]. So early engagement is not a private correspondence between a company and its regulator. Parts of it are conducted in the open, which is one more reason a developer's characterization of its own status is checkable rather than something you have to accept.

What the GAO has said about NRC readiness for advanced reactor licensing

The regulator side of this deserves the same scrutiny as the developer side. In July 2023 the Government Accountability Office published a report whose title states its conclusion directly: the NRC needs to take additional actions to prepare to license advanced reactors ^[10]. The concerns in that body of work center on workforce and readiness questions, meaning whether the agency has the staff, skills, and processes lined up for a wave of technologies unlike the light-water fleet it has regulated for decades.

That thread did not close in 2023. GAO maintains priority open recommendation letters for federal agencies, and it issued one for the NRC in June 2026 ^[11]. The existence of an open priority recommendation letter is itself informative: it tells you an external auditor still considers some recommendations unimplemented. Congress moved on the same problem legislatively through the ADVANCE Act, which the NRC describes on its own pages as directing improvements to the efficiency of its licensing work ^[8].

The counterargument, stated fairly: if the regulator has documented readiness gaps, then pre-application engagement is a formality that mostly generates paperwork, and a developer would be better served building and letting the licensing catch up later. That argument is not stupid, and versions of it are common in the industry.

Our response: it points in the opposite direction from the one intended. When agency review capacity is a constrained resource, arriving with unresolved fundamental questions is the most expensive possible way to consume it. Early engagement is how a developer reduces the amount of review capacity its application will need, and how the staff sees the technology before it is under schedule pressure. The readiness gaps GAO describes ^[10][11] make disciplined pre-application more valuable rather than less, and they also argue for humility about timelines from every developer, including this one.

Where RankShield Energy actually is, stated without softening

RankShield Energy is a pre-applicant. We hold no license, no construction permit, no design approval, and no design certification. Nothing about our design has been demonstrated to or accepted by the NRC, and no safety, performance, or operational characteristic described anywhere on this site has been reviewed or endorsed by the agency. Everything in the preceding sections about what pre-application does not grant ^[1] applies to us without exception.

We also are not licensed under the proposed microreactor rule, because nobody is. Part 57 is a proposal in the Federal Register ^[5], and any statement that our design aligns with it is a statement about design intent measured against a document that could change. We would rather write that sentence ourselves than let a reader infer something warmer.

A concrete decision and its tradeoff, since this article has been asking developers to make theirs visible. We decided that every public page would state the pre-applicant limitation in plain language rather than in a footnote. The cost is real: next to a competitor describing the same regulatory position in more flattering terms, we look less advanced than we are, and that has a commercial price in early conversations. We accepted it because a public claim that contradicts a future application is a durable liability, and because a company whose entire technical thesis is verifiable claims cannot start by making unverifiable ones.

The honest limitation, since we have been demanding that others state theirs: our claim about our own regulatory status is, at this moment, mostly a self-report. The public record establishes what the NRC publishes about engagement ^[1], and it does not establish the internal detail of our program. Treat our claims with the same skepticism this article recommends everywhere else. If you want the technical side of that argument, it runs through how you would verify an autonomous microreactor, and the vocabulary problem underneath it is unpacked in automation, remote, and autonomous as separate terms.