The QAPD Is Your First Topical Report. Here's How to Build It.

Intended audience:  Advanced reactor founders and engineering leads building their first Quality Assurance Program Description, and the investors evaluating whether that program is real.

Executive Summary

The Quality Assurance Program Description, the QAPD, is the only part of a developer's quality program that becomes public record, the part that lands on ADAMS. It's what gets docketed and reviewed, with the NRC issuing a Safety Evaluation Report in response once that review is complete. The NRC itself sees more than the public does: it audits the full Quality Assurance Plan directly, on site, not just the QAPD. But that's genuinely just the tip of the iceberg from an outside investor's or auditor's vantage point: underneath the QAPD sits a body of internal implementing procedures, controlled forms, and a formal training program that never gets filed with the NRC but absolutely gets audited against it. Founders consistently misunderstand two things: how much substance has to exist beneath that visible document, and that meeting every requirement on day one isn't the bar, building a program that grows toward full compliance is. This post walks through what a QAPD actually has to contain, what most startups get wrong, and why an early-stage program that can't do everything yet is not a program that should wait to start.

The QAPD Is the Tip of the Iceberg

A QAPD is the visible, docketed document, the one the NRC reviews and issues a Safety Evaluation Report against, and the one an outside investor or auditor can actually go read on ADAMS. The NRC's own review goes further, on-site audits cover the full Quality Assurance Plan, not just the QAPD. What the QAPD isn't, for anyone outside the agency, is the whole quality program. Underneath it sits the internal implementing procedures that actually control the activities and items affecting quality, calibrated to how important those activities are, plus a formal training program that indoctrinates and trains every person who performs or manages activities affecting quality. None of that lives in the QAPD itself. It lives in internal program documents the QAPD points to and commits the organization to maintaining.

This is the gap I see founders miss most often: treating the QAPD as the finish line, a document to write once and file, rather than the visible commitment on top of a much larger internal structure that has to actually exist and function.

The Regulatory Stack: 10 CFR 50 Appendix B, RG 1.28, and ASME NQA-1

10 CFR 50 Appendix B is the federal regulation, 18 quality criteria covering everything from organizational structure and design control to procurement, inspection, nonconforming materials, corrective action, and audits. It states what has to be done. It does not tell you how.

That's where ASME NQA-1 comes in. NQA-1 is the industry consensus standard that provides the detailed, practical methodology for actually meeting Appendix B's requirements, and Regulatory Guide 1.28, Revision 6 is where the NRC formally endorses specific parts of NQA-1 (Part I and Part II of the 2017, 2019, and 2022 editions) as an acceptable way to satisfy Appendix B during design and construction, with certain NRC clarifications and regulatory positions layered on top. The QAPD should be built as a standalone topical report, kept distinct from the Final Safety Analysis Report, which carries the technical safety case. Exactly where it lands within a Construction Permit Application or Combined License Application varies by applicant; I've seen it filed as its own numbered part of the submittal (for example, as Part 11, COL Application Enclosures, in some applications), and it can also be submitted as an enclosure to a separate topical report letter. Either way, it stays a distinct document from the FSAR. For a construction permit specifically, the QAPD needs to cover design, fabrication, construction, post-construction testing, and preoperational testing.

Two Requirements Founders Consistently Underestimate

Independence between doer and checker. This isn't just an ASME NQA-1 elaboration, it's written directly into the federal regulation. 10 CFR 50 Appendix B, Criterion III, Design Control, states that verifying or checking the adequacy of a design "shall be performed by individuals or groups other than those who performed the original design." Criterion X, Inspection, applies the same rule to inspection activities. NQA-1 provides the detailed methodology for implementing that independence, but the underlying requirement comes from Appendix B itself. This sounds easy until a small team tries to implement it: a five-person engineering team doesn't have much natural redundancy, and it's a real organizational design problem, not just a policy line, to make sure the same person never checks their own work. It's also worth being direct about something increasingly relevant: AI tools cannot take on either role. A human has to perform the work, and a different human has to independently verify it. That's not a preference, it's a structural requirement of the regulation itself.

