Documentation Demonstrating Regulatory Compliance in the Plant Operating States Analysis Schema

Introduction
Coverage of Regulatory Requirements
POS-D1
POS-D2
POS-D3
Peer Review and Validation
Transition Risk Analysis
Plant Representation Accuracy
Configuration Control and Traceability

1. POS-D1 Compliance

1.1 POS-D1.a

The schema captures plant evolutions through the plantEvolutions field in the PlantOperatingStatesAnalysis interface:

typescript

plantEvolutions: PlantEvolution[];

Each PlantEvolution contains detailed definitions as required:

typescript

export interface PlantEvolution extends Unique, Named {
  description?: string;
  operatingModes: string[];
  rcbConfigurations: string[];
  rcsParameters: {
    powerLevel?: number;
    temperature?: number;
    pressure?: number;
    coolantInventory?: number;
  };
  availableInstrumentation: string[];
  activitiesLeadingToChanges: string[];
  radionuclideTransportBarriersStatus: string[];
  sscCapabilitiesChanges: string[];
  operationalAssumptions: string[];
  plantOperatingStates: PlantOperatingState[];
  // Additional fields...
}

The schema also tracks whether at-power operations are included in the analysis as required by regulation:

typescript

includesAtPowerOperations: boolean;

Sample Documentation for Plant Evolutions

Plant Evolution: Normal Power Operation

Description: Normal operation from startup to shutdown
Operating Modes: POWER, STARTUP, SHUTDOWN
RCB Configurations: Pressure boundary intact, Vented for maintenance
RCS Parameters: Power level: 100%, Temperature: 550°F, Pressure: 2250 psia
Available Instrumentation: Reactor pressure, Reactor temperature, Neutron flux
Activities Leading to Changes: Load following, Startup sequence, Normal shutdown
Radionuclide Barriers Status: All barriers intact during power operation
SSC Capabilities Changes: No changes during normal operation
Operational Assumptions: Reactor operates at full power for 90% of operational time

1.2 POS-D1.b

The schema documents the identification process through the PlantOperatingStatesDocumentation interface:

typescript

export interface PlantOperatingStatesDocumentation {
  // Process description for POS identification
  identificationProcessDetails: string;
  // Other fields...
}

Each PlantOperatingState is clearly defined with unique boundaries:

typescript

export interface PlantOperatingState extends Unique, Named {
  description?: string;
  characteristics?: string;
  processCriteriaIdentification?: string;
  timeBoundary: TimeBoundary;
  // Other fields...
}

The TimeBoundary interface ensures clear delineation between states:

typescript

export interface TimeBoundary {
  startingCondition: string;
  endingCondition: string;
  transitionParameters?: TransitionParameter[];
}

Sample Documentation for POS Identification Process

POS Identification Process:

Analyzed the complete plant operating cycle from initial startup to shutdown
Identified distinct plant conditions based on:
- Reactor power levels
- RCS configuration
- Equipment availability
- Decay heat levels
- Barrier statuses
Defined explicit time boundaries for each POS
Verified mutual exclusivity using the POSValidationRules interface
Confirmed collective exhaustivity to ensure complete coverage of the operating cycle

POS Identification Criteria:

Changes in major safety function availability
Changes in barrier status
Significant changes in plant parameters (e.g., RCS pressure/temperature)
Changes in decay heat removal capabilities
Changes in reactor coolant inventory
Significant operator actions or alignments

1.3 POS-D1.c

The schema supports grouping of plant operating states through the plantOperatingStatesGroups field:

typescript

plantOperatingStatesGroups?: PlantOperatingStatesGroup[];

Each group has detailed documentation of the process:

typescript

export interface PlantOperatingStatesGroup extends Unique, Named {
  description?: string;
  plantOperatingStateIds: string[];
  groupingJustification: string;
  representativeCharacteristics: string[];
}

The schema also tracks subsumed operating states:

typescript

subsumedPOSs?: SubsumedPOS[];

Each subsumed POS is documented with clear justification:

typescript

