How to Evaluate a Microreactor Vendor: The Verification Questions to Ask

Why evaluating an autonomous or remote design is different

Conventional plant diligence leans on things you can go and look at: an operating record, a staffed control room, inspectors on site. That surface is real. The NRC keeps roughly 150 resident inspectors in the field, at least two at every plant, whose stated role is independently verifying that requirements are being met ^[1], inside an oversight process built on inspection findings, performance indicators, and a significance determination process ^[2].

A microreactor designed for reduced on-site staffing removes much of that. Proposed Part 57 contemplates remote operation and reduced staffing ^[3], and NRC staff have separately proposed operational-phase oversight built on a scalable inspection footprint ^[4]. Fewer people on site, fewer inspector-hours per unit.

The consequence for a buyer is specific. More of what you can know about the reactor arrives as data the operating organization reports about itself. So diligence has to move upstream, from checking outcomes to checking who is positioned to confirm them. That is what the questions below are built to test.

None of these require you to be a nuclear engineer, and none require a vendor to disclose anything proprietary. They test the structure of a claim rather than the physics behind it.

Question one: what is your exact regulatory status today

This is the easiest claim to verify without the vendor's help, and the one most often softened. A developer in pre-application engagement has not been granted a license, a permit, or a design approval, and pre-application produces no safety finding ^[5]. That is public.

The vocabulary is close enough to blur deliberately or accidentally. A pre-applicant is engaging with the regulator before submitting. An applicant has submitted and is under review. A licensee holds a license. Phrases like "working with the NRC," "in the NRC process," or "NRC-engaged" can describe any of these, or the earliest.

Two follow-ups do real work. Ask which framework they are pursuing: Part 53 was finalized in March 2026 as a risk-informed, technology-inclusive framework and is available now ^[6], while the microreactor-specific Part 57 remains proposed with its comment period closed ^[3]. A developer betting entirely on a rule that is not final carries schedule risk a developer using an available pathway does not.

Then ask what they expect to submit next, and when. A credible answer names a document. A vague one names a quarter. The distinction between pre-application and approval is where most marketing language quietly lives.

Question two: which safety claims are demonstrated, and which are design targets

Every vendor will tell you their design is safe. The useful question is what "safe" is resting on: qualified analysis and test data, or intent that has not been through regulatory review yet.

A strong answer separates the two without prompting and volunteers what testing is still owed. A weak answer presents every safety characteristic as settled. The tell is whether a developer can name a weakness at all.

Context helps you calibrate. Real capability has been demonstrated at national-laboratory scale: DOE reported that INL demonstrated a digital twin of a simulated microreactor that predicted heat pipe temperatures and then autonomously controlled the heat pipe ^[7], and INL's MARVEL project exists to test remote monitoring and develop autonomous control technologies ^[8]. Those are genuine results.

They are also lab results, not commercial operating experience, and they belong to the laboratories rather than to any vendor. A developer citing national-lab demonstrations as though they were their own operating record is doing something you should notice.

Question three: who verifies reactor state, and are they separate from you

This is the question with the most signal and the one least often asked. If the reactor reports its own condition and the vendor evaluates that report, an outside party has nothing independent to rely on.

The precedent is not speculative. IAEA safeguards exist so that an outside body applies technical measures to independently verify rather than relying on an operator's assertion ^[9]. Computing standardized the same separation in RFC 9334, splitting the attester that produces evidence from the verifier that appraises it and the relying party that acts on the result ^[10].

Ask what happens to the result afterwards, because present-tense monitoring does not answer past-tense questions. Standards exist for this too: an append-only transparency service that registers signed statements and issues receipts a third party can audit later ^[11], with the receipts themselves standardized as compact cryptographic proofs ^[12].

A strong answer names a verification function separate from operations and describes what it records. A weak answer points at a monitoring dashboard. That is the whole of self-attestation versus independent verification, and it is worth pressing on because the two sound identical in a sales conversation.

Question four: which cybersecurity standards, and what is their status

Digital instrumentation and autonomous control change the threat model, and the honest state of the field is that requirements for advanced reactors are still being written. NRC guidance for digital I&C review of non-light-water reactors exists ^[13], and cyber requirements for advanced reactors remain consequence-based and in development rather than finalized ^[14].

International guidance is further along and worth asking about by name. The IAEA has published technical guidance on protecting reactor instrumentation and control systems across their full life cycle ^[15], and has an active research project on computer security for small modular and microreactors that names autonomous and remote operations, digital twins, and centralised fleet management with reduced staffing as the conditions to address ^[16].