Lead Auditor qualification is specific and non-trivial. Unlike the doer/checker independence rule above, this one doesn't originate in the federal regulation. Appendix B, Criterion XVIII simply requires "a comprehensive system of planned and periodic audits"; it doesn't specify auditor qualifications. The detailed bar comes entirely from NQA-1 Requirement 2, Section 303, which lays out exactly what it takes to qualify as a Lead Auditor: communication skills attested to in writing by the employer, participation in a minimum of five quality assurance audits within a period not exceeding three years prior to qualification, with at least one of those being a nuclear quality assurance audit within the year immediately prior, plus passing a comprehension examination on the body of knowledge. That's a real bar, and it's binding because RG 1.28 endorses NQA-1 as the accepted method of meeting Appendix B, not because Appendix B states it directly. A startup building its first QA program from scratch usually doesn't have someone who already clears it, and has a real choice to make: contract with an outside auditing firm in the near term, or invest in developing an internal Lead Auditor over time as the organization matures. Neither choice is wrong. What's wrong is not planning for it at all.

Revision Zero Is Allowed to Be Imperfect

Here's the mistake that actually costs developers the most time: waiting to start the QA program until the organization believes it can satisfy all of NQA-1 at once. That's backwards. Early-stage programs are expected to start at Revision 0, honest about where the organization's capabilities currently stand, and revise as the organization grows into fuller compliance, maintaining an internal Lead Auditor instead of relying permanently on an outside firm, for example, as one specific, common maturation step. The fact that a program can't do everything on day one is not a reason to delay starting it. It's the reason Revision 0 exists.

The Exploratory-to-Qualification Transition

One structural pattern worth building into a QA program from the start, especially for reactor designers and fuel-cycle or reprocessing developers doing genuine R&D: early feasibility work and basic research don't need to run under full NQA-1 rigor on day one. It's reasonable, and common, to treat early-stage exploratory work, orientation testing, feasibility studies, basic research, under a lighter or non-NQA-1 process, since the objective at that stage is learning, not qualifying a design.

The discipline comes in defining, clearly and in advance, when that exploratory work has to convert into something fully NQA-1-controlled. The moment R&D output is intended for actual use in an application of a nuclear facility, it has to formally transition, through either qualification testing or a documented peer review, into what a mature program would call "design validated." Programs that skip defining this transition point tend to either over-engineer early feasibility work unnecessarily, burning time and budget on rigor that isn't required yet, or under-control late-stage work that should have already converted, creating a gap an NRC reviewer will find.

This same discipline extends to software. NQA-1 Subpart 2.7 doesn't let a program simply trust a commercial analysis tool because it's an established, name-brand product (e.g., SCALE or RELAP5). Design and analysis software, finite element tools, CFD codes, even familiar commercial packages, have to be validated and qualified for the specific use a program is putting them to, with documented test cases and a process for evaluating how vendor-issued bug reports might affect past design work. It's a detail many early-stage programs don't budget time for until an auditor (or worse, an NRC reviewer!) asks about it directly.

Don't Starve the Internal Program in the Name of Moving Fast

This same principle applies to how a startup should think about scoping the work, not just how it thinks about compliance timing. I've had this exact conversation with more than one developer weighing a minimal program against a fuller one. The temptation is to go narrow: build only what's needed for the most immediate milestone, and treat the rest of the internal procedures and controlled forms as something to add later, once the team is bigger or the next raise has closed.

Here's what actually gets lost in a minimal program, concretely: establishing an Approved Suppliers List, any internal or external audit program, and test control, inspection, or calibration coverage for measuring and test equipment. It's fair to say a ten-person team isn't ready to fully use most of that yet. But not having it documented yet is different from not having it exist as a known gap. When a program skips defining these areas entirely rather than acknowledging them as not-yet-mature, the team doesn't just lack the procedure, they can lack the awareness that the procedure is needed at all. That's how "we'll build it later" quietly turns into "we didn't know we needed it."

I've seen this play out directly. A developer built some real infrastructure early, Design Control, Supplier Management, Document Control, genuinely solid implementing procedures. But without a documented program for NQA-1 Part I, Requirement 7, Control of Purchased Items and Services, nothing stopped their procurement team from buying safety-related items without anyone in the organization recognizing that those purchases needed their own NQA-1-compliant procedure and forms in the first place. The gap wasn't a missing checkbox. It was a blind spot that let real procurement activity happen outside the program's visibility entirely, and it's exactly the kind of thing that gets built retroactively, under pressure, and shaped around whatever the organization happened to already be doing rather than around the principles NQA-1 was actually designed to enforce. Procedures built that way, reverse-engineered from existing practice instead of built forward from the standard, tend to justify what already happened rather than actually control what happens next.