export interface SubsumedPOS {
  subsumedPOS: string;
  subsumingPOS: string;
  justification: string;
  riskImpact?: "HIGH" | "MEDIUM" | "LOW";
  limitations?: string[];
  validationMethod?: string;
}

Sample Documentation for POS Grouping Process

POS Grouping Criteria:

Similar decay heat levels
Similar RCS configurations
Similar available equipment
Similar initiating events
Similar success criteria

Grouping Process:

Evaluated each POS against the grouping criteria
Identified POSs with similar characteristics
Performed sensitivity analysis to verify that grouping doesn't mask risk insights
Documented justification for each grouping decision
Maintained the most limiting characteristics for each group

Example Grouping Justification: POS-5A and POS-5B were grouped because they share similar decay heat levels (0.5-0.7% of rated power), identical RCS configurations (vented, reduced inventory), and the same set of available safety systems. Sensitivity analysis confirmed that using the parameters from POS-5A (the more limiting case) provides conservative results for both states.

1.4 POS-D1.d

The schema provides detailed definitions of each POS group through the PlantOperatingStatesGroup interface:

typescript

export interface PlantOperatingStatesGroup extends Unique, Named {
  description?: string;
  plantOperatingStateIds: string[];
  groupingJustification: string;
  representativeCharacteristics: string[];
}

Sample Documentation for POS Group Definition

POS Group: Low Power Operations

Description: Includes all operating states between 0-15% reactor power
Included POS IDs: POS-2A, POS-2B, POS-2C
Grouping Justification: These states share similar thermal-hydraulic conditions, available safety systems, and potential initiating events
Representative Characteristics:
- Power level: 10% (most limiting)
- RCS pressure: 2200 psia
- RCS temperature: 547°F
- All safety systems available
- Manual reactor control
- Turbine synchronization activities in progress

POS Group: Mid-Loop Operations

Description: Includes all operating states with reduced RCS inventory
Included POS IDs: POS-5A, POS-5B
Grouping Justification: Both states have similar reduced inventory conditions and decay heat removal configurations
Representative Characteristics:
- RCS level at mid-loop elevation
- Decay heat 0.7% of rated power (most limiting)
- RHR providing decay heat removal
- RCS vented
- Equipment hatch closed
- Time since shutdown: 48-96 hours

1.5 POS-D1.e

Each PlantOperatingState in the schema has comprehensive characteristics defined:

typescript

export interface PlantOperatingState extends Unique, Named {
  description?: string;
  characteristics?: string;
  radioactiveMaterialSources: string[];
  operatingMode: OperatingState;
  rcbConfiguration: string;
  rcsParameters: ReactorCoolantSystemParameters;
  decayHeatRemoval: DecayHeatRemovalSystems;
  availableInstrumentation: string[];
  radionuclideTransportBarrier: RadionuclideTransportBarriers;
  initiatingEvents: InitiatingEvent[];
  safetyFunctions: SafetyFunction[];
  // Additional fields...
}

The ReactorCoolantSystemParameters interface specifically captures key parameters:

typescript

export interface ReactorCoolantSystemParameters {
  powerLevel: [number & tags.Minimum<0>, number & tags.Maximum<1>];
  decayHeatLevel: [number & tags.Minimum<0>, number & tags.Maximum<1>];
  reactorCoolantTemperatureAtControlVolume1: [number & tags.Minimum<0>, number & tags.Maximum<1>];
  coolantPressureAtControlVolume1: [number & tags.Minimum<0>, number & tags.Maximum<1>];
  others?: [number, number];
  reactorLevel?: [number & tags.Minimum<0>, number & tags.Maximum<1>];
  timeAfterShutdown?: number;
  rcsConfigurationDescription?: string;
}

Sample Documentation for POS Characteristics

POS: Full Power Operation (POS-1)