The disqualifying answer here is specific: a vendor claiming to hold a completed NRC cybersecurity approval for an advanced reactor is describing something that does not yet exist in final form. That is not a nuance, it is a factual error, and it tells you how carefully the rest of their claims are made.

A strong answer names the standards they build toward, distinguishes final guidance from proposed rules, and explains how a third party could check the claim. Our fuller treatment is in microreactor cybersecurity, explained.

Question five: where does the fuel come from, and what does it do to the schedule

Fuel is the constraint buyers most often underweight, and it is a schedule risk rather than an engineering one. Most advanced designs need HALEU, and a commercial domestic supply chain at the scale the industry will need does not yet exist, which is why the Energy Act of 2020 directed DOE to establish the HALEU Availability Program ^[17].

This is not a vendor-specific failing. Almost nobody has solved fuel independently, so it is a poor basis for choosing between developers. What differentiates them is whether they account for it honestly.

A developer who names fuel as a schedule constraint and describes their supply path is giving you a deployment timeline. One whose plan treats fuel as settled is giving you an engineering timeline, which is a different and less useful thing when you are planning around a delivery date. The detail sits in where HALEU comes from.

Question six: what staffing and oversight does your model assume

This one is newer and rarely asked, but it determines what the other answers are worth over twenty years. Current regulation requires a licensed operator at the controls at all times ^[18]. A design premised on reduced staffing is premised on that requirement changing, or on an exemption being granted.

Oak Ridge examined what autonomous control disturbs and found it reaches well past headcount: staffing, manipulation of controls, licensed operator provisions, technical specifications, cybersecurity, and event notifications, with the control room potentially not co-located with the plant ^[19]. Sandia, working for the NRC, described designs where one control room supervises multiple microreactors ^[20].

So ask directly: how many operators per reactor does the business case assume, and what has to be true regulatorily for that to be permitted. Then ask the oversight version, because the GAO has reported that the NRC has not evaluated its efforts to address staffing gaps and lacks benchmarks for whether recruitment and retention are working ^[21], and still lists licensing advanced reactors among its priority open recommendations ^[22].

A developer whose economics depend on thin staffing and thin inspection, without a story for how anyone confirms the reactor between visits, has an unpriced risk in the model. That is the fleet-scale verification problem arriving through the commercial door.

What a checkable answer sounds like

The pattern across all six is simple. A strong answer points to a document, a standard, a regulator's public record, or a party with no stake in the outcome. A weak answer points back to the vendor.

Every stronger answer above can be checked after the meeting. Every weaker one cannot. That is the only property the table is really sorting on.

One practical note on running the conversation. Ask these questions of the technical lead rather than the commercial team, and ask them in the order above, because status constrains everything after it. A developer who is candid about being early will usually be candid about the rest. A developer who blurs status tends to blur the harder questions too, and you will have learned that in the first five minutes rather than the third meeting.

It is also worth asking one deliberately open question at the end: what would have to go wrong for your schedule to slip two years. The content of the answer matters less than whether they have one. Everyone in this industry is carrying fuel risk, licensing risk, and supply-chain risk simultaneously. A developer who cannot name their own largest risk either has not modelled it or does not want to discuss it, and both are things you want to know before signing.

Applying all six questions to RankShield Energy, honestly

A buyer's guide written by a vendor is worth very little unless the vendor runs the questions against itself, so here are our answers. Status: we are a pre-applicant, we hold no NRC license, permit, or design approval, and nothing about our design has been demonstrated to or accepted by the NRC ^[5]. Demonstrated versus target: our reactor safety characteristics are design intent, subject to analysis, testing, and regulatory review, and we have testing still owed before we would characterise them otherwise.

Verification: separation of the verifier from the operator is the core of our approach and the reason this site exists, and it is an architecture we apply rather than a deployed, certified capability. Cybersecurity: we build toward standards that are themselves still being finalised, so we claim no completed NRC cyber approval. Fuel: HALEU supply is a real schedule constraint for us as it is for the field ^[17]. Staffing: our model assumes reduced on-site staffing, which depends on regulatory change that has not happened yet ^[3].

If that reads as less confident than a sales page, that is deliberate. A vendor who cannot tell you where they are weak is not giving you information you can plan around. Apply these six questions to us and to everyone else, and weigh the answers the same way.