The full foundation, even an imperfect one with honest, documented exceptions, is what actually protects a design effort as it scales. A narrower one doesn't eliminate that work. It just defers it to a point where it's harder to see, harder to fix, and far more expensive to unwind.

What Small Teams Should Do Now

Start the QAPD as a standalone topical report now, even if it's Revision 0 and openly incomplete in places. Map out, honestly, which of the 18 Appendix B criteria your organization can already meet, which it can partially meet, and which require either an outside contractor or a hire you haven't made yet. Decide early whether your Lead Auditor function will be contracted or built internally, and if internal, start the clock on the five-audit, three-year qualification pathway now, not when you're already deep into pre-application engagement and need one.

Frequently Asked Questions

Q: What is a QAPD, and how is it different from a company's internal quality procedures?

A: The QAPD, Quality Assurance Program Description, is the document submitted to and reviewed by the NRC, and the only part of a developer's quality program that becomes part of the public record. The internal implementing procedures, controlled forms, and training program that actually carry out the QAPD's commitments are separate, internal documents that are not filed with the NRC but are subject to audit against it.

Q: What is the relationship between 10 CFR 50 Appendix B and ASME NQA-1?

A: Appendix B is the federal regulation, 18 quality criteria stating what a nuclear quality assurance program must accomplish. NQA-1 is the industry consensus standard providing the detailed methodology for how to meet those requirements. NRC Regulatory Guide 1.28, Revision 6 formally endorses specific parts of NQA-1 (2017, 2019, and 2022 editions) as an acceptable method for satisfying Appendix B.

Q: Can an AI tool perform the independent verification role required under NQA-1?

A: No. This requirement originates in 10 CFR 50 Appendix B itself, Criterion III requires that design verification be performed by individuals other than those who performed the original design, and NQA-1 provides the detailed methodology for implementing it. Both roles require human accountability; an AI tool cannot assume either the performing or the independent verification role under the regulation.

Q: What does it take to qualify as a Lead Auditor under NQA-1?

A: Per several editions of NQA-1 Requirement 2, Section 303: communication skills attested to in writing by the employer, participation in a minimum of five quality assurance audits within a period not exceeding three years prior to qualification, with at least one of those being a nuclear quality assurance audit within the year prior to qualification, and passing a comprehension examination.

Q: Does a startup's QA program need to fully satisfy NQA-1 before it can begin operating?

A: No. Early-stage programs commonly begin at Revision 0, reflecting the organization's actual current capabilities, and mature over time, for example moving from a contracted outside Lead Auditor to a qualified internal one as the organization grows. Waiting to start the program until full compliance is achievable is not required and generally not advisable.

Q: Should the QAPD be filed as part of the Safety Analysis Report, or separately?

A: Separately. The QAPD should be developed as a standalone topical report, distinct from the Final Safety Analysis Report, which covers the technical safety case. Exactly where it's positioned within a Construction Permit Application or Combined License Application varies by applicant, it has been filed as its own numbered part of the submittal (for example, as Part 11, COL Application Enclosures, in some 10 CFR 52 applications), and it can also be submitted as an enclosure to a separate topical report letter. For a 10 CFR 50 construction permit application, the QAPD needs to address design, fabrication, construction, post-construction testing, and preoperational testing.

Q: When does exploratory R&D work need to convert to full NQA-1 control?

A: The moment the results of exploratory or feasibility work are intended for actual use in a nuclear facility, they need to formally transition into full NQA-1 control, through either qualification testing or a documented peer review. Basic research and orientation testing can run under lighter or non-NQA-1 processes before that point, provided the transition trigger is clearly defined in advance.

Sarah Gibboney, P.E. is Founder & Principal Licensing Engineer of Gibboney Nuclear, PLLC, a nuclear licensing consultancy serving advanced reactor developers. She has 17 years of nuclear energy experience, including co-authoring Construction Permit Applications for both ARDP awardees, TerraPower Natrium and X-energy Xe-100.