Description: Normal operation at rated thermal power
Characteristics: Steady-state operation with all safety systems available
Operating Mode: POWER
RCB Configuration: Intact, all penetrations closed
RCS Parameters:
- Power Level: [0.98, 1.0] (fraction of rated power)
- Decay Heat Level: [0.07, 0.07] (fraction of rated power)
- RCS Temperature: [540°F, 560°F]
- RCS Pressure: [2200 psia, 2300 psia]
Decay Heat Removal Systems:
- Primary Cooling Systems:
- Secondary Cooling Systems:
Available Instrumentation: Reactor pressure, temperature, level, neutron flux, coolant flow
Radionuclide Transport Barriers:
- Barrier1: INTACT
- Barrier2: INTACT
Initiating Events: LOCA events, transients, loss of offsite power
Safety Functions: Reactivity control, core cooling, RCS pressure control

POS: Mid-Loop Operation (POS-5A)

Description: Reduced inventory operation for maintenance activities
Characteristics: Reduced inventory with time after shutdown > 72 hours
Operating Mode: SHUTDOWN
RCB Configuration: Equipment hatch closed, personnel airlock open
RCS Parameters:
- Power Level: [0, 0] (fraction of rated power)
- Decay Heat Level: [0.005, 0.007] (fraction of rated power)
- RCS Temperature: [100°F, 120°F]
- RCS Pressure: [0 psia, 0 psia]
- Reactor Level: [0.33, 0.38] (fraction of full level)
- Time After Shutdown: 72 hours
Decay Heat Removal Systems:
- Primary Cooling Systems:
- Secondary Cooling Systems:
Available Instrumentation: RCS temperature, level, RHR flow
Radionuclide Transport Barriers:
- Barrier1: BREACHED
- Barrier2: INTACT
Initiating Events: Loss of RHR, inventory loss events
Safety Functions: Decay heat removal, RCS inventory control

1.6 POS-D1.f

The schema captures these temporal aspects through multiple fields:

typescript

export interface PlantOperatingState {
  // Other fields...
  meanDuration: number;
  meanTimeSinceShutdown?: number;
  meanFrequency?: Frequency;
}

The schema also supports detailed frequency and duration analysis:

typescript

export interface OperatingStatesFrequencyDuration {
  outagePlansRecords: {
    /* fields */
  }[];
  maintenancePlansRecords: {
    /* fields */
  }[];
  operationsData: {
    /* fields */
  }[];
  tripHistory: {
    /* fields */
  }[];
  summary?: {
    posName: string;
    averageDuration: number;
    entriesPerYear: number;
    fractionOfTime: number;
  }[];
}

Sample Documentation for POS Durations and Frequencies

POS: Full Power Operation (POS-1)

Mean Duration: 7300 hours
Mean Time Since Shutdown: N/A (operating state)
Mean Frequency: 1.0 per year
Fraction of Time: 0.83 (83% of plant operating time)

POS: Normal Shutdown (POS-3)

Mean Duration: 24 hours
Mean Time Since Shutdown: 0 hours (beginning of shutdown)
Mean Frequency: 1.0 per year
Fraction of Time: 0.003 (0.3% of plant operating time)

POS: Refueling (POS-7)

Mean Duration: 240 hours
Mean Time Since Shutdown: 96 hours
Mean Frequency: 0.5 per year (biennial refueling)
Fraction of Time: 0.014 (1.4% of plant operating time)

1.7 POS-D1.g

Decay heat information is captured in the rcsParameters field:

typescript

export interface ReactorCoolantSystemParameters {
  // Other fields...
  decayHeatLevel: [number & tags.Minimum<0>, number & tags.Maximum<1>];
  timeAfterShutdown?: number;
}

Time-varying decay heat is further captured through:

typescript

export interface TimeVaryingCondition extends Unique, Named {
  time: number;
  parameter: string;
  value: number;
  impact: string;
  units?: string;
  uncertainty?: number;
  requiresMonitoring: boolean;
}

Sample Documentation for Decay Heat Association

Decay Heat Levels by POS in Normal Operation Evolution:

