Document: NUREG-0800
Document ID: 4f0d611c-d3fb-43e5-ab91-e7f7b4de3511
Document Type: srp
Title: Determining the Technical Adequacy of Probabilistic Risk
Source: NUREG-0800
Source URL: https://www.nrc.gov/docs/ML0406/ML040630300.pdf
Revision Date: 2023-06
Chapter: 19
Section ID: 19.1
CFR Part: 
CFR Title: 

Content:
ddress this full scope, the decision makers must make allowances for these omissions. Examples of allowances include the introduction of compensatory measures, restriction of the implementation of the proposed change to the aspects of the plant covered by the risk model, and use of bounding arguments to cover the risk contributions not addressed by the model. This SRP does not address this aspect of decision making but is focused on what information should be provided. The reviewer’s responsibility is to understand the scope of the PRA used in the decision making so that the appropriate appendices to Regulatory Guide 1.200 are identified as references for the review. III.1.3 Parts of the PRA Model Used in Application To assess the quality of the PRA input for a decision, the licensee identifies which parts of the PRA are called upon to provide the PRA results called for by the acceptance criteria. These include not only the logic model events onto which the cause-effect relationships are mapped, but also all the events that appear in the accident sequences in which the first group of elements appear and the parts of the analysis required to evaluate the necessary results. For some applications, this may be a limited set, but for others, e.g., risk-informing the scope of special treatment requirements, all parts of the PRA model are relevant. In applying this SRP, the reviewer need only address those parts identified as being required to support the PRA results used. III.2 Assessment of the PRA The part of the PRA used for the application is assessed to determine whether it is of sufficient technical quality. There are two aspects to assessing the acceptability and adequacy of the PRA results. First, the underlying PRA must be technically sound. This implies that (1) the PRA model, or the parts of the model required to support the application, represent the as-built and as-operated plant, which in turn implies that the PRA is up to date and reflects the current