In May 2025 the U.S. Nuclear Regulatory Commission approved NuScale's 462-megawatt small modular reactor plant design, and later in the year cleared the company's VOYGR-4 and VOYGR-6 configurations. Those approvals matter for a reason that has little to do with megawatts. A certified standard design is the whole point of the SMR bet: build the same reactor module many times, in a factory, and amortize the engineering across a fleet instead of starting fresh on every site.
That ambition is exactly where model-based systems engineering starts to look less like a nice-to-have and more like a structural requirement. Nuclear has been a slow adopter of MBSE, partly out of justified conservatism. But the economics of small modular reactors put pressure on the document-heavy way the industry has always specified plants, and a wave of projects breaking ground in 2026 is forcing the question.
Why SMRs change the MBSE math
A traditional gigawatt-scale plant is a one-off. Each unit gets a bespoke design, a mountain of paper, and a licensing campaign tailored to that specific site. When you only build one, the cost of reconciling thousands of documents by hand is painful but tolerable. You absorb it once.
SMRs flip that logic. Holtec plans to submit construction permit applications in 2026 for two SMR-300 units at the Palisades site in Michigan, with commissioning targeted for the mid-2030s. Dow and X-energy both expect to start construction in 2026 on projects in Texas, with operations later in the decade. The promise underneath all of them is repetition: a reference design instantiated across many sites, with controlled variations for local conditions. The moment you commit to building the same thing repeatedly, the manual document-reconciliation approach stops scaling. A change to the reference design has to propagate cleanly to every site that inherited it, and you need to know, with confidence, which units are affected.
That is the problem MBSE was built for. A model holds requirements, interfaces, and architecture as connected data rather than prose scattered across PDFs. Change one element and the links tell you what else moves. For a fleet of near-identical reactors, that traceability is the difference between a manageable configuration program and a spreadsheet that nobody fully trusts.
What the model actually carries
It helps to be concrete about what gets modeled. In a nuclear context, the system model typically anchors a few things at once. It holds the requirements baseline, from top-level safety functions down to component-level specs. It captures the interfaces between disciplines that otherwise live in separate worlds: reactor physics, thermal-hydraulics, instrumentation and control, electrical, and the balance of plant. And it ties each requirement to the analysis or test that verifies it, so the verification status is a property of the model rather than a line in a separate matrix.
A recent study of MBSE adoption in the U.S. nuclear industry, published in Nuclear Engineering and Design, found the methodology being applied precisely to manage this complexity and cut the communication errors that creep in when teams hand documents back and forth. That is the unglamorous core of the value: fewer translation errors between disciplines, and a single place where the current state of the design actually lives.
The contrast with the old approach is stark enough to draw:
The right-hand column is not automatic. Plenty of SMR programs still run on documents. But the structure of the SMR business case keeps pushing toward the model, because reuse and configuration control are where the money is.
Tooling and the standards question
The tools in play here are mostly the same ones used across aerospace and defense, which is no accident: many SMR developers hire systems engineers out of those industries. Dassault's Cameo Systems Modeler (part of the CATIA Magic line) and Eclipse Capella both show up in nuclear modeling work, and newer SysML v2-native environments such as Dalus are entering the same space as teams weigh the move to the updated language. Each takes a different stance on methodology and notation, and the right choice depends as much on a team's existing skills and the rest of its toolchain as on any feature list.
The harder question is standards. Aerospace has ECSS and a long history of model-based practice to lean on. Nuclear has no equivalent MBSE standard with regulatory force, and the NRC's review process was built around documents, not models. So even teams that model everything internally still produce traditional licensing deliverables for the regulator. The model becomes the source of truth, and the documents become generated artifacts pulled from it. That works, but it means MBSE in nuclear is currently an internal engineering discipline rather than a regulatory interface. Closing that gap is a multi-year effort, and it depends on regulators getting comfortable consuming models directly.
What MBSE won't solve
A model is not a safety case. It organizes the evidence and keeps the traceability honest, but it does not produce the thermal-hydraulic analysis, the probabilistic risk assessment, or the qualification testing that a license actually rests on. Teams that expect the model to substitute for that work are setting themselves up for disappointment.
There are other limits worth naming plainly. Modeling has real upfront cost, and on a genuinely one-off design that cost may never pay back. The discipline only earns its keep when there's reuse, change propagation, or enough cross-discipline complexity that document reconciliation is already breaking down. The other trap is the disconnected model: a beautiful SysML artifact that drifts out of sync with the analyses and the as-built configuration because nobody funded the integration to keep it current. A model that lies is worse than no model, because people trust it. And none of this removes the regulatory friction. Until the NRC and its counterparts can review models as primary submissions, every MBSE program in nuclear carries the overhead of generating conventional documents on top of maintaining the model.
The bottom line
Nuclear is not adopting MBSE because models are fashionable. It's adopting them because the SMR thesis, build the same reactor many times and license a standard design once, only holds together if the design is managed as connected data instead of a paper archive. The 2025 NRC approvals and the 2026 construction starts move that thesis from slide decks toward concrete, and the configuration challenge that follows a fleet is squarely a systems engineering problem. The teams that treat the model as their working baseline, fund the integration to keep it honest, and stay clear-eyed about what it can't certify will get the most out of it. The ones expecting a model to do the safety engineering for them will learn an expensive lesson.