POS ID	POS Name	Min Decay Heat (%)	Max Decay Heat (%)	Time After Shutdown (hrs)
POS-1	Full Power	7.0	7.0	N/A
POS-2	Reactor Trip	7.0	6.0	0-1
POS-3	Hot Standby	6.0	4.0	1-4
POS-4	Cooldown	4.0	2.5	4-24
POS-5A	Mid-Loop (Early)	2.5	1.7	24-48
POS-5B	Mid-Loop (Late)	1.7	0.7	48-96
POS-6	Cavity Flooded	0.7	0.5	96-336
POS-7	Refueling	0.5	0.4	336-576

Time-Varying Decay Heat for POS-3 (Hot Standby):

Time (hrs)	Decay Heat (%)	Impact on Safety Functions	Requires Monitoring
1.0	6.0	High heat load on AFW and PORVs	Yes
2.0	5.0	Moderate heat load, RHR entry conditions	Yes
3.0	4.5	Reduced heat load, approaching RHR entry	Yes
4.0	4.0	Minimum heat load for this POS	Yes

1.8 Specific Interfaces with Other PRA Tasks (POS-D1.h)

The schema includes explicit interfaces with other PRA tasks:

typescript

export interface PlantOperatingStatesDocumentation {
  // Other fields...
  praTaskInterfaces: string;
}

Additionally, cross-references to other technical elements exist throughout:

typescript

export interface PlantOperatingState {
  // Other fields...
  initiatingEvents: InitiatingEvent[];
  successCriteriaIds?: SuccessCriteriaId[];
}

Sample Documentation for PRA Task Interfaces

Interfaces with Other PRA Tasks:

Initiating Event Analysis: The POS Analysis provides the operational context for initiating event identification and quantification. Each POS has a defined set of applicable initiating events referenced through the initiatingEvents field.
Success Criteria Analysis: POS-specific success criteria are referenced through the successCriteriaIds field, which uses the standardized pattern ^SC-[A-Z0-9-]+$ from shared patterns. Each POS has unique thermal-hydraulic conditions that affect system success criteria.

The success criteria IDs follow a consistent format across the PRA:

Format: SC-[SYSTEM]-[NUMBER]
Example: SC-RCIC-001
Pattern validation ensures consistent formatting

Systems Analysis: The availability and configuration of systems in each POS are captured in the decayHeatRemoval field. This information feeds into the systems analysis task.
Human Reliability Analysis: POS-specific operator actions are documented in the evolutionConsiderations.operatorActions field. This information supports human reliability analysis for different plant conditions.
Data Analysis: Historical data on POS frequencies and durations is captured in the OperatingStatesFrequencyDuration interface. This provides input to the Data Analysis technical element.

Example Interface Control: When the Success Criteria Analysis is updated, the corresponding success criteria IDs in the POS Analysis are verified for consistency. Likewise, when new initiating events are identified, they are mapped to the appropriate POS definitions.

2. POS-D2 Compliance

2.1 Schema Support for Model Uncertainty Documentation

typescript

export interface PlantOperatingStatesAnalysis {
  // Other fields...

  /**
   * Sources of model uncertainty related to POS definitions
   * @implements POS-A12
   */
  modelUncertainty?: ModelUncertaintyInfo[];

  // Additional fields for documentation
  documentation?: PlantOperatingStatesDocumentation;
}

The ModelUncertaintyInfo interface provides a structured way to document these uncertainties:

typescript

export interface ModelUncertaintyInfo {
  /** Source of the uncertainty */
  source: string;

  /** Description of the uncertainty */
  description: string;

  /** Impact level of the uncertainty */
  impact: "HIGH" | "MEDIUM" | "LOW";

  /** How the uncertainty is treated in the model */
  treatment: string;

  /** Reasonable alternatives that could be considered */
  reasonableAlternatives?: string[];
}

2.2 Example Model Uncertainty Documentation

Below is an example of how model uncertainties would be documented using the schema:

typescript

