No single definition has distributed more disarray. This is the story of why it happened…
Every 50.59-trained engineer faces the great challenge of distinguishing between general design requirements and design basis requirements, between design functions and design basis functions.
“Functions credited in licensee safety analyses or to meet NRC requirements are 10 CFR 50.2 design bases functions. Individual SSC functions are, in general, subsidiary to 10 CFR 50.2 design bases functions,” as we learn in Appendix B to NEI 97-04.
The engineer must assess whether a proposed design change adversely affects a design function of an SSC. Many design functions are described in the UFSAR. But not all design functions of all described equipment are considered “design functions.”
Perhaps it would be comforting to know that the NRC officially admitted multiple times that the definition of “design bases” as codified in 10 CFR 50.2 has caused much confusion over the last 50+ years.
So let’s start there:
“There has been much confusion regarding terminology, in particular, what is meant by design bases.”
So admitted the NRC in 1991 in NUREG-1397.
You see, in or around the mid-1980s, the NRC began conducting engineering inspections. What it discovered was confusion over terminology and an apparent loss of design control and design bases document retrievability. It began a discussion about, and issued many documents encouraging the need for the US fleet to initiate design basis document reconstitution programs. The NRC partnered with the industry to undertake this significant effort voluntarily so that it wouldn’t need to issue a new rule forcing it.
But a consistent theme that surfaced in this years-long discussion was this: confusion about the meaning of “design bases.”
It became obvious that the NRC had in mind an interpretation that differed from the official definition. But the plants seemed to document exactly what the rule required of them, which was inadequate for the NRC’s needs. The NRC admitted as such, as we shall see.
I’m going to trace this confusion back to its origin: a set of specific editorial changes made between 1966 and 1968 that nobody seems to have documented in one place until now.
The problems began in 1966 when the initial definition was proposed.
Not because the definition was inadequate. But because the final form that was approved in 1968 changed it. And many, perhaps most, of the consequences that would surface 20 years later can be traced to those changes.
I’m going to take you through the original 1966 definition and what it accomplished. Then I’m going to walk you through critical changes made to the final 1968 definition to show you what we lost.
I’ll then summarize the consequences and estimated cost of those consequences.
Finally, I’m going to point to a source document that remains as relevant and clear today as it was over 50 years ago and show that every effort since then was an attempt to return to that original specification document.
THE ORIGINAL PROPOSED DEFINITION
First, let’s examine the definition given in the proposed rule of 1966:
“Design bases” means information which identifies the specific function of a major component or systems of a facility in terms of performance objectives, and the specific values or range of values chosen for controlling parameters as reference bounds or limits for design.
Despite cramming 42 words into one sentence, it provides technical clarity. “Design bases” are defined, essentially, as performance specification statements. Performance is an attribute of function, and by establishing functions “in terms of performance objectives,” the result is a performance specification.
Another feature of the definition is that it limited the scope with just one word: “major.”
It was concerned with “major” components and systems, qualifying them by their importance to safety by requiring values associated not only with just their reference bounds, but their “limits” for design.
Limits denote boundaries. More importantly, they signify boundary violations, negative sanctions that occur for crossing that boundary. Consequences for failure.
So the original definition required documenting the performance specifications of major, safety-significant systems and equipment that were involved in preventing and mitigating the release of radioactivity.
Quantified performance requirements are concrete. They can be tested and shown to either meet, exceed, or fail their acceptance criteria. The 1966 rules also introduced the concept of the Safety Analysis Report (SAR) in support of revised sections on the Technical Specifications (50.36). The tech specs were concerned in part with demonstrating safety limits were in place to protect safety margins.
The AEC introduced the preliminary safety analysis report (PSAR) requiring that it:
- Describe the facility;
- Explain the bases for its design and the limits on its operation;
- Include the principal design criteria (PDC) for the facility;
- Include the design bases and the relation of the design bases to the PDC; and
- Include a preliminary safety analysis and evaluation of the facility.
The tech specs were required to be derived from the analyses and evaluations included in the SAR. In the 1966 summary of its rationale, the AEC stated in part that “Safety limits would be established at a level significantly above the normal operating range, but low enough to assure that the barriers are adequately protected.” This ties directly to the reason for including “reference bounds or limits” for design in the 50.2 definition: to bound both the operational zone and define the upper bound on safety limits.
An analogous modern process is running a short circuit model for a proposed electrical system design in analysis software like SKM or ETAP to determine the available short circuit current at each piece of equipment. You then take those results and write equipment specifications. For example, your short circuit analysis may indicate a particular bus needs to withstand a maximum of 37 kA of fault current, so you write a specification requiring that the switchgear be rated to withstand not less than 42 kA to provide “safety” margin.
One note: “principal design criteria” are used throughout 10 CFR 50, but it’s conspicuously missing in the list of formal definitions. We’ll return to that below.
THE FINAL AND CURRENT DEFINITION
This is where the problems arise that bred decades of confusion.
Let’s examine the final rule approved in 1968:
Design bases means that information which identifies the specific functions to be performed by a structure, system, or component of a facility, and the specific values or ranges of values chosen for controlling parameters as reference bounds for design. These values may be (1) restraints derived from generally accepted “state of the art” practices for achieving functional goals, or (2) requirements derived from analysis (based on calculation and/or experiments) of the effects of a postulated accident for which a structure, system, or component must meet its functional goals.
Here’s a “tracked changes” version showing the edits for easier consumption (text added in the 1968 version is colored red):
Design bases means that information which identifies the specific functions of a major component or system to be performed by a structure, system, or component of a facility in terms of performance objectives, and the specific values or ranges of values chosen for controlling parameters as reference bounds or limits for design. These values may be (1) restraints derived from generally accepted “state of the art” practices for achieving functional goals, or (2) requirements derived from analysis (based on calculation and/or experiments) of the effects of a postulated accident for which a structure, system, or component must meet its functional goals.
At best, the final definition moved “design bases” from performance specifications to something like a functional specification: function without performance attributes. But the reality is something even less.
ANALYZING THE FIRST TWO CHANGES
The first two consequential changes that created problems is this: deleting “in terms of a performance objective” and removing “major.”
The preliminary 1966 version forces measurement. It requires the rigor of an engineering specification.
The final 1968 version permits description.
And because it also deleted “major” and replaced it with the generalized SSC triad, it drastically expanded the scope.
Instead of narrowing the focus of design bases information to SSCs important to safety and preventing uncontrolled release of radioactivity, the 1968 definition broadened the scope to any SSC that had a function, regardless of what it was.
In those two years, for some reason, the hard engineering requirement was watered down into a drafting guideline.
And reams of description is what the industry got. In a draft description that was removed from the final version of Regulatory Guide 1.186, the NRC stated this frankly:
“Although the scope of information has evolved, the staff did not intend to include the functions of every structure, system, or component within the scope of design bases functions. As stated earlier, there has been considerable discussion within the industry and within the staff about what constitutes design bases information.”
If you ask an engineer to state the design basis function of the emergency core cooling system (ECCS) according to the 1966 version, you would get something like this:
“The function of the ECCS in terms of performance objectives is to limit peak cladding temperature to ≤ 2200°F following a loss-of-coolant accident.”
This is a performance specification. It has a function, a measurable outcome, and a limit (see below). You can test it. You can ask whether the as-built system achieves it. You can ask whether a proposed change affects it.
Now ask for a definition according to the 1968 version. You would get something like this:
“The function to be performed by the ECCS is to provide emergency core cooling following a loss-of-coolant accident.”
That satisfies the actual definition that was codified in 10 CFR 50.2. It names an action. But it’s not testable as stated. “Cooling” lacks quantification. There’s no limit. It lacks specificity.
Because the 1968 definition doesn’t require performance objectives, and because it broadened the scope to any SSC that has a function, the industry stuffed design bases information with functional descriptions rather than quantitative criteria.
“The containment shall maintain its integrity” satisfies the definition.
“The containment shall maintain its integrity such that the calculated offsite dose following a design basis LOCA does not exceed 10 CFR 100 limits” also satisfies it, but nothing in the definition requires the second form over the first.
An editor changed the language to move the venue from the engineer’s desk to a courtroom. The grammatical shift moved from requiring engineering specificity to something like promoting legal risk aversion. It is harder to prove someone violated a vague obligation than one nailed down in terms of an engineering specification.
ANALYZING THE THIRD CHANGE
The third change of consequence involved the deletion of just two words from the final definition: “or limits.”
And the ramifications are still being felt today.
“Bounds” is a neutral mathematical concept. It defines a range in which operation occurs. It doesn’t explain what happens if that range is crossed.
“Limits,” on the other hand, carries consequences. It possesses real gravity. The limit is the point beyond which performance degrades, integrity is compromised, a response is triggered. It imposes a design obligation.
The original definition, therefore, was describing both the operational range and the safety limits. The original definition preserved the distinction because context matters. A low flow might cause a pump to cavitate. A high temperature might cause fuel cladding to fail.
“Limits” was doing the same thing that “in terms of performance objectives” was doing: anchoring the function to quantitative, measurable criteria. It created a commitment that drove the safety analysis that defined the tech specs. Deleting the word deletes the commitment.
The three changes combined moved the definition from one that required engineering specificity to one that permits administrative generality. A reference bound tells you where the boundary is. A limit tells you what happens when you cross it. The 1968 final rule kept the boundary and removed the consequence.
The result was decades of debate over what “outside the design bases” means.
ANALYZING THE FOURTH CHANGE
The fourth and final problem was the second sentence the 1968 final rule added to the definition. It added genuinely helpful information designed to answer this question: From where do controlling parameter values come?
This is meaningful for evaluating the safety impact of a design change. “State of the art practices” can involve designing SSCs to codes and industry standards. On the other hand, some values may be derived from accident analyses.
And if those are impacted, then that’s a flag that a design change needs to be heavily scrutinized against the plant’s licensing basis to ensure its safety functions aren’t compromised.
Despite that added clarity, it stumbled right out of the gate with its permissive legal drafting: “These values may be 1 or 2.”
The editors didn’t say “These values are 1 or 2.”
They didn’t say “These values must be 1 or 2″ or “These values shall be 1 or 2.”
They’re illustrations that essentially say “Here are two examples, but the list is not exhaustive. You can derive parameter values this way, but other methods aren’t prohibited.”
“May be” is permissive language in a place that required mandatory language. The 1968 editors added two clauses of genuine clarifying technical content and then prefaced them with the one word that ensured the industry would never be required to use them. The result is permission to trace parameter values to accident analysis without the obligation to.
This was clearly against the stated intent provided in 1966, but it survived as a permissive anyway.
The 1968 Federal Register is silent on why. The preamble to the final rule enumerates the changes made from the proposed rule: the §50.34 PSAR requirements, the §50.36 LCO structure, the §50.59 ACRS referral process, even the deletion of Appendix A, each with stated rationale. The design bases definition receives two clauses: ‘Several changes have been incorporated in the amendments as adopted as a result of comments and further Commission consideration. In § 50.2, the definition of “design bases” has been revised.’
No description of what changed. No explanation of why. The most consequential definitional revision in the history of nuclear plant licensing was disposed of in one passive sentence buried at the end of a list.
DECADES OF CONSEQUENCES
By 1991, the NRC confessed to the confusion. NUREG-1397 stated it plainly on page 3:
There has been much confusion regarding terminology, in particular, what is meant by design bases. The NRC inspections discussed earlier in this report and other similar inspections at different plants led to the conclusion that many plants had unretrievable, undocumented, or incomplete design bases. This means that plants had insufficient design documentation to support the as-built facility.
The most telling admission is what came next:
“[The 10 CFR 50.2 definition of “design bases”] has caused some utilities to infer that in order to have an adequate design bases it is only necessary to define the functions performed by systems, structures, and components and the values or range of values for controlling parameters, without the supporting engineering or design analyses.”
In one sentence, the NRC admitted that the plants had complied exactly with the regulation.
But they considered this to be inadequate:
“There are three categories of design documents. These are design inputs, design analyses, and design output documents, and all are necessary to have a fully documented and auditable design.”
To address the design basis issue, in 1990, NUMARC, the predecessor of NEI, released its 90-12 report titled “Design Basis Program Guidelines.”
As a result, the industry spent millions of dollars on design basis reconstitution efforts throughout the 1990s trying to recover the specificity that the 1968 definition deleted as a requirement.
This was a massive effort.
For example, in January of 1989, PSE&G held a meeting with the NRC to discuss their DBD reconstitution efforts. One of the bullet points included in the notes made it clear: “Tremendous Effort Involved in Data Retrieval.”
Another heading titled “PSE&G and A/E Estimated Expenditures” listed the dollar values:
- $22 million – Salem
- $12 million – Hope Creek
Adjusted for inflation, that’s $93 million in 2026 dollars. For three units in a fleet of over 100 at the time.
Consider another data point provided by Southern California Edison regarding San Onofre’s document retrieval efforts. In an update to the NRC on their DBD progress in 1993, they noted an indexing effort for over 23,000 documents “containing an estimated 350,000 pages of calculations, analyses, studies, evaluations, and correspondence.”
THE INDUSTRY RESPONSE
The DBD reconstitution efforts continued throughout the 1990’s. But the issue of what is truly meant by “design bases” remained unresolved.
The industry finally drove the issue to the forefront of regulatory thought after 1997. The NRC responded with Regulatory Guide 1.186 in December of the year 2000–thirty-two years after the definition was codified.
NUMARC was consolidated into NEI in March of 1994, and one of the first efforts on which it embarked was to update the NUMARC 90-12 guidance. An NRC letter requested information that was considered beyond the scope of 50.2 design bases information, and NEI responded by issuing updated guidance to clarify the issue.
The updated guidance was released as NEI 97-04.
In the introduction, NEI wrote: “The primary focus of this document is to address the intent, content, development, and uses of design bases documents as they relate to the 10 CFR 50.2 definition.”
Further discussion between NEI and the NRC resulted in an updated version of Appendix B of 97-04 that clarified the relation of 50.2 design bases information to other important topics.
The NRC announced in the April 12, 2000 issue of the Federal Register the issuance of draft regulatory guidance that was “being developed to provide a better understanding of the term ‘design bases’ as defined in 10 CFR 50.2. This better understanding is to help the industry and the NRC staff implement the regulations that use the term design bases.”
In an October 2000 Policy Issue, it made this frank announcement: “Although the staff and the nuclear industry have agreed that it is important to understand what constitutes the design bases of a plant, there has been no agreement about the implementation of the definition in 10 CFR 50.2.”
Appendix B was endorsed by the NRC in Regulatory Guide 1.186.
In the opening paragraph of RG 1.186, issued in December of 2000, the NRC stated the issue plainly:
“Although the NRC staff and the nuclear industry have always agreed that it is important to understand what constitutes the design bases of a plant, there has not been agreement about the implementation of the definition in 10 CFR 50.2.”
THE ORIGINAL SPECIFICATION
For maximum clarity for any engineer attempting to get to the bottom of this problem, I refer them to the original AEC document upon which the 1966 regulations were based: “A Guide for the Organization and Contents of Safety Analysis Reports,” issued by the AEC on June 30 of 1966.
This is the Rosetta stone.
In the document’s “General Considerations,” it presents the pattern:
What the guide does is to lay out a pattern for the presentation of information based upon the following sequence:
(1) Identification of the principal criteria for design of the facility and the design bases for those major systems and components significant to safety.
(2) Description of how it is intended that the plant be built and operated to satisfy the principal criteria and design bases.
(3) Systematic safety analysis and evaluation of the design-that show plant performance objectives can be achieved and safety assured.
Such an approach to presentation of information is desired for all nuclear reactors.
More critically, it defines “design bases” more clearly than anywhere else:
Design Bases means that information which identifies the specific functions to be performed by a major component or system in terms of performance objectives together with specific values or range of values chosen for controlling parameters as reference bounds or limits for design. Such limits may be restraints derived from generally accepted “state of the art” practices for achieving functional goals (such as a “no-center melting” restriction placed upon fuel design) or requirements derived from calculating the effects of a situation representing an upper limit which a component or system could reach under credible circumstances (such as peak pressure loading of a containment).
Besides clarifying what “state of the art” practices are, it does one critical thing: yes, it essentially includes the second sentence added back into the final definition issued in 1968. But where the 1968 version links the source to generic “values,” the 1966 guidance links them to the limits.
The AEC Guide made the two clauses a classification of limits specifically. The 1968 version makes them an optional illustration of all values generally.
The clarifying examples confirm the analysis above: hard engineering criteria and calculated values from analyses to establish performance specifications were the intent. Quantifiable. Measurable. Testable.
Even better, the sections demonstrate the intent in action. Take, for example, Section III, Reactor:
Design Bases. The bases upon which the design of the reactor was established, including such matters as: (1) The functional or performance objectives for the reactor, such as average thermal power, core design lifetime, and fuel replacement program.
(2) Limits imposed upon the design by selection of specific values or ranges of values which are themselves safety bounds or control parameters which are safety bounds; e.g.:
(a) Nuclear Limits such as fuel burnup…
(b) Reactivity Control Limits such as shutdown margins…
(c) Thermal and Hydraulic Limits such as fuel and clad temperatures…
(d) Mechanical Limits such as maximum allowable stresses…
This one document shows what the original engineers intended before the lawyers got to it and molded it into the version of 10 CFR 50.2 “Design Bases” that we have to this day.
Returning to the source is exactly how NEI finally resolved the matter in NEI 97-04, referencing this document and its original intent. “The design bases definition in 10 CFR 50.2 was added to the regulations in 1968 to codify statements used in earlier Atomic Energy Commission (AEC) guidance on the content of a final safety analysis report (FSAR)…In reviewing the AEC documentation, it is clear that the term design bases is linked to major structures, systems, and components (SSCs) associated with the protection of public health and safety.”
Thirty-two years, and the industry guided the NRC back to its original source document, the departure from which created an expensive detour for the industry.
As an added bonus, the AEC’s 1966 guidance also formally defined “principal design criteria”:
Principal Design Criteria means those fundamental architectural and engineering design objectives established for the project. As such, these criteria represent the broad frame of reference within which the more detailed plant design effort is to proceed and against which the end project will be judged.
That definition never appeared in 10 CFR 50. It remains buried in the AEC guidance to this day.
THE NRC’S CONFESSION
In language that was removed from the final RG 1.186, the draft guidance made a number of admissions:
The staff notes that its implementation of the design bases definition has been inconsistent over the years. When considering applications for licenses to operate nuclear power plants in the mid-to-late 1960s, the staff had, in general, a narrow view of what information constituted design bases…
The staff acknowledges that the definition has been read by some to mean that all functions described in the UFSAR are design bases functions. In addition, the definition does not, by its terms, specify the functions considered in establishing design bases, therefore it does not limit the scope of components having design bases to those that have a bearing on system function or have their own independent function…
With regard to values, the guidance focuses on reference bounds for design necessary to meet design bases functional requirements as defined above. The rule, however, does not directly link the values solely to the “functional requirements” since the rule also refers to “controlling parameters as reference bounds for design” and, in the next sentence, states that these values “may be derived from. . . practices for achieving functional goals.” Thus whether the entire set of bounding values (which may be derived from a number of considerations) are “design bases,” or only those values directly corresponding to the design bases functions has also been a point of controversy in the past…
The confusion generated parallel corrective actions. Issuing RG 1.186 in December of 2000 was one. Another was designed to reduce reporting burden: the NRC revised the reporting criteria of 10 CFR 50.72 and 50.73 to eliminate the vague “outside the design basis” reporting trigger, replacing it with risk-informed specificity effective January 2001.
The NRC also revised 10 CFR 50.59 in 1999, effective 2001, which I’ve documented extensively here, to clarify the documentation requirements further: 10 CFR 50.59 – A history of the rule’s development.
Perhaps the most ironic comments are contained at the end of the draft guidance, just before the conclusion statement. Here they are, with my remarks:
The staff does recognize that the text in the 10 CFR 50.2 definition of design bases permits substantial latitude in the interpretation of what constitutes design bases information.
Substantial latitude indeed. NUREGs, policy statements, regulatory guides issued. All suggestions. None required.
The staff has considered a rule change but has not done an analysis of the costs and benefits. The staff believes that there may be some benefit in proceeding to rulemaking in an effort to add specificity to the rule definition.
They didn’t count the cost of clarifying the definition. We know something of the cost from primary source documents: Thirty-two years of design basis documentation degradation, loss of configuration control, and hundreds of millions of dollars spent reconstituting them to return to the requirements issued in the original specification document issued by the AEC in 1966.
(Note that resources for rulemaking on the design bases definition during Fiscal Year 2000 have not been budgeted.)
CONCLUSION
In fiscal year 2000, thirty-two years after the consequential design error was introduced, the NRC acknowledged in writing that their definition permitted substantial latitude, considered fixing it, declined to budget the analysis of whether fixing it was worthwhile, and offered a non-binding regulatory guide as the substitute.
The industry had spent those thirty-two years and hundreds of millions of dollars trying to implement a definition that the regulator acknowledged was broken but declined to repair.
The 1966 proposed rules were an engineering document. The final 1968 version we got was a legal document. The industry spent decades reeling from a consequential design error.
And the design was the final regulation itself.