const posAnalysis: PlantOperatingStatesAnalysis = {
  // Other fields...

  modelUncertainty: [
    {
      source: "Decay Heat Calculation Method",
      description:
        "The ANS 1979 decay heat model includes uncertainties that impact time-to-boil calculations in low-power states",
      impact: "MEDIUM",
      treatment: "Used ANS 1979 + 2σ uncertainty to ensure conservative time windows",
      reasonableAlternatives: [
        "ANS 1994 decay heat model with plant-specific adjustments",
        "Use of actual measured data from similar plants to refine the model",
      ],
    },
    {
      source: "Plant Evolution Timeline",
      description: "Limited operational experience causes uncertainty in duration of transitional states",
      impact: "LOW",
      treatment: "Used conservative estimates based on similar plant designs",
      reasonableAlternatives: ["Use shorter durations to assess impact on overall risk profile"],
    },
    {
      source: "Success Criteria in Transitional States",
      description: "Thermal-hydraulic analyses have higher uncertainty during rapidly changing conditions",
      impact: "HIGH",
      treatment: "Used bounding analysis at multiple snapshots within each transitional state",
      reasonableAlternatives: [
        "Dynamic thermal-hydraulic modeling throughout the transition",
        "More granular subdivision of transitional states",
      ],
    },
  ],
};

This example shows how the schema effectively documents:

The sources of model uncertainty
Detailed descriptions of each uncertainty
The relative impact of each uncertainty
How the uncertainty is treated in the analysis
Reasonable alternative approaches that could be considered

3. POS-D3 Compliance

3.1 Schema Support for Pre-operational Limitations

typescript

export interface PlantOperatingStatesAnalysis {
  // Other fields...

  /**
   * List of assumptions due to lack of as-built details
   * @implements POS-A13, POS-B8
   */
  assumptionsLackOfDetail?: AssumptionsLackOfDetail[];

  // Documentation and other fields
}

The AssumptionsLackOfDetail interface is specifically designed to address POS-D3:

typescript

export interface AssumptionsLackOfDetail {
  /**
   * Description of the assumption made
   */
  description: string;

  /**
   * Influences of plant operating state definitions
   */
  influence: string;

  /**
   * Impact assessment of this assumption on risk
   */
  riskImpact: "HIGH" | "MEDIUM" | "LOW";

  /**
   * Justification for the assumption
   */
  justification?: string;

  /**
   * Planned actions to validate or refine this assumption
   */
  plannedActions?: string[];

  /**
   * Affected plant operating states
   */
  affectedPOSIds?: string[];

  /**
   * Potential alternatives to this assumption
   */
  potentialAlternatives?: string[];

  /**
   * Sensitivity analysis results, if performed
   */
  sensitivityAnalysis?: string;
}

3.2 Example Pre-operational Limitations Documentation

Below is an example of how pre-operational limitations would be documented using the schema:

typescript

const posAnalysis: PlantOperatingStatesAnalysis = {
  // Other fields...

  assumptionsLackOfDetail: [
    {
      description: "RCS temperature distribution during mid-loop operations",
      influence: "Affects success criteria for decay heat removal systems in POS-5A and POS-5B",
      riskImpact: "HIGH",
      justification: "No as-built instrument locations available to confirm thermal stratification",
      plannedActions: [
        "Confirm thermal-hydraulic assumptions with scale model testing",
        "Add additional temperature sensors during commissioning",
      ],
      affectedPOSIds: ["POS-5A", "POS-5B"],
      potentialAlternatives: [
        "Conservative uniform temperature assumption",
        "Detailed CFD modeling with sensitivity studies",
      ],
      sensitivityAnalysis:
        "Sensitivity studies show mid-loop operation risk estimates may vary by a factor of 2-3 depending on temperature distribution assumptions",
    },
    {
      description: "Operator response times for non-routine evolutions",
      influence: "Affects time available for operator actions in transitional states",
      riskImpact: "MEDIUM",
      justification: "No operating crew performance data available pre-operation",
      plannedActions: [
        "Conduct timed simulator exercises during training",
        "Refine estimates after initial plant operation",
      ],
      affectedPOSIds: ["POS-3", "POS-4", "POS-5A"],
      sensitivityAnalysis:
        "Sensitivity study assuming 1.5x longer response times shows acceptable safety margins maintained",
    },
    {
      description: "System alignment transition times during outage activities",
      influence: "Affects vulnerability windows for specific initiating events",
      riskImpact: "MEDIUM",
      justification: "Limited information on maintenance procedures and crew coordination",
      plannedActions: [
        "Develop detailed maintenance procedures",
        "Benchmark against similar plant outage data",
        "Update PRA after first refueling outage",
      ],
      affectedPOSIds: ["POS-4", "POS-5A", "POS-6"],
      potentialAlternatives: [
        "Use of bounding estimates from industry experience",
        "Application of uncertainty factors to account for variations",
      ],
      sensitivityAnalysis:
        "Sensitivity studies show that even with 2x longer alignment times, core damage frequency remains below threshold",
    },
  ],
};

This example shows how the schema effectively documents:

Assumptions made due to lack of as-built, as-operated details
How these assumptions influence POS definitions
Risk impact assessments
Justifications for the assumptions
Planned actions to validate or refine assumptions during commissioning
Affected plant operating states
Potential alternative approaches
Results of sensitivity analyses

Such documentation satisfies the requirements of POS-D3 by providing a structured approach to capturing pre-operational limitations and plans to address them.

4. Configuration Control and Traceability

The schema ensures traceability through unique identifiers and explicit cross-references:

typescript

export interface Unique {
  /** Unique identifier for the element */
  uuid: string;
}

export interface Named {
  /** Name of the element */
  name: string;
}

Each POS, evolution, and group has a unique identifier that can be referenced across the PRA model. This ensures changes can be tracked and impacts assessed across the model.

Peer Review and Validation

The schema includes comprehensive support for peer review findings and validation through several interfaces:

PeerReviewFinding interface:

typescript

export interface PeerReviewFinding {
  /** ID of the peer review finding */
  findingId: string;

  /** Description of the finding */
  description: string;

  /** Category of the finding */
  category: string;

  /** Significance of the finding (HIGH/MEDIUM/LOW) */
  significance: ImportanceLevel;

  /** Response to the finding */
  response: string;

  /** Actions taken to address the finding */
  actions?: string[];

  /** Resolution status */
  status: "OPEN" | "CLOSED" | "IN_PROGRESS";
}

POSValidationRules interface:

typescript

export interface POSValidationRules {
  /** Validates mutual exclusivity between POSs */
  mutualExclusivityRules: {
    description: string;
    delineationParameters: string[];
    verificationMethod: string;
  };

  /** Validates collective exhaustivity of POSs */
  collectiveExhaustivityRules: {
    description: string;
    verificationMethod: string;
    configurationCoverage: string;
  };

  /** Rules for transitions between POSs */
  transitionRules: {
    transitionMatrix: Record<string, string[]>;
    transitionTriggers: Record<string, string>;
  };
}

Transition Risk Analysis

The schema includes dedicated interfaces for documenting transition risks:

TransitionRisk interface:

typescript

export interface TransitionRisk {
  /** ID of the transition */
  transitionId: string;

  /** Description of the transition */
  description: string;

  /** Risks associated with the transition */
  risks: string[];

  /** Significance of the risks */
  significance: ImportanceLevel;

  /** Mitigating actions */
  mitigatingActions?: string[];

  /** Human actions required during this transition */
  requiredHumanActions?: string[];

  /** Equipment that must be available during this transition */
  requiredEquipment?: string[];
}

Enhanced TransitionEvent interface with additional fields:

typescript

export interface TransitionEvent extends Unique {
  // ... existing fields ...

  /** Risk significance of this transition */
  riskSignificance?: ImportanceLevel;

  /** Mitigating actions to reduce transition risks */
  mitigatingActions?: string[];

  /** Human actions required during this transition */
  requiredHumanActions?: string[];

  /** Equipment that must be available during this transition */
  requiredEquipment?: string[];

  /** Potential failure modes during this transition */
  potentialFailureModes?: string[];
}

Plant Representation Accuracy

The schema includes comprehensive support for assessing plant representation accuracy:

PlantRepresentationAccuracy interface:

typescript

export interface PlantRepresentationAccuracy {
  /** Degree of accuracy */
  accuracy: ImportanceLevel;

  /** Basis for accuracy assessment */
  basis: string;

  /** Limitations in plant representation */
  limitations?: string[];

  /** Actions to improve accuracy */
  improvementActions?: string[];

  /** Assessment of sufficiency for risk-significant contributors */
  sufficientForRiskSignificantContributors: boolean;

  /** Justification for the sufficiency assessment */
  sufficiencyJustification?: string;
}

Enhanced PlantOperatingState with accuracy assessment:

typescript

export interface PlantOperatingState extends Unique, Named {
  // ... existing fields ...

  /** Plant representation accuracy for this POS */
  plantRepresentationAccuracy?: PlantRepresentationAccuracy & {
    /** Areas with high confidence */
    highConfidenceAreas?: string[];

    /** Areas with lower confidence */
    lowerConfidenceAreas?: string[];

    /** Plans for improvement */
    improvementPlans?: string[];
  };
}

Enhanced PlantOperatingStatesAnalysis with time-varying conditions:

typescript

export interface PlantOperatingStatesAnalysis
  extends TechnicalElement<TechnicalElementTypes.PLANT_OPERATING_STATES_ANALYSIS> {
  // ... existing fields ...

  /** Time-varying conditions across multiple POSs */
  timeVaryingConditions?: TimeVaryingCondition[];
}

Documentation Demonstrating Regulatory Compliance in the Plant Operating States Analysis Schema ​

Table of Contents ​

1. POS-D1 Compliance ​

1.1 POS-D1.a ​

Sample Documentation for Plant Evolutions ​

1.2 POS-D1.b ​

Sample Documentation for POS Identification Process ​

1.3 POS-D1.c ​

Sample Documentation for POS Grouping Process ​

1.4 POS-D1.d ​

Sample Documentation for POS Group Definition ​

1.5 POS-D1.e ​

Sample Documentation for POS Characteristics ​

1.6 POS-D1.f ​

Sample Documentation for POS Durations and Frequencies ​

1.7 POS-D1.g ​

Sample Documentation for Decay Heat Association ​

1.8 Specific Interfaces with Other PRA Tasks (POS-D1.h) ​

Sample Documentation for PRA Task Interfaces ​

2. POS-D2 Compliance ​

2.1 Schema Support for Model Uncertainty Documentation ​

2.2 Example Model Uncertainty Documentation ​

3. POS-D3 Compliance ​

3.1 Schema Support for Pre-operational Limitations ​

3.2 Example Pre-operational Limitations Documentation ​

4. Configuration Control and Traceability ​

Peer Review and Validation ​

Transition Risk Analysis ​

Plant Representation Accuracy ​

Documentation Demonstrating Regulatory Compliance in the Plant Operating States Analysis Schema

Table of Contents

1. POS-D1 Compliance

1.1 POS-D1.a

Sample Documentation for Plant Evolutions

1.2 POS-D1.b

Sample Documentation for POS Identification Process

1.3 POS-D1.c

Sample Documentation for POS Grouping Process

1.4 POS-D1.d

Sample Documentation for POS Group Definition

1.5 POS-D1.e

Sample Documentation for POS Characteristics

1.6 POS-D1.f

Sample Documentation for POS Durations and Frequencies

1.7 POS-D1.g

Sample Documentation for Decay Heat Association

1.8 Specific Interfaces with Other PRA Tasks (POS-D1.h)

Sample Documentation for PRA Task Interfaces

2. POS-D2 Compliance

2.1 Schema Support for Model Uncertainty Documentation

2.2 Example Model Uncertainty Documentation

3. POS-D3 Compliance

3.1 Schema Support for Pre-operational Limitations

3.2 Example Pre-operational Limitations Documentation

4. Configuration Control and Traceability

Peer Review and Validation

Transition Risk Analysis

Plant Representation Accuracy