open-nuclear-ops/starter-kit
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Initial commit

Browse source
This commit is contained in:
Nick Touran 2025-09-22 14:54:12 -04:00
commit 98edb494ae
55 changed files with 1905 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

162
.gitignore vendored Normal file
View file

@ -0,0 +1,162 @@
**/generated_assets/
# Typical Python stuff:
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
# C extensions
*.so
# Distribution / packaging
.Python
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
share/python-wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST
# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# Unit test / coverage reports
htmlcov/
.tox/
.nox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.py,cover
.hypothesis/
.pytest_cache/
cover/
# Translations
*.mo
*.pot
# Django stuff:
*.log
local_settings.py
db.sqlite3
db.sqlite3-journal
# Flask stuff:
instance/
.webassets-cache
# Scrapy stuff:
.scrapy
# Sphinx documentation
docs/_build/
# PyBuilder
.pybuilder/
target/
# Jupyter Notebook
.ipynb_checkpoints
# IPython
profile_default/
ipython_config.py
# pyenv
# For a library or package, you might want to ignore these files since the code is
# intended to run in multiple environments; otherwise, check them in:
# .python-version
# pipenv
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
# However, in case of collaboration, if having platform-specific dependencies or dependencies
# having no cross-platform support, pipenv may install dependencies that don't work, or not
# install all needed dependencies.
#Pipfile.lock
# poetry
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
# This is especially recommended for binary packages to ensure reproducibility, and is more
# commonly ignored for libraries.
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
#poetry.lock
# pdm
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
#pdm.lock
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
# in version control.
# https://pdm.fming.dev/#use-with-ide
.pdm.toml
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
__pypackages__/
# Celery stuff
celerybeat-schedule
celerybeat.pid
# SageMath parsed files
*.sage.py
# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/
# Spyder project settings
.spyderproject
.spyproject
# Rope project settings
.ropeproject
# mkdocs documentation
/site
# mypy
.mypy_cache/
.dmypy.json
dmypy.json
# Pyre type checker
.pyre/
# pytype static type analyzer
.pytype/
# Cython debug symbols
cython_debug/
# PyCharm
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
# and can be added to the global gitignore or merged into this file. For a more nuclear
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
#.idea/

8
.vscode/settings.json vendored Normal file
View file

@ -0,0 +1,8 @@
{
"esbonio.sphinx.confDir": "",
"[python]": {
"editor.codeActionsOnSave": {
"source.organizeImports": "explicit"
}
},
}

68
README.md Normal file
View file

@ -0,0 +1,68 @@
# Nuclear Reactor Starter Kit
The Nuclear Reactor Starter Kit (NRSK) is a set of requirements, procedures,
processes, templates, checklists, and data intended as a starting point for
a commercial nuclear reactor development and/or deployment program. The
objective of the NRSK is to speed up nuclear reactor deployment worldwide. Its
approach for doing so includes:
1. To identify and document modern best practices for achieving compliance and efficiency
2. To allow the nuclear industry to collaborate and share
3. To help newcomers to the field ramp up quickly
All commercial nuclear reactor and fuel processing facilities and their suppliers are
required by law to follow a set of rigorous regulations. Doing so doesn't need to be
debilitating.
The NRSK began as USA-centric in that it started with fundamental quality requirements
from 10 CFR 50 Appendix B and traced down uniformly to specific procedure sections and
other needs. However, given some homogeneity in nuclear quality regulatory regimes
worldwide, it is expected that this will be readily adaptable to other jurisdictions as
well.
## Features
- Scrape GDCs from 10 CFR 50 App A into individual requirements
- Scrape each 'shall' statement from 10 CFR 50 App B into individual
requirements to drive a traceable QA procedure set
- Provide procedures implementing the requirements
- Each section of each procedure explicitly tied to a basis explaining why it is
the way it is (flowed down from regulatory requirements or elsewhere)
- Provide fillable forms and checklists to document progress and compliance
- Fillable by human and/or computer (e.g. e-forms)
## Installing
### Install prerequisites
- python
- xelatex
### Install NSRK
1. Make a virtual environment:
python3 -m venv /path/to/venv
source /path/to/venv/bin/activate
2. Clone repo:
git clone /path/to/nrsk
3. Install dependencies:
pip install -e .[dev]
## Building initial documents
Generate the baseline data files:
python src/nsrk/regs/load_10cfr50.py
Build docs via Sphinx using::
cd documents
make html
make latex
cd build/latex
for f in *.tex; do xelatex $f; done

162
data/regs/10-cfr-50-app-a.txt Normal file
View file

@ -0,0 +1,162 @@
I. Overall Requirements
Criterion 1—Quality standards and records. Structures, systems, and components important to safety shall be designed, fabricated, erected, and tested to quality standards commensurate with the importance of the safety functions to be performed. Where generally recognized codes and standards are used, they shall be identified and evaluated to determine their applicability, adequacy, and sufficiency and shall be supplemented or modified as necessary to assure a quality product in keeping with the required safety function. A quality assurance program shall be established and implemented in order to provide adequate assurance that these structures, systems, and components will satisfactorily perform their safety functions. Appropriate records of the design, fabrication, erection, and testing of structures, systems, and components important to safety shall be maintained by or under the control of the nuclear power unit licensee throughout the life of the unit.
Criterion 2—Design bases for protection against natural phenomena. Structures, systems, and components important to safety shall be designed to withstand the effects of natural phenomena such as earthquakes, tornadoes, hurricanes, floods, tsunami, and seiches without loss of capability to perform their safety functions. The design bases for these structures, systems, and components shall reflect: (1) Appropriate consideration of the most severe of the natural phenomena that have been historically reported for the site and surrounding area, with sufficient margin for the limited accuracy, quantity, and period of time in which the historical data have been accumulated, (2) appropriate combinations of the effects of normal and accident conditions with the effects of the natural phenomena and (3) the importance of the safety functions to be performed.
Criterion 3—Fire protection. Structures, systems, and components important to safety shall be designed and located to minimize, consistent with other safety requirements, the probability and effect of fires and explosions. Noncombustible and heat resistant materials shall be used wherever practical throughout the unit, particularly in locations such as the containment and control room. Fire detection and fighting systems of appropriate capacity and capability shall be provided and designed to minimize the adverse effects of fires on structures, systems, and components important to safety. Firefighting systems shall be designed to assure that their rupture or inadvertent operation does not significantly impair the safety capability of these structures, systems, and components.
Criterion 4—Environmental and dynamic effects design bases. Structures, systems, and components important to safety shall be designed to accommodate the effects of and to be compatible with the environmental conditions associated with normal operation, maintenance, testing, and postulated accidents, including loss-of-coolant accidents. These structures, systems, and components shall be appropriately protected against dynamic effects, including the effects of missiles, pipe whipping, and discharging fluids, that may result from equipment failures and from events and conditions outside the nuclear power unit. However, dynamic effects associated with postulated pipe ruptures in nuclear power units may be excluded from the design basis when analyses reviewed and approved by the Commission demonstrate that the probability of fluid system piping rupture is extremely low under conditions consistent with the design basis for the piping.
Criterion 5—Sharing of structures, systems, and components. Structures, systems, and components important to safety shall not be shared among nuclear power units unless it can be shown that such sharing will not significantly impair their ability to perform their safety functions, including, in the event of an accident in one unit, an orderly shutdown and cooldown of the remaining units.
II. Protection by Multiple Fission Product Barriers
Criterion 10—Reactor design. The reactor core and associated coolant, control, and protection systems shall be designed with appropriate margin to assure that specified acceptable fuel design limits are not exceeded during any condition of normal operation, including the effects of anticipated operational occurrences.
Criterion 11—Reactor inherent protection. The reactor core and associated coolant systems shall be designed so that in the power operating range the net effect of the prompt inherent nuclear feedback characteristics tends to compensate for a rapid increase in reactivity.
Criterion 12—Suppression of reactor power oscillations. The reactor core and associated coolant, control, and protection systems shall be designed to assure that power oscillations which can result in conditions exceeding specified acceptable fuel design limits are not possible or can be reliably and readily detected and suppressed.
Criterion 13—Instrumentation and control. Instrumentation shall be provided to monitor variables and systems over their anticipated ranges for normal operation, for anticipated operational occurrences, and for accident conditions as appropriate to assure adequate safety, including those variables and systems that can affect the fission process, the integrity of the reactor core, the reactor coolant pressure boundary, and the containment and its associated systems. Appropriate controls shall be provided to maintain these variables and systems within prescribed operating ranges.
Criterion 14—Reactor coolant pressure boundary. The reactor coolant pressure boundary shall be designed, fabricated, erected, and tested so as to have an extremely low probability of abnormal leakage, of rapidly propagating failure, and of gross rupture.
Criterion 15—Reactor coolant system design. The reactor coolant system and associated auxiliary, control, and protection systems shall be designed with sufficient margin to assure that the design conditions of the reactor coolant pressure boundary are not exceeded during any condition of normal operation, including anticipated operational occurrences.
Criterion 16—Containment design. Reactor containment and associated systems shall be provided to establish an essentially leak-tight barrier against the uncontrolled release of radioactivity to the environment and to assure that the containment design conditions important to safety are not exceeded for as long as postulated accident conditions require.
Criterion 17—Electric power systems. An onsite electric power system and an offsite electric power system shall be provided to permit functioning of structures, systems, and components important to safety. The safety function for each system (assuming the other system is not functioning) shall be to provide sufficient capacity and capability to assure that (1) specified acceptable fuel design limits and design conditions of the reactor coolant pressure boundary are not exceeded as a result of anticipated operational occurrences and (2) the core is cooled and containment integrity and other vital functions are maintained in the event of postulated accidents.
The onsite electric power supplies, including the batteries, and the onsite electric distribution system, shall have sufficient independence, redundancy, and testability to perform their safety functions assuming a single failure.
Electric power from the transmission network to the onsite electric distribution system shall be supplied by two physically independent circuits (not necessarily on separate rights of way) designed and located so as to minimize to the extent practical the likelihood of their simultaneous failure under operating and postulated accident and environmental conditions. A switchyard common to both circuits is acceptable. Each of these circuits shall be designed to be available in sufficient time following a loss of all onsite alternating current power supplies and the other offsite electric power circuit, to assure that specified acceptable fuel design limits and design conditions of the reactor coolant pressure boundary are not exceeded. One of these circuits shall be designed to be available within a few seconds following a loss-of-coolant accident to assure that core cooling, containment integrity, and other vital safety functions are maintained.
Provisions shall be included to minimize the probability of losing electric power from any of the remaining supplies as a result of, or coincident with, the loss of power generated by the nuclear power unit, the loss of power from the transmission network, or the loss of power from the onsite electric power supplies.
Criterion 18—Inspection and testing of electric power systems. Electric power systems important to safety shall be designed to permit appropriate periodic inspection and testing of important areas and features, such as wiring, insulation, connections, and switchboards, to assess the continuity of the systems and the condition of their components. The systems shall be designed with a capability to test periodically (1) the operability and functional performance of the components of the systems, such as onsite power sources, relays, switches, and buses, and (2) the operability of the systems as a whole and, under conditions as close to design as practical, the full operation sequence that brings the systems into operation, including operation of applicable portions of the protection system, and the transfer of power among the nuclear power unit, the offsite power system, and the onsite power system.
Criterion 19—Control room. A control room shall be provided from which actions can be taken to operate the nuclear power unit safely under normal conditions and to maintain it in a safe condition under accident conditions, including loss-of-coolant accidents. Adequate radiation protection shall be provided to permit access and occupancy of the control room under accident conditions without personnel receiving radiation exposures in excess of 5 rem whole body, or its equivalent to any part of the body, for the duration of the accident. Equipment at appropriate locations outside the control room shall be provided (1) with a design capability for prompt hot shutdown of the reactor, including necessary instrumentation and controls to maintain the unit in a safe condition during hot shutdown, and (2) with a potential capability for subsequent cold shutdown of the reactor through the use of suitable procedures.
Applicants for and holders of construction permits and operating licenses under this part who apply on or after January 10, 1997, applicants for design approvals or certifications under part 52 of this chapter who apply on or after January 10, 1997, applicants for and holders of combined licenses or manufacturing licenses under part 52 of this chapter who do not reference a standard design approval or certification, or holders of operating licenses using an alternative source term under § 50.67, shall meet the requirements of this criterion, except that with regard to control room access and occupancy, adequate radiation protection shall be provided to ensure that radiation exposures shall not exceed 0.05 Sv (5 rem) total effective dose equivalent (TEDE) as defined in § 50.2 for the duration of the accident.
III. Protection and Reactivity Control Systems
Criterion 20—Protection system functions. The protection system shall be designed (1) to initiate automatically the operation of appropriate systems including the reactivity control systems, to assure that specified acceptable fuel design limits are not exceeded as a result of anticipated operational occurrences and (2) to sense accident conditions and to initiate the operation of systems and components important to safety.
Criterion 21—Protection system reliability and testability. The protection system shall be designed for high functional reliability and inservice testability commensurate with the safety functions to be performed. Redundancy and independence designed into the protection system shall be sufficient to assure that (1) no single failure results in loss of the protection function and (2) removal from service of any component or channel does not result in loss of the required minimum redundancy unless the acceptable reliability of operation of the protection system can be otherwise demonstrated. The protection system shall be designed to permit periodic testing of its functioning when the reactor is in operation, including a capability to test channels independently to determine failures and losses of redundancy that may have occurred.
Criterion 22—Protection system independence. The protection system shall be designed to assure that the effects of natural phenomena, and of normal operating, maintenance, testing, and postulated accident conditions on redundant channels do not result in loss of the protection function, or shall be demonstrated to be acceptable on some other defined basis. Design techniques, such as functional diversity or diversity in component design and principles of operation, shall be used to the extent practical to prevent loss of the protection function.
Criterion 23—Protection system failure modes. The protection system shall be designed to fail into a safe state or into a state demonstrated to be acceptable on some other defined basis if conditions such as disconnection of the system, loss of energy (e.g., electric power, instrument air), or postulated adverse environments (e.g., extreme heat or cold, fire, pressure, steam, water, and radiation) are experienced.
Criterion 24—Separation of protection and control systems. The protection system shall be separated from control systems to the extent that failure of any single control system component or channel, or failure or removal from service of any single protection system component or channel which is common to the control and protection systems leaves intact a system satisfying all reliability, redundancy, and independence requirements of the protection system. Interconnection of the protection and control systems shall be limited so as to assure that safety is not significantly impaired.
Criterion 25—Protection system requirements for reactivity control malfunctions. The protection system shall be designed to assure that specified acceptable fuel design limits are not exceeded for any single malfunction of the reactivity control systems, such as accidental withdrawal (not ejection or dropout) of control rods.
Criterion 26—Reactivity control system redundancy and capability. Two independent reactivity control systems of different design principles shall be provided. One of the systems shall use control rods, preferably including a positive means for inserting the rods, and shall be capable of reliably controlling reactivity changes to assure that under conditions of normal operation, including anticipated operational occurrences, and with appropriate margin for malfunctions such as stuck rods, specified acceptable fuel design limits are not exceeded. The second reactivity control system shall be capable of reliably controlling the rate of reactivity changes resulting from planned, normal power changes (including xenon burnout) to assure acceptable fuel design limits are not exceeded. One of the systems shall be capable of holding the reactor core subcritical under cold conditions.
Criterion 27—Combined reactivity control systems capability. The reactivity control systems shall be designed to have a combined capability, in conjunction with poison addition by the emergency core cooling system, of reliably controlling reactivity changes to assure that under postulated accident conditions and with appropriate margin for stuck rods the capability to cool the core is maintained.
Criterion 28—Reactivity limits. The reactivity control systems shall be designed with appropriate limits on the potential amount and rate of reactivity increase to assure that the effects of postulated reactivity accidents can neither (1) result in damage to the reactor coolant pressure boundary greater than limited local yielding nor (2) sufficiently disturb the core, its support structures or other reactor pressure vessel internals to impair significantly the capability to cool the core. These postulated reactivity accidents shall include consideration of rod ejection (unless prevented by positive means), rod dropout, steam line rupture, changes in reactor coolant temperature and pressure, and cold water addition.
Criterion 29—Protection against anticipated operational occurrences. The protection and reactivity control systems shall be designed to assure an extremely high probability of accomplishing their safety functions in the event of anticipated operational occurrences.
IV. Fluid Systems
Criterion 30—Quality of reactor coolant pressure boundary. Components which are part of the reactor coolant pressure boundary shall be designed, fabricated, erected, and tested to the highest quality standards practical. Means shall be provided for detecting and, to the extent practical, identifying the location of the source of reactor coolant leakage.
Criterion 31—Fracture prevention of reactor coolant pressure boundary. The reactor coolant pressure boundary shall be designed with sufficient margin to assure that when stressed under operating, maintenance, testing, and postulated accident conditions (1) the boundary behaves in a nonbrittle manner and (2) the probability of rapidly propagating fracture is minimized. The design shall reflect consideration of service temperatures and other conditions of the boundary material under operating, maintenance, testing, and postulated accident conditions and the uncertainties in determining (1) material properties, (2) the effects of irradiation on material properties, (3) residual, steady state and transient stresses, and (4) size of flaws.
Criterion 32—Inspection of reactor coolant pressure boundary. Components which are part of the reactor coolant pressure boundary shall be designed to permit (1) periodic inspection and testing of important areas and features to assess their structural and leaktight integrity, and (2) an appropriate material surveillance program for the reactor pressure vessel.
Criterion 33—Reactor coolant makeup. A system to supply reactor coolant makeup for protection against small breaks in the reactor coolant pressure boundary shall be provided. The system safety function shall be to assure that specified acceptable fuel design limits are not exceeded as a result of reactor coolant loss due to leakage from the reactor coolant pressure boundary and rupture of small piping or other small components which are part of the boundary. The system shall be designed to assure that for onsite electric power system operation (assuming offsite power is not available) and for offsite electric power system operation (assuming onsite power is not available) the system safety function can be accomplished using the piping, pumps, and valves used to maintain coolant inventory during normal reactor operation.
Criterion 34—Residual heat removal. A system to remove residual heat shall be provided. The system safety function shall be to transfer fission product decay heat and other residual heat from the reactor core at a rate such that specified acceptable fuel design limits and the design conditions of the reactor coolant pressure boundary are not exceeded.
Suitable redundancy in components and features, and suitable interconnections, leak detection, and isolation capabilities shall be provided to assure that for onsite electric power system operation (assuming offsite power is not available) and for offsite electric power system operation (assuming onsite power is not available) the system safety function can be accomplished, assuming a single failure.
Criterion 35—Emergency core cooling. A system to provide abundant emergency core cooling shall be provided. The system safety function shall be to transfer heat from the reactor core following any loss of reactor coolant at a rate such that (1) fuel and clad damage that could interfere with continued effective core cooling is prevented and (2) clad metal-water reaction is limited to negligible amounts.
Suitable redundancy in components and features, and suitable interconnections, leak detection, isolation, and containment capabilities shall be provided to assure that for onsite electric power system operation (assuming offsite power is not available) and for offsite electric power system operation (assuming onsite power is not available) the system safety function can be accomplished, assuming a single failure.
Criterion 36—Inspection of emergency core cooling system. The emergency core cooling system shall be designed to permit appropriate periodic inspection of important components, such as spray rings in the reactor pressure vessel, water injection nozzles, and piping, to assure the integrity and capability of the system.
Criterion 37—Testing of emergency core cooling system. The emergency core cooling system shall be designed to permit appropriate periodic pressure and functional testing to assure (1) the structural and leaktight integrity of its components, (2) the operability and performance of the active components of the system, and (3) the operability of the system as a whole and, under conditions as close to design as practical, the performance of the full operational sequence that brings the system into operation, including operation of applicable portions of the protection system, the transfer between normal and emergency power sources, and the operation of the associated cooling water system.
Criterion 38—Containment heat removal. A system to remove heat from the reactor containment shall be provided. The system safety function shall be to reduce rapidly, consistent with the functioning of other associated systems, the containment pressure and temperature following any loss-of-coolant accident and maintain them at acceptably low levels.
Suitable redundancy in components and features, and suitable interconnections, leak detection, isolation, and containment capabilities shall be provided to assure that for onsite electric power system operation (assuming offsite power is not available) and for offsite electric power system operation (assuming onsite power is not available) the system safety function can be accomplished, assuming a single failure.
Criterion 39—Inspection of containment heat removal system. The containment heat removal system shall be designed to permit appropriate periodic inspection of important components, such as the torus, sumps, spray nozzles, and piping to assure the integrity and capability of the system.
Criterion 40—Testing of containment heat removal system. The containment heat removal system shall be designed to permit appropriate periodic pressure and functional testing to assure (1) the structural and leaktight integrity of its components, (2) the operability and performance of the active components of the system, and (3) the operability of the system as a whole, and under conditions as close to the design as practical the performance of the full operational sequence that brings the system into operation, including operation of applicable portions of the protection system, the transfer between normal and emergency power sources, and the operation of the associated cooling water system.
Criterion 41—Containment atmosphere cleanup. Systems to control fission products, hydrogen, oxygen, and other substances which may be released into the reactor containment shall be provided as necessary to reduce, consistent with the functioning of other associated systems, the concentration and quality of fission products released to the environment following postulated accidents, and to control the concentration of hydrogen or oxygen and other substances in the containment atmosphere following postulated accidents to assure that containment integrity is maintained.
Each system shall have suitable redundancy in components and features, and suitable interconnections, leak detection, isolation, and containment capabilities to assure that for onsite electric power system operation (assuming offsite power is not available) and for offsite electric power system operation (assuming onsite power is not available) its safety function can be accomplished, assuming a single failure.
Criterion 42—Inspection of containment atmosphere cleanup systems. The containment atmosphere cleanup systems shall be designed to permit appropriate periodic inspection of important components, such as filter frames, ducts, and piping to assure the integrity and capability of the systems.
Criterion 43—Testing of containment atmosphere cleanup systems. The containment atmosphere cleanup systems shall be designed to permit appropriate periodic pressure and functional testing to assure (1) the structural and leaktight integrity of its components, (2) the operability and performance of the active components of the systems such as fans, filters, dampers, pumps, and valves and (3) the operability of the systems as a whole and, under conditions as close to design as practical, the performance of the full operational sequence that brings the systems into operation, including operation of applicable portions of the protection system, the transfer between normal and emergency power sources, and the operation of associated systems.
Criterion 44—Cooling water. A system to transfer heat from structures, systems, and components important to safety, to an ultimate heat sink shall be provided. The system safety function shall be to transfer the combined heat load of these structures, systems, and components under normal operating and accident conditions.
Suitable redundancy in components and features, and suitable interconnections, leak detection, and isolation capabilities shall be provided to assure that for onsite electric power system operation (assuming offsite power is not available) and for offsite electric power system operation (assuming onsite power is not available) the system safety function can be accomplished, assuming a single failure.
Criterion 45—Inspection of cooling water system. The cooling water system shall be designed to permit appropriate periodic inspection of important components, such as heat exchangers and piping, to assure the integrity and capability of the system.
Criterion 46—Testing of cooling water system. The cooling water system shall be designed to permit appropriate periodic pressure and functional testing to assure (1) the structural and leaktight integrity of its components, (2) the operability and the performance of the active components of the system, and (3) the operability of the system as a whole and, under conditions as close to design as practical, the performance of the full operational sequence that brings the system into operation for reactor shutdown and for loss-of-coolant accidents, including operation of applicable portions of the protection system and the transfer between normal and emergency power sources.
V. Reactor Containment
Criterion 50—Containment design basis. The reactor containment structure, including access openings, penetrations, and the containment heat removal system shall be designed so that the containment structure and its internal compartments can accommodate, without exceeding the design leakage rate and with sufficient margin, the calculated pressure and temperature conditions resulting from any loss-of-coolant accident. This margin shall reflect consideration of (1) the effects of potential energy sources which have not been included in the determination of the peak conditions, such as energy in steam generators and as required by § 50.44 energy from metal-water and other chemical reactions that may result from degradation but not total failure of emergency core cooling functioning, (2) the limited experience and experimental data available for defining accident phenomena and containment responses, and (3) the conservatism of the calculational model and input parameters.
Criterion 51—Fracture prevention of containment pressure boundary. The reactor containment boundary shall be designed with sufficient margin to assure that under operating, maintenance, testing, and postulated accident conditions (1) its ferritic materials behave in a nonbrittle manner and (2) the probability of rapidly propagating fracture is minimized. The design shall reflect consideration of service temperatures and other conditions of the containment boundary material during operation, maintenance, testing, and postulated accident conditions, and the uncertainties in determining (1) material properties, (2) residual, steady state, and transient stresses, and (3) size of flaws.
Criterion 52—Capability for containment leakage rate testing. The reactor containment and other equipment which may be subjected to containment test conditions shall be designed so that periodic integrated leakage rate testing can be conducted at containment design pressure.
Criterion 53—Provisions for containment testing and inspection. The reactor containment shall be designed to permit (1) appropriate periodic inspection of all important areas, such as penetrations, (2) an appropriate surveillance program, and (3) periodic testing at containment design pressure of the leaktightness of penetrations which have resilient seals and expansion bellows.
Criterion 54—Piping systems penetrating containment. Piping systems penetrating primary reactor containment shall be provided with leak detection, isolation, and containment capabilities having redundancy, reliability, and performance capabilities which reflect the importance to safety of isolating these piping systems. Such piping systems shall be designed with a capability to test periodically the operability of the isolation valves and associated apparatus and to determine if valve leakage is within acceptable limits.
Criterion 55—Reactor coolant pressure boundary penetrating containment. Each line that is part of the reactor coolant pressure boundary and that penetrates primary reactor containment shall be provided with containment isolation valves as follows, unless it can be demonstrated that the containment isolation provisions for a specific class of lines, such as instrument lines, are acceptable on some other defined basis:
(1) One locked closed isolation valve inside and one locked closed isolation valve outside containment; or
(2) One automatic isolation valve inside and one locked closed isolation valve outside containment; or
(3) One locked closed isolation valve inside and one automatic isolation valve outside containment. A simple check valve may not be used as the automatic isolation valve outside containment; or
(4) One automatic isolation valve inside and one automatic isolation valve outside containment. A simple check valve may not be used as the automatic isolation valve outside containment.
Isolation valves outside containment shall be located as close to containment as practical and upon loss of actuating power, automatic isolation valves shall be designed to take the position that provides greater safety.
Other appropriate requirements to minimize the probability or consequences of an accidental rupture of these lines or of lines connected to them shall be provided as necessary to assure adequate safety. Determination of the appropriateness of these requirements, such as higher quality in design, fabrication, and testing, additional provisions for inservice inspection, protection against more severe natural phenomena, and additional isolation valves and containment, shall include consideration of the population density, use characteristics, and physical characteristics of the site environs.
Criterion 56—Primary containment isolation. Each line that connects directly to the containment atmosphere and penetrates primary reactor containment shall be provided with containment isolation valves as follows, unless it can be demonstrated that the containment isolation provisions for a specific class of lines, such as instrument lines, are acceptable on some other defined basis:
(1) One locked closed isolation valve inside and one locked closed isolation valve outside containment; or
(2) One automatic isolation valve inside and one locked closed isolation valve outside containment; or
(3) One locked closed isolation valve inside and one automatic isolation valve outside containment. A simple check valve may not be used as the automatic isolation valve outside containment; or
(4) One automatic isolation valve inside and one automatic isolation valve outside containment. A simple check valve may not be used as the automatic isolation valve outside containment.
Isolation valves outside containment shall be located as close to the containment as practical and upon loss of actuating power, automatic isolation valves shall be designed to take the position that provides greater safety.
Criterion 57—Closed system isolation valves. Each line that penetrates primary reactor containment and is neither part of the reactor coolant pressure boundary nor connected directly to the containment atmosphere shall have at least one containment isolation valve which shall be either automatic, or locked closed, or capable of remote manual operation. This valve shall be outside containment and located as close to the containment as practical. A simple check valve may not be used as the automatic isolation valve.
VI. Fuel and Radioactivity Control
Criterion 60—Control of releases of radioactive materials to the environment. The nuclear power unit design shall include means to control suitably the release of radioactive materials in gaseous and liquid effluents and to handle radioactive solid wastes produced during normal reactor operation, including anticipated operational occurrences. Sufficient holdup capacity shall be provided for retention of gaseous and liquid effluents containing radioactive materials, particularly where unfavorable site environmental conditions can be expected to impose unusual operational limitations upon the release of such effluents to the environment.
Criterion 61—Fuel storage and handling and radioactivity control. The fuel storage and handling, radioactive waste, and other systems which may contain radioactivity shall be designed to assure adequate safety under normal and postulated accident conditions. These systems shall be designed (1) with a capability to permit appropriate periodic inspection and testing of components important to safety, (2) with suitable shielding for radiation protection, (3) with appropriate containment, confinement, and filtering systems, (4) with a residual heat removal capability having reliability and testability that reflects the importance to safety of decay heat and other residual heat removal, and (5) to prevent significant reduction in fuel storage coolant inventory under accident conditions.
Criterion 62—Prevention of criticality in fuel storage and handling. Criticality in the fuel storage and handling system shall be prevented by physical systems or processes, preferably by use of geometrically safe configurations.
Criterion 63—Monitoring fuel and waste storage. Appropriate systems shall be provided in fuel storage and radioactive waste systems and associated handling areas (1) to detect conditions that may result in loss of residual heat removal capability and excessive radiation levels and (2) to initiate appropriate safety actions.
Criterion 64—Monitoring radioactivity releases. Means shall be provided for monitoring the reactor containment atmosphere, spaces containing components for recirculation of loss-of-coolant accident fluids, effluent discharge paths, and the plant environs for radioactivity that may be released from normal operations, including anticipated operational occurrences, and from postulated accidents.

91
data/regs/10-cfr-50-app-b.txt Normal file
View file

@ -0,0 +1,91 @@
Appendix B to Part 50—Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants
Introduction. Every applicant for a construction permit is required by the provisions of § 50.34 to include in its preliminary safety analysis report a description of the quality assurance program to be applied to the design, fabrication, construction, and testing of the structures, systems, and components of the facility. Every applicant for an operating license is required to include, in its final safety analysis report, information pertaining to the managerial and administrative controls to be used to assure safe operation. Every applicant for a combined license under part 52 of this chapter is required by the provisions of § 52.79 of this chapter to include in its final safety analysis report a description of the quality assurance applied to the design, and to be applied to the fabrication, construction, and testing of the structures, systems, and components of the facility and to the managerial and administrative controls to be used to assure safe operation. For applications submitted after September 27, 2007, every applicant for an early site permit under part 52 of this chapter is required by the provisions of § 52.17 of this chapter to include in its site safety analysis report a description of the quality assurance program applied to site activities related to the design, fabrication, construction, and testing of the structures, systems, and components of a facility or facilities that may be constructed on the site. Every applicant for a design approval or design certification under part 52 of this chapter is required by the provisions of 10 CFR 52.137 and 52.47, respectively, to include in its final safety analysis report a description of the quality assurance program applied to the design of the structures, systems, and components of the facility. Every applicant for a manufacturing license under part 52 of this chapter is required by the provisions of 10 CFR 52.157 to include in its final safety analysis report a description of the quality assurance program applied to the design, and to be applied to the manufacture of, the structures, systems, and components of the reactor. Nuclear power plants and fuel reprocessing plants include structures, systems, and components that prevent or mitigate the consequences of postulated accidents that could cause undue risk to the health and safety of the public. This appendix establishes quality assurance requirements for the design, manufacture, construction, and operation of those structures, systems, and components. The pertinent requirements of this appendix apply to all activities affecting the safety-related functions of those structures, systems, and components; these activities include designing, purchasing, fabricating, handling, shipping, storing, cleaning, erecting, installing, inspecting, testing, operating, maintaining, repairing, refueling, and modifying.
As used in this appendix, "quality assurance" comprises all those planned and systematic actions necessary to provide adequate confidence that a structure, system, or component will perform satisfactorily in service. Quality assurance includes quality control, which comprises those quality assurance actions related to the physical characteristics of a material, structure, component, or system which provide a means to control the quality of the material, structure, component, or system to predetermined requirements.
I. Organization
The applicant 1 shall be responsible for the establishment and execution of the quality assurance program. The applicant may delegate to others, such as contractors, agents, or consultants, the work of establishing and executing the quality assurance program, or any part thereof, but shall retain responsibility for the quality assurance program. The authority and duties of persons and organizations performing activities affecting the safety-related functions of structures, systems, and components shall be clearly established and delineated in writing. These activities include both the performing functions of attaining quality objectives and the quality assurance functions. The quality assurance functions are those of (1) assuring that an appropriate quality assurance program is established and effectively executed; and (2) verifying, such as by checking, auditing, and inspecting, that activities affecting the safety-related functions have been correctly performed. The persons and organizations performing quality assurance functions shall have sufficient authority and organizational freedom to identify quality problems; to initiate, recommend, or provide solutions; and to verify implementation of solutions. The persons and organizations performing quality assurance functions shall report to a management level so that the required authority and organizational freedom, including sufficient independence from cost and schedule when opposed to safety considerations, are provided. Because of the many variables involved, such as the number of personnel, the type of activity being performed, and the location or locations where activities are performed, the organizational structure for executing the quality assurance program may take various forms, provided that the persons and organizations assigned the quality assurance functions have the required authority and organizational freedom. Irrespective of the organizational structure, the individual(s) assigned the responsibility for assuring effective execution of any portion of the quality assurance program at any location where activities subject to this appendix are being performed, shall have direct access to the levels of management necessary to perform this function.
II. Quality Assurance Program
The applicant shall establish at the earliest practicable time, consistent with the schedule for accomplishing the activities, a quality assurance program which complies with the requirements of this appendix. This program shall be documented by written policies, procedures, or instructions and shall be carried out throughout plant life in accordance with those policies, procedures, or instructions. The applicant shall identify the structures, systems, and components to be covered by the quality assurance program and the major organizations participating in the program, together with the designated functions of these organizations. The quality assurance program shall provide control over activities affecting the quality of the identified structures, systems, and components, to an extent consistent with their importance to safety. Activities affecting quality shall be accomplished under suitably controlled conditions. Controlled conditions include the use of appropriate equipment; suitable environmental conditions for accomplishing the activity, such as adequate cleanness; and assurance that all prerequisites for the given activity have been satisfied. The program shall take into account the need for special controls, processes, test equipment, tools, and skills to attain the required quality, and the need for verification of quality by inspection and test. The program shall provide for indoctrination and training of personnel performing activities affecting quality as necessary to assure that suitable proficiency is achieved and maintained. The applicant shall regularly review the status and adequacy of the quality assurance program. Management of other organizations participating in the quality assurance program shall regularly review the status and adequacy of that part of the quality assurance program which they are executing.
III. Design Control
Measures shall be established to assure that applicable regulatory requirements and the design basis, as defined in § 50.2 and as specified in the license application, for those structures, systems, and components to which this appendix applies are correctly translated into specifications, drawings, procedures, and instructions. These measures shall include provisions to assure that appropriate quality standards are specified and included in design documents and that deviations from such standards are controlled. Measures shall also be established for the selection and review for suitability of application of materials, parts, equipment, and processes that are essential to the safety-related functions of the structures, systems and components.
Measures shall be established for the identification and control of design interfaces and for coordination among participating design organizations. These measures shall include the establishment of procedures among participating design organizations for the review, approval, release, distribution, and revision of documents involving design interfaces.
The design control measures shall provide for verifying or checking the adequacy of design, such as by the performance of design reviews, by the use of alternate or simplified calculational methods, or by the performance of a suitable testing program. The verifying or checking process shall be performed by individuals or groups other than those who performed the original design, but who may be from the same organization. Where a test program is used to verify the adequacy of a specific design feature in lieu of other verifying or checking processes, it shall include suitable qualifications testing of a prototype unit under the most adverse design conditions. Design control measures shall be applied to items such as the following: reactor physics, stress, thermal, hydraulic, and accident analyses; compatibility of materials; accessibility for inservice inspection, maintenance, and repair; and delineation of acceptance criteria for inspections and tests.
Design changes, including field changes, shall be subject to design control measures commensurate with those applied to the original design and be approved by the organization that performed the original design unless the applicant designates another responsible organization.
IV. Procurement Document Control
Measures shall be established to assure that applicable regulatory requirements, design bases, and other requirements which are necessary to assure adequate quality are suitably included or referenced in the documents for procurement of material, equipment, and services, whether purchased by the applicant or by its contractors or subcontractors. To the extent necessary, procurement documents shall require contractors or subcontractors to provide a quality assurance program consistent with the pertinent provisions of this appendix.
V. Instructions, Procedures, and Drawings
Activities affecting quality shall be prescribed by documented instructions, procedures, or drawings, of a type appropriate to the circumstances and shall be accomplished in accordance with these instructions, procedures, or drawings. Instructions, procedures, or drawings shall include appropriate quantitative or qualitative acceptance criteria for determining that important activities have been satisfactorily accomplished.
VI. Document Control
Measures shall be established to control the issuance of documents, such as instructions, procedures, and drawings, including changes thereto, which prescribe all activities affecting quality. These measures shall assure that documents, including changes, are reviewed for adequacy and approved for release by authorized personnel and are distributed to and used at the location where the prescribed activity is performed. Changes to documents shall be reviewed and approved by the same organizations that performed the original review and approval unless the applicant designates another responsible organization.
VII. Control of Purchased Material, Equipment, and Services
Measures shall be established to assure that purchased material, equipment, and services, whether purchased directly or through contractors and subcontractors, conform to the procurement documents. These measures shall include provisions, as appropriate, for source evaluation and selection, objective evidence of quality furnished by the contractor or subcontractor, inspection at the contractor or subcontractor source, and examination of products upon delivery. Documentary evidence that material and equipment conform to the procurement requirements shall be available at the nuclear powerplant or fuel reprocessing plant site prior to installation or use of such material and equipment. This documentary evidence shall be retained at the nuclear powerplant or fuel reprocessing plant site and shall be sufficient to identify the specific requirements, such as codes, standards, or specifications, met by the purchased material and equipment. The effectiveness of the control of quality by contractors and subcontractors shall be assessed by the applicant or designee at intervals consistent with the importance, complexity, and quantity of the product or services.
VIII. Identification and Control of Materials, Parts, and Components
Measures shall be established for the identification and control of materials, parts, and components, including partially fabricated assemblies. These measures shall assure that identification of the item is maintained by heat number, part number, serial number, or other appropriate means, either on the item or on records traceable to the item, as required throughout fabrication, erection, installation, and use of the item. These identification and control measures shall be designed to prevent the use of incorrect or defective material, parts, and components.
IX. Control of Special Processes
Measures shall be established to assure that special processes, including welding, heat treating, and nondestructive testing, are controlled and accomplished by qualified personnel using qualified procedures in accordance with applicable codes, standards, specifications, criteria, and other special requirements.
X. Inspection
A program for inspection of activities affecting quality shall be established and executed by or for the organization performing the activity to verify conformance with the documented instructions, procedures, and drawings for accomplishing the activity. Such inspection shall be performed by individuals other than those who performed the activity being inspected. Examinations, measurements, or tests of material or products processed shall be performed for each work operation where necessary to assure quality. If inspection of processed material or products is impossible or disadvantageous, indirect control by monitoring processing methods, equipment, and personnel shall be provided. Both inspection and process monitoring shall be provided when control is inadequate without both. If mandatory inspection hold points, which require witnessing or inspecting by the applicant's designated representative and beyond which work shall not proceed without the consent of its designated representative are required, the specific hold points shall be indicated in appropriate documents.
XI. Test Control
A test program shall be established to assure that all testing required to demonstrate that structures, systems, and components will perform satisfactorily in service is identified and performed in accordance with written test procedures which incorporate the requirements and acceptance limits contained in applicable design documents. The test program shall include, as appropriate, proof tests prior to installation, preoperational tests, and operational tests during nuclear power plant or fuel reprocessing plant operation, of structures, systems, and components. Test procedures shall include provisions for assuring that all prerequisites for the given test have been met, that adequate test instrumentation is available and used, and that the test is performed under suitable environmental conditions. Test results shall be documented and evaluated to assure that test requirements have been satisfied.
XII. Control of Measuring and Test Equipment
Measures shall be established to assure that tools, gages, instruments, and other measuring and testing devices used in activities affecting quality are properly controlled, calibrated, and adjusted at specified periods to maintain accuracy within necessary limits.
XIII. Handling, Storage and Shipping
Measures shall be established to control the handling, storage, shipping, cleaning and preservation of material and equipment in accordance with work and inspection instructions to prevent damage or deterioration. When necessary for particular products, special protective environments, such as inert gas atmosphere, specific moisture content levels, and temperature levels, shall be specified and provided.
XIV. Inspection, Test, and Operating Status
Measures shall be established to indicate, by the use of markings such as stamps, tags, labels, routing cards, or other suitable means, the status of inspections and tests performed upon individual items of the nuclear power plant or fuel reprocessing plant. These measures shall provide for the identification of items which have satisfactorily passed required inspections and tests, where necessary to preclude inadvertent bypassing of such inspections and tests. Measures shall also be established for indicating the operating status of structures, systems, and components of the nuclear power plant or fuel reprocessing plant, such as by tagging valves and switches, to prevent inadvertent operation.
XV. Nonconforming Materials, Parts, or Components
Measures shall be established to control materials, parts, or components which do not conform to requirements in order to prevent their inadvertent use or installation. These measures shall include, as appropriate, procedures for identification, documentation, segregation, disposition, and notification to affected organizations. Nonconforming items shall be reviewed and accepted, rejected, repaired or reworked in accordance with documented procedures.
XVI. Corrective Action
Measures shall be established to assure that conditions adverse to quality, such as failures, malfunctions, deficiencies, deviations, defective material and equipment, and nonconformances are promptly identified and corrected. In the case of significant conditions adverse to quality, the measures shall assure that the cause of the condition is determined and corrective action taken to preclude repetition. The identification of the significant condition adverse to quality, the cause of the condition, and the corrective action taken shall be documented and reported to appropriate levels of management.
XVII. Quality Assurance Records
Sufficient records shall be maintained to furnish evidence of activities affecting quality. The records shall include at least the following: Operating logs and the results of reviews, inspections, tests, audits, monitoring of work performance, and materials analyses. The records shall also include closely-related data such as qualifications of personnel, procedures, and equipment. Inspection and test records shall, as a minimum, identify the inspector or data recorder, the type of observation, the results, the acceptability, and the action taken in connection with any deficiencies noted. Records shall be identifiable and retrievable. Consistent with applicable regulatory requirements, the applicant shall establish requirements concerning record retention, such as duration, location, and assigned responsibility.
XVIII. Audits
A comprehensive system of planned and periodic audits shall be carried out to verify compliance with all aspects of the quality assurance program and to determine the effectiveness of the program. The audits shall be performed in accordance with the written procedures or check lists by appropriately trained personnel not having direct responsibilities in the areas being audited. Audit results shall be documented and reviewed by management having responsibility in the area audited. Followup action, including reaudit of deficient areas, shall be taken where indicated.
1 While the term "applicant" is used in these criteria, the requirements are, of course, applicable after such a person has received a license to construct and operate a nuclear power plant or a fuel reprocessing plant or has received an early site permit, design approval, design certification, or manufacturing license, as applicable. These criteria will also be used for guidance in evaluating the adequacy of quality assurance programs in use by holders of construction permits, operating licenses, early site permits, design approvals, combined licenses, and manufacturing licenses.
[35 FR 10499, June 27, 1970, as amended at 36 FR 18301, Sept. 11, 1971; 40 FR 3210D, Jan. 20, 1975; 72 FR 49505, Aug. 28, 2007; 84 FR 63568, Nov. 18, 2019]
Page Last Reviewed/Updated Monday, June 14, 2021

20
documents/Makefile Normal file
View file

@ -0,0 +1,20 @@
# Minimal makefile for Sphinx documentation
#
# You can set these variables from the command line, and also
# from the environment for the first two.
SPHINXOPTS ?=
SPHINXBUILD ?= sphinx-build
SOURCEDIR = .
BUILDDIR = build
# Put it first so that "make" without argument is like "make help".
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

10
documents/_data/systems.yaml Normal file
View file

@ -0,0 +1,10 @@
---
rmdc-systems:
- name: NukeVault
description: Specialized commercial records management system
use-cases: Storing Documents and Records generated during design of Project X
location: https://nukevault.opennucleonics.org
- name: Supplier Portal
description: A place where our suppliers can get documents
use-cases: External suppliers send documents/records to us
location: Online

14
documents/_static/css/custom.css Normal file
View file

@ -0,0 +1,14 @@
/*
Add brand colors here
See also: https://pydata-sphinx-theme.readthedocs.io/en/stable/user_guide/styling.html#color-variables
*/
html[data-theme="light"] {
--pst-color-primary: rgb(126, 3, 3);
--pst-color-secondary: rgb(218, 2, 2);
}
html[data-theme="dark"] {
--pst-color-primary: rgb(115, 199, 164);
--pst-color-secondary: rgb(21, 197, 124);
}

BIN
documents/_static/favicon.ico Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 1.4 KiB

BIN
documents/_static/logo.png Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 84 KiB

7
documents/bibliography.rst Normal file
View file

@ -0,0 +1,7 @@
.. only:: html
############
Bibliography
############
.. bibliography::

136
documents/conf.py Normal file
View file

@ -0,0 +1,136 @@
# Configuration file for the Sphinx documentation builder.
#
# This file only contains a selection of the most common options. For a full
# list see the documentation:
# https://www.sphinx-doc.org/en/master/usage/configuration.html
# -- Path setup --------------------------------------------------------------
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#
# import os
# import sys
# sys.path.insert(0, os.path.abspath('.'))
import datetime
# -- Project information -----------------------------------------------------
company_name = "Open Nucleonics"
project = f"{company_name} Governing Documents"
author = company_name
release = "1.0"
version = release
project_copyright = f"{datetime.datetime.now(tz=datetime.timezone.utc).year}"
description = f"Procedures, Forms, Templates that govern work at {company_name}"
# -- General configuration ---------------------------------------------------
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
"sphinxcontrib.plantuml",
"sphinx_needs",
"myst_parser",
"sphinxcontrib.bibtex",
"sphinxcontrib.glossaryused",
"sphinx.ext.imgmath",
"sphinxcontrib.datatemplates",
"sphinxcontrib.mermaid",
"sphinx.ext.graphviz",
# "sphinx.ext.imgconverter", # SVG to png but rasterizes and bad
"sphinxcontrib.inkscapeconverter", # SVG to pdf without rasterizing
"sphinx_timeline",
]
# Add any paths that contain templates here, relative to this directory.
templates_path = ["_templates"]
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path.
exclude_patterns = []
# -- Options for HTML output -------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
#
html_theme = "sphinx_book_theme"
html_title = f"{project} {release}"
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ["_static"]
html_logo = "_static/logo.png"
html_favicon = "_static/favicon.ico"
html_theme_options = {
"logo": {
"text": html_title,
# "image_light": "_static/logo-light.png",
# "image_dark": "_static/logo-dark.png",
}
}
html_css_files = [
"css/custom.css",
]
# system-specific plantuml config
# https://sphinx-needs.readthedocs.io/en/latest/installation.html#plantuml-support
plantuml = "java -Djava.awt.headless=true -jar /usr/share/plantuml/plantuml.jar"
# LaTeX document generation options
# doesn't work with sphinx-needs
latex_documents = [
(
"index",
"nrsk.tex",
"Nuclear Reactor Starter Kit",
author,
"manual",
False,
),
]
# (
# "org/qapd",
# "qapd.tex",
# "Quality Assurance Program Description",
# author,
# "howto",
# False,
# ),
# (
# "proc/calc",
# "proc_calc.tex",
# "Engineering Calculation Procedure",
# author,
# "howto",
# False,
# ),
# (
# "proc/software",
# "proc_software.tex",
# "Software Management Procedure",
# author,
# "howto",
# False,
# ),
# ]
rst_prolog = f"""
.. |inst| replace:: **{company_name}**
"""
# will need to move relevant refs somewhere
# more reusable, like into the repo?
bibtex_bibfiles = ["/pool/Reading/refs.bib"]
mermaid_cmd = "./node_modules/.bin/mmdc"
# enable pdf cropping of mermaid diagrams for fit
mermaid_pdfcrop = "/usr/bin/pdfcrop"
mermaid_version = "10.6.1"
# Sphinx Needs config
needs_include_needs = True # turn off to hide all needs (e.g. for working docs)

27
documents/glossary.rst Normal file
View file

@ -0,0 +1,27 @@
.. need to design a way to bring in multiple glossary data sources
so that we can use the global shared glossary + our project
specific glossary
#########
Glossary
#########
Glossary
.. glossary::
Document
A written collection of information, instructions, drawings,
specifications, etc. that is *maintained* throughout the
design/operation/decommissioning of the facility. Differs from a
*record* in that it is expected to be *maintained* by revisions as
needed. See :need:`R_APPB_45`
Record
A written collection of information providing evidence of
work that was done at a specific time. Records are expected
to be *retained* for a certain retention period, e.g.
for the lifetime of the plant or for a given number of years.
See :need:`R_APPB_79`

22
documents/index.rst Normal file
View file

@ -0,0 +1,22 @@
|inst| Governing Documents
===============================
.. toctree::
:maxdepth: 2
:numbered:
:caption: Contents:
purpose/index
organization/index
procedures/index
bibliography
requirements/index
glossary
Indices and tables
==================
* :ref:`genindex`
* :ref:`search`

35
documents/make.bat Normal file
View file

@ -0,0 +1,35 @@
@ECHO OFF
pushd %~dp0
REM Command file for Sphinx documentation
if "%SPHINXBUILD%" == "" (
set SPHINXBUILD=sphinx-build
)
set SOURCEDIR=.
set BUILDDIR=build
if "%1" == "" goto help
%SPHINXBUILD% >NUL 2>NUL
if errorlevel 9009 (
echo.
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
echo.installed, then set the SPHINXBUILD environment variable to point
echo.to the full path of the 'sphinx-build' executable. Alternatively you
echo.may add the Sphinx directory to PATH.
echo.
echo.If you don't have Sphinx installed, grab it from
echo.https://www.sphinx-doc.org/
exit /b 1
)
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
goto end
:help
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
:end
popd

8
documents/organization/index.rst Normal file
View file

@ -0,0 +1,8 @@
############
Organization
############
.. toctree::
organization
qapd

56
documents/organization/org_chart.dot Normal file
View file

@ -0,0 +1,56 @@
digraph G {
compound=true
graph [splines=ortho, nodesep=0.2]
subgraph clusterBoard{
chairman [label="Chairman"];
board1
board2
board3
}
subgraph clusterTop {
vision [label="Vision"]
values [label="Values"]
objectives [label="Objectives"]
}
chairman -> values [ltail=clusterBoard,lhead=clusterTop]
subgraph clusterCsuite{
CEO [label="Chief\nExecutive\nOfficer"]
COO [label="Chief\nOperations\nOfficer"]
CTO [label="Chief\nTechnology\nOfficer"]
CFO [label="Chief\nFinancial\nOfficer"]
CIO [label="Chief\nInformation\nOfficer"]
CCO [label="Chief\nCompliance\nOfficer"]
CEO -> {CFO, CTO, CIO, COO, CCO}
}
Finance [shape=box];
Engineering [shape=box];
RD [label="Research &\nDevelopment",shape=box];
Operations [shape=box];
PM [label="Project\nManagement",shape=box];
HR [label="Human\nResources",shape=box];
Licensing [shape=box];
CFO -> Finance;
CTO -> {Engineering,RD};
CIO -> PM;
COO -> {Operations,HR};
CCO -> {Licensing};
values -> CEO [ltail=clusterTop,lhead=clusterCsuite]
subgraph clusterIT{
infra [label="Infrastructure"]
help [label="Helpdesk"]
hpc [label="High Performance\nComputing"]
dev [label="Software\nDevelopment"]
label="IT"
}
CIO -> hpc [ltail=clusterTop,lhead=clusterIT]
}

16
documents/organization/organization.rst Normal file
View file

@ -0,0 +1,16 @@
**********************
Organization Structure
**********************
.. _org-chart:
Organization Chart
==================
Org chart should show:
* Job Titles
* Departments
* Authorities
.. graphviz:: org_chart.dot

21
documents/organization/qapd.rst Normal file
View file

@ -0,0 +1,21 @@
*************************************
Quality Assurance Program Description
*************************************
Basis
-----
This document is implemented to satisfy the linked requirements shown below.
.. impl:: Issue a Quality Assurance Program Description
:id: I_QAPD
:links: R_APPB_1,R_APPB_3,R_APPB_4,R_APPB_5,R_APPB_6
:duration: 25
:completion: 0
:collapse: true
.. needflow:: Basis for this document
:filter: "I_QAPD" in links
We are going to do a lot of high quality work in our program, I swear!
.. note:: See NEI 11-04 and 06-14A for generic QAPD templates!

60
documents/procedures/administration/corrective_action.rst Normal file
View file

@ -0,0 +1,60 @@
Corrective Action Procedure
---------------------------
.. impl:: Maintain a Corrective Action Procedure
:links: R_APPB_76
Since Corrective Actions are directly mentioned in AppB, it's wise
to have a very clear and direct procedure defining how it will
be done.
Measures shall be established to assure that conditions adverse to quality, such
as failures, malfunctions, deficiencies, deviations, defective material and
equipment, and nonconformances are promptly identified and corrected.
Corrective Actions are designed to assure that conditions adverse to quality
are promptly identified and corrected. Such conditions may include:
* Failures
* Malfunctions
* Deficiencies
* Deviations
* Defective material
* Defective equipment
* Nonconformances
.. graphviz::
digraph G {
Anyone [label="Anyone",color=green,shape=circle]
Identify [label="Identify condition \nadverse to quality",shape=box];
Create [label="Create CAQ ticket",shape=box];
Notify;
Classify [label="Classify significance"];
Significant [label="Significant condition\n adverse to quality?",shape=diamond]
Cause [label="Determine the cause"];
Preclude [label="Do Corrective Actions \nto preclude repetition"];
Stop [label="Close ticket\n and stop",color=red,shape=circle];
Document [shape=house];
DCause [label="Document cause \nof condition",shape=note];
Action [label="Document actions\ntaken",shape=note];
Report [label="Report to \nappropriate management"];
Anyone -> Identify -> Create -> Notify -> Classify -> Significant;
Significant -> Cause [label="Yes"];
Cause -> Preclude -> Document;
Document -> {DCause, Action} -> Report -> Stop;
Significant -> Stop [label="No"];
}
In the case of significant conditions adverse to quality, the measures shall
assure that the cause of the condition is determined and corrective action taken
to preclude repetition.
The identification of the significant condition adverse to quality, the cause of
the condition, and the corrective action taken shall be documented and reported
to appropriate levels of management.

16
documents/procedures/administration/doc-types.yaml Normal file
View file

@ -0,0 +1,16 @@
- name: Calculation
abbrev: CALC
use-cases: Documenting an analysis
record: False
retention: Varies
- name: Procedure
abbrev: PROC
use-cases: Defining and dictating how work is done
record: False
retention: Lifetime
- name: Form
abbrev: FORM
use-cases: Providing evidence of tasks that were done
record: True
retention: Lifetime

98
documents/procedures/administration/document_management.rst Normal file
View file

@ -0,0 +1,98 @@
Records and Document Management Procedure
-----------------------------------------
This procedure governs the creation, maintenance, and retention of
:term:`Records <Record>` and :term:`Documents <Document>`.
.. impl:: Define processes for lifetime records
:links: R_GDC_1_4
.. impl:: Define processes for Document Control
:links: R_APPB_45
.. impl:: Define processes for Quality Records
:links: R_APPB_79
.. _rmdc-systems:
Systems
^^^^^^^
Documents and records are managed in the following systems.
.. datatemplate:yaml::
:source: /_data/systems.yaml
{{ make_list_table_from_mappings(
[('Name', 'name'), ('Use case(s)', 'use-cases'), ('Location', 'location')],
data['rmdc-systems'],
title='RMDC Systems',
) }}
.. _rmdc-origination:
Origination
^^^^^^^^^^^
New records and new or revised documents are originated as invoked by other procedures
and processes. The following steps shall be taken at such times:
* **Originator** shall specify key data defining the new record/document, including:
* Required:
* Title --- a single-line description of what the record/document is
* Record/document type --- This determines template, review, and
retention rules. Should be from :ref:`rmdc-doctypes`
* Originating organization --- the organization or group assigned primary authorship.
Internally-generated records/documents shall be contained on the :ref:`org-chart`, while
others should be the name and department of external entities.
* Optional
* Keywords --- words or phrases to assist in future searches/lookups
.. impl:: Require document index to be updated upon origination
of any new document or record
:links: R_APPB_83
Updating the index at the point of creation is a robust
way to ensure compliance that each document/record will always
be discoverable and retrievable.
.. _rmdc-doctypes:
Record/Document Types
^^^^^^^^^^^^^^^^^^^^^
One of the following record/document types should be assigned to each
record/document. The types are generally associated with specific forms or
templates that include the expected content/sections, and are often created to
satisfy the needs of a lower-level procedure.
.. impl:: Define numerous Record/Document types
There is a timeless debate about having too many vs. too few doc types.
Additional types are added to support more mature procedure sets, but then
people start to struggle to know what type they should use, leading to
cleanup efforts, followed by management declarations to reduce the number of
types.
A good solution to this problem is to be very explicit in your procedural
culture. Ensure that whenever a record or document is being originated, that
each staff member has the relevant procedure open and is following it
precisely. Ensure that the procedures are rigorous and precise about which
record/document types should be generated in each scenario. When a procedure
is written, ensure that any new record/document types are added to the list
of known types.
.. warning:: Don't make one rec/doc type for each individual checklist or form
in each procedure though. Those can all be forms. Or maybe do make them
all form subtypes? Could be nice to really have specific evidence.
Need easy way to make auto-generated forms per procedure then.
.. datatemplate:yaml::
:source: doc-types.yaml
{{ make_list_table_from_mappings(
[('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use-cases'),
('Record', 'record'), ('Retention', 'retention')],
data,
title='Record/Document types',
) }}

10
documents/procedures/administration/index.rst Normal file
View file

@ -0,0 +1,10 @@
Administration
##############
Administration procedures govern the management of records, corrective actions,
and the management of procedures themselves.
.. toctree::
:glob:
*

35
documents/procedures/administration/procedure_writing.rst Normal file
View file

@ -0,0 +1,35 @@
Procedure Management Procedure
------------------------------
.. impl:: Write and maintain written procedures describing how work is done
:links: R_APPB_22
This procedure governs how procedures are created and maintained.
.. impl:: Require that each procedure include acceptance criteria
:links: R_APPB_44
Each procedure shall include appropriate quantitative or qualitative
acceptance criteria for determining that important activities have been
satisfactorily accomplished.
.. impl:: Keep forms/records/document types synchronized with
the Document management plan
:links: R_APPB_45, R_APPB_43
If procedures are precise about what record/document types to use,
people will be more likely to put in the appropriate and expected
information, maintaining document control.
Whenever a record or document is dictated by a procedure, the procedure shall
clearly specify with record/document type from the list in :ref:`rmdc-doctypes`
is to be used. If a new record or document type is needed for the procedure,
ensure it is defined and added to the list in :ref:`rmdc-doctypes`.
Procedure review checklist
^^^^^^^^^^^^^^^^^^^^^^^^^^
A new or revised procedure should be checked to have the following characteristics:
* It includes acceptance criteria
* Record/documents generated throughout the procedure are identified
clearly, including with type

6
documents/procedures/administration/writers_guide.rst Normal file
View file

@ -0,0 +1,6 @@
Writer's Guide
--------------
See :ref:`meyerProcedureWriterGuide1993`
See :ref:`wieringaProcedureWritingDomains1991`.

87
documents/procedures/engineering/calc.rst Normal file
View file

@ -0,0 +1,87 @@
Engineering Calculation Procedure
*********************************
.. list-table:: Revisions
:widths: 20 80
:header-rows: 1
* - Version
- Change summary
* - 0.1.0
- Initial release
Purpose
=======
Scope
=====
Definitions
===========
Roles & Responsibilities
========================
Originator
----------
Verifier or Checker
-------------------
Responsible Manager
-------------------
Design Authority
----------------
Safety Basis Authority
----------------------
Procedure
=========
General
-------
Determination of Calculation Type
---------------------------------
Use of Engineering Calculation Software
---------------------------------------
Software Management and Quality Assurance
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Functional Classification of Software
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error Control
^^^^^^^^^^^^^
Calculations by Others
----------------------
Registered Professional Engineer
--------------------------------
Release to Outside Agencies
---------------------------
References
==========
Records
=======
Forms
-----
Procedure Basis
===============
The sections in this procedure were informed by Savannah River Conduct of
Engineering Manual E7 Procedure: 2.31 rev 15
https://www.nrc.gov/docs/ML2020/ML20206L028.pdf

13
documents/procedures/engineering/index.rst Normal file
View file

@ -0,0 +1,13 @@
***********
Engineering
***********
Engineering Procedures govern how engineering work is conducted.
.. toctree::
:glob:
:maxdepth: 1
calc
software
*

81
documents/procedures/engineering/software.rst Normal file
View file

@ -0,0 +1,81 @@
Software Management Procedure
*****************************
.. for revisions, put the full system revision in, so that the entire
QA/documentation package is always at the same global revision.
For instance if a doc is introduced at rev 2.1.2, then that should
be listed as the version of initial release. And then if it's changed
next at 2.4.22, that will be the next entry
.. list-table:: Revisions
:widths: 20 80
:header-rows: 1
* - Version
- Change summary
* - 0.1.0
- Initial release
Purpose
=======
Scope
=====
Definitions
===========
Roles & Responsibilities
========================
Design Authority
----------------
Design Agency
-------------
Design Agency Manager
---------------------
Quality Reviewers
-----------------
Independent Reviewers
---------------------
Requirements
============
General
-------
References
==========
Records
=======
Forms
-----
.. Hmm problem: when rendering individual PDFs of each proc the linked requirements
are not available. So they'd show up in the HTML version, or a master PDF of all
docs, but not in individual procs. Maybe that's a bug not a feature, and we can
suppress in all pdfs with .. only html or whatever? Oof but then even the footnotes
wouldn't have a target in the PDFs.... this needs more thinking
This section explains how this procedure meets the linked
regulatory commitments and links to specific requirements.
.. note:: This can help explain why the procedure is designed
the way it is to aid in future improvements.
.. [sn1] Document things
.. impl:: Think software here
:links: R_APPB_39
Hi there.

11
documents/procedures/human_resources/index.rst Normal file
View file

@ -0,0 +1,11 @@
***************
Human Resources
***************
HR govern how recruiting, hiring, training, qualifications are managed.
.. toctree::
:glob:
*

19
documents/procedures/index.rst Normal file
View file

@ -0,0 +1,19 @@
##########
Procedures
##########
This section contains Procedures that govern how work gets done at |inst|.
Compliance with all procedures is required at all times. They are designed to
ensure consistent and traceable compliance with our regulatory requirements and
business needs.
.. toctree::
:glob:
:maxdepth: 2
administration/index
human_resources/index
engineering/index
operations/index
procurement/index
*

10
documents/procedures/operations/index.rst Normal file
View file

@ -0,0 +1,10 @@
**********
Operations
**********
Operations procedures govern how facilities and equipment are operated.
.. toctree::
:glob:
*

11
documents/procedures/procurement/index.rst Normal file
View file

@ -0,0 +1,11 @@
***********
Procurement
***********
Procurement procedures govern how service and equipment are purchased from
suppliers and vendors.
.. toctree::
:glob:
*

4
documents/project/index.rst Normal file
View file

@ -0,0 +1,4 @@
.. thinking of putting like, all the calcs you have to do during design,
calibrations during commissioning,
work during operations. This would be where we could be like, "Hey don't forget
to include impurities in shielding calculations"

17
documents/purpose/index.rst Normal file
View file

@ -0,0 +1,17 @@
#######
Purpose
#######
This section describes the vision, mission, objectives, and values of this
institution. These are what differentiate this organization from all others.
They guide essential decisions every day about what to do, who to hire, how to
solve problems. They also provide the basis for top-level requirements
that drive all underlying work.
.. toctree::
vision
values
story
objectives

12
documents/purpose/milestones.yml Normal file
View file

@ -0,0 +1,12 @@
- start: 1885-09-05
name: Hill Valley clock dedicated
- start: 1955-11-05
name: Had initial innovation
- start: 1955-11-12
name: Fish Under the Sea ball
- start: 1985-10-26 01:21 (US/Pacific)
name: "Temporal Experiment #1"
- start: 1985-10-26 01:35 (US/Pacific)
name: Accidental time jump
- start: 2015-10-21 16:29 (US/Pacific)
name: Saved Marty Jr.

24
documents/purpose/objectives.rst Normal file
View file

@ -0,0 +1,24 @@
**********
Objectives
**********
.. Here's where you'll define specific goals and objectives
that can drive your actions.
.. todo:: Maybe rename to "activities?"
We are the premier potassium vapor turbine manufacturer
this side of the Mississippi. We:
* Perform research and development on potassium vapor turbines, including:
* Computational models
* Conceptual design
* Materials research
* Prototype testing
* Provide design services for customized potassium vapor turbines
* Manufacture potassium vapor turbines
* Test and qualify potassium vapor turbines

21
documents/purpose/story.rst Normal file
View file

@ -0,0 +1,21 @@
*****
Story
*****
.. Write up your history here so everyone can know.
Our story began on November 5, 1955. I remember it vividly. I was standing on
the edge of my toilet hanging a clock. The porcelain was wet. I slipped, hit my
head on the edge of the sink, and when I came to I had a revelation. A vision.
A picture in my head. A picture of this. This is what makes time travel
possible: the flux capacitor!
Historical Milestones
=====================
.. timeline::
:events: ./milestones.yml
**{{dtrange(day_name=False, short_date=False)}}**
*{{e.name}}*

24
documents/purpose/values.rst Normal file
View file

@ -0,0 +1,24 @@
******
Values
******
.. Define your values here: the specific traits that define your
people and organization. Be careful though: ENRON's values were
"Respect, Integrity, Communication and Excellence"
We are driven by a set of values, as follows:
* **Innovation** — We come up with ideas no one else has had, except
back in the 1950s.
* **Dedication** — We believe in our challenges and want to work
hard to make them go away
* **Perseverance** — We do things not because they are easy, but because
we thought that they would be easy
We also have some lesser biases and preferences:
.. This is where you can put things like, "Well we're funded by Jeff Bezos so
we generally prefer Amazon Web Services IT solutions" or whatever
* **Open-source** — We use and support open source software and data projects.

11
documents/purpose/vision.rst Normal file
View file

@ -0,0 +1,11 @@
******
Vision
******
.. The vision is generally a brief statement describing the long-term world in
which your efforts are successful. For example, Microsoft's vision once was: "a
microcomputer on every desk and in every home".
Our organization is driven by a singular vision:
**"A nuclear reactor on every desk and in every home"**

18
documents/requirements/index.rst Normal file
View file

@ -0,0 +1,18 @@
############
Requirements
############
This section contains objectives, rules, regulations, codes, and standards that
are applicable to the institution. These drive the projects goals and constraints
and are contained here to maintain a linkage between the procedures and their
bases.
.. toctree::
:maxdepth: 2
:caption: Contents:
:glob:
stakeholder/index
national/index
standards/index
*

48
documents/requirements/national/USA/10cfr50.rst Normal file
View file

@ -0,0 +1,48 @@
10 CFR 50
=========
.. req:: Abide by 10 CFR 50
:id: R_10CFR50
.. :basis: Promulgated by the Nuclear Regulatory Commission pursuant to the
Atomic Energy Act of 1954, as amended (68 Stat. 919), and Title II of the
Energy Reorganization Act of 1974 (88 Stat. 1242), to provide for the
licensing of production and utilization facilities
Appendix A
----------
`10 CFR 50 Appendix A
<https://www.nrc.gov/reading-rm/doc-collections/cfr/part050/part050-appa.html>`_
contains the General Design Criteria for nuclear power plants, often considered
primarily for LWRs. For non-LWRs, you may want to bring in RG 1.232, which
describes the development of PDCs for non-LWRs.
See `NRC summary of non-LWR Design Criteria <https://www.nrc.gov/reactors/new-reactors/advanced/modernizing/rulemaking-and-guidance/nrc-doe-joint-initiative-non-lwr-design-criteria.html>`_
and `RG 1.232 <https://www.nrc.gov/docs/ML1732/ML17325A611.pdf>`_.
.. needtable:: Appendix A summary
:filter: id.startswith("R_GDC")
:columns: id
.. include:: /../generated_assets/10-cfr-50-app-a-list.rst
Appendix B
----------
.. req:: Abide by 10 CFR 50 App B
:id: R_10CFR50_APPB
:links: R_10CFR50
:collapse: true
`10 CFR 50 Appendix B
<https://www.nrc.gov/reading-rm/doc-collections/cfr/part050/part050-appb.html>`_
describes the quality assurance criteria for nuclear plants and fuel
reprocessing plants.
.. :basis: Flowed down
.. needimport:: /../generated_assets/10-cfr-50-app-b.json
:collapse: true
:tags: ["quality"]

7
documents/requirements/national/index.rst Normal file
View file

@ -0,0 +1,7 @@
National Regulations
====================
.. toctree::
:glob:
USA/*

8
documents/requirements/standards/index.rst Normal file
View file

@ -0,0 +1,8 @@
###################
Consensus Standards
###################
.. toctree::
:maxdepth: 2
:caption: Contents:

8
documents/software/index.rst Normal file
View file

@ -0,0 +1,8 @@
########
Software
########
We run a wide variety of software systems to help facilitate our work.
.. toctree::

19
documents/software/task_management.rst Normal file
View file

@ -0,0 +1,19 @@
Task Management
###############
A wide variety of key information fits into the category
of task management, ranging from formally tracked to
casual TODOs. These include:
* Regulatory commitments that we are legally bound to (really?)
* Conditions and limitations on topical reports (really?)
* Requests For additional Information (RFIs)
* Corrective actions
* Open items
* Scheduled tasks
* Bug reports
* Feature requests
* Helpdesk tickets
* Facilities tickets
* Decomposed tasks (e.g. on a Kanban board)
* Action items from meetings

BIN
documents/templates/doc_template_1.odt Normal file
View file

Binary file not shown.

74
pyproject.toml Normal file
View file

@ -0,0 +1,74 @@
[project]
name = "nuclear-reactor-starter-kit"
version = "0.1.0"
authors = [
{ name="Nick Touran", email="nick@whatisnuclear.com" },
]
description = """\
A baseline set of requirements, procedures, templates, forms, \
and tools supporting efficient nuclear energy endeavors.\
"""
readme = "README.md"
requires-python = ">=3.9"
dependencies = [
"openpyxl",
"pyyaml",
"nltk",
"sphinx",
"sphinx-book-theme",
"sphinx-needs[plotting]",
"sphinxcontrib.plantuml",
"myst-parser",
"sphinx-pyproject",
"beautifulsoup4",
"sphinxcontrib-bibtex >= 2.6.1",
"sphinxcontrib-glossaryused @ git+https://github.com/partofthething/glossaryused@bb321e6581b4c0618cd6dc4f1fd8355d314aee4d",
"sphinx-autobuild",
"sphinxcontrib.datatemplates",
"sphinxcontrib-mermaid",
"sphinxcontrib-svg2pdfconverter",
"sphinx-timeline",
]
classifiers = [
"Programming Language :: Python :: 3",
"License :: OSI Approved :: MIT License",
"Operating System :: OS Independent",
]
[project.urls]
Homepage = "https://github.com/whatisnuclear/nrsk"
Issues = "https://github.com/whatisnuclear/nrsk/issues"
[project.optional-dependencies]
dev = [
"ruff",
"black",
"isort",
]
test = [
]
[tool.ruff]
fix = true
[tool.ruff.lint]
select = ["E4", "E7", "E9", "F", "W", "C901", "I", "N", "D", "B", "A", "DTZ", "Q", "RET", "SIM"]
unfixable = ["F401"]
[tool.ruff.lint.pydocstyle]
convention = "numpy"
[tool.sphinx-pyproject]
project = "Nuclear Reactor Starter Kit"
copyright = "2025, Nick Touran"
# The full version, including alpha/beta/rc tags
release = "0.1.0"
github_username = "whatisnuclear"
github_repository = "nrsk"
[tool.isort]
multi_line_output = 3
include_trailing_comma = true
force_grid_wrap = 0
line_length = 88
profile = "black"

0
src/nrsk/__init__.py Normal file
View file

0
src/nrsk/regs/__init__.py Normal file
View file

168
src/nrsk/regs/load_10cfr50.py Executable file
View file

@ -0,0 +1,168 @@
"""
Read text 10 CFR 50 App B and turn to json and xlsx.
Text should be loaded from web and pasted into data folder.
Needs to eventually write requirements data to flow down to QA program.
One way to do that is to write a ``needs.json`` file to the format
described `here <https://sphinx-needs.readthedocs.io/en/latest/builders.html#format>`_.
"""
import json
import logging
import re
import requests
from bs4 import BeautifulSoup
from nrsk.utils import excel, get_project_root, needs, tokenize
logging.basicConfig(level=logging.INFO)
ROOT = get_project_root()
LOG = logging.getLogger(__name__)
TXT_10_CFR_50_APPA = ROOT / "data" / "regs" / "10-cfr-50-app-a.txt"
TXT_10_CFR_50_APPB = ROOT / "data" / "regs" / "10-cfr-50-app-b.txt"
OUT_PATH = ROOT / "documents" / "generated_assets"
# todo: move to config file in case they change?
URL_APP_A = (
"https://www.nrc.gov/reading-rm/doc-collections/cfr/part050/part050-appa.html"
)
URL_APP_B = (
"https://www.nrc.gov/reading-rm/doc-collections/cfr/part050/part050-appb.html"
)
def fetch_10cfr50_app_a():
"""Go online and get the text of 10CFR50 App A.
We still commit the results to the repo because this system
may be run in an environment that does not have internet access.
This is here to show how the committed files are created in the first place.
Note that this may require changes if the NRC updates the format of the
webpage.
"""
def _is_criteria_label(tag):
return tag.name == "p" and tag.string == "Criteria"
html_app_a = requests.get(URL_APP_A).text
soup = BeautifulSoup(html_app_a, "html.parser")
# criteria are all in the last general-content div
content = soup.find_all("div", class_="general-content")[-1]
label = content.find_next(_is_criteria_label)
with TXT_10_CFR_50_APPA.open("w") as f:
for crit in label.find_all_next("p"):
if "1 Further details relating" in crit.text:
# marks the end
break
f.write(crit.text + "\n\n")
def process_10cfr50_app_a():
"""
Convert App A text (General Design Criteria) into Sphinx Needs.
Each criteria actually has a name and then a number of shall sentences
below it. So each number should make 1 main need + numerous child needs.
Input text file should start in the Criteria section, e.g. at Overall
Requirements.
Since this makes parent/child requirements, we'll try using the Sphinx-needs
list2need feature for this one.
https://sphinx-needs.readthedocs.io/en/latest/directives/list2need.html
list2need is messing up labels on (1) and (2) listings in the text so I'm going to remap
those over to 1. and 2., etc.
Groan it's also messing up on non-numerical parentheticals. Must be a sphinx-needs bug.
Will map those to comma phrases.
Groan even then it's still messed up.
.. todo:: submit a bug report to sphinx-needs with these examples.
"""
def process(line):
line = re.sub(r"\((\d+)\)", r"\1.", line)
line = re.sub(r"\((.+)\)", r", \1,", line)
return line
needs_lines = [".. list2need::", " :types: req, req, req", ""]
with open(TXT_10_CFR_50_APPA) as inp_f:
for line in inp_f:
line = line.strip()
if not line:
continue
if re.search(r"^[A-Z]+\. [A-Z]", line):
LOG.info("Reading %s", line)
elif match := re.search(r"^Criterion (\d+)—(.+?)\.(.+)", line):
num = match.group(1).strip()
title = match.group(2).strip()
subnum = 1
LOG.info(
"Found Criterion %s - %s",
match.group(1).strip(),
match.group(2).strip(),
)
needs_lines.append(f" * (R_GDC_{num}){process(title)}")
sentences = tokenize.tokenize_sentences(match.group(3).strip())
for sent in sentences:
needs_lines.append(
f" * (R_GDC_{num}_{subnum}){process(sent.strip())}"
)
subnum += 1
else:
sentences = tokenize.tokenize_sentences(line)
for sent in sentences:
needs_lines.append(
f" * (R_GDC_{num}_{subnum}){process(sent.strip())}"
)
subnum += 1
with open(OUT_PATH / "10-cfr-50-app-a-list.rst", "w") as out_f:
out_f.write("\n".join(needs_lines))
def process_10cfr50_app_b():
"""
Read 10 CFR 50 App B and generate needs data from it, and xlsx.
Just tokenizing the text straight up works ok.
"""
with open(TXT_10_CFR_50_APPB) as inp_f:
sentences = tokenize.tokenize_sentences(inp_f.read())
needs_data = []
i = 0
for s in sentences:
if len(s) < 40:
LOG.warning(f"Skipping short sentence: `{s}`")
continue
needs_data.append((f"10 CFR 50 App B Sentence {i}", s))
i += 1
with (OUT_PATH / "10-cfr-50-app-b.json").open("w") as f:
json.dump(
needs.data_to_needs(needs_data, prefix="R_APPB_", links=["R_10CFR50_APPB"]),
f,
indent=4,
)
filtered_titles, filtered_sentences = zip(*needs_data)
wb = excel.make_xlsx_from_sentences(filtered_sentences)
wb.save(OUT_PATH / "10-cfr-50-app-b.xlsx") # can only write to disk, not stream
if __name__ == "__main__":
# fetch_10cfr50_app_a()
OUT_PATH.mkdir(parents=True, exist_ok=True)
process_10cfr50_app_a()
process_10cfr50_app_b()

5
src/nrsk/utils/__init__.py Normal file
View file

@ -0,0 +1,5 @@
"""General Utils."""
from pathlib import Path
def get_project_root() -> Path:
return Path(__file__).parent.parent.parent.parent

12
src/nrsk/utils/excel.py Normal file
View file

@ -0,0 +1,12 @@
"""Excel utils."""
from openpyxl import Workbook
def make_xlsx_from_sentences(sentences: list) -> Workbook:
"""Convert json list of sentences to xlsx with numbers."""
wb = Workbook()
ws = wb.active
for row_data in enumerate(sentences):
ws.append(row_data)
return wb

53
src/nrsk/utils/forms.py Normal file
View file

@ -0,0 +1,53 @@
"""
Utilities for working with Forms.
"""
import os
import subprocess
import yaml
PDFTK = "/usr/bin/pdftk"
def load_form_data(file_path):
"""Load yaml or json form data intended to be populated into a form template."""
with open(file_path, "r") as f:
if file_path.endswith(".yaml"):
return yaml.safe_load(f)
elif file_path.endswith(".json"):
import json
return json.load(f)
def create_fdf(data, fdf_file):
"""Create form data in FDF format to fill into a PDF form template."""
fdf = "%FDF-1.2\n1 0 obj\n<< /FDF << /Fields ["
for key, value in data.items():
value = str(value).replace("\n", " ").replace("\r", "")
fdf += f"<< /V ({value}) /T ({key}) >>"
fdf += "] >> >>\nendobj\ntrailer\n<< /Root 1 0 R >>\n%%EOF"
with open(fdf_file, "w") as f:
f.write(fdf)
def fill_pdf(template_pdf, fdf_file, output_pdf):
"""Populate a given pdf form template with form data."""
temp_fname = output_pdf + ".filled"
subprocess.call([PDFTK, template_pdf, "fill_form", fdf_file, "output", temp_fname])
# and flatten it
subprocess.call([PDFTK, temp_fname, "output", output_pdf, "flatten"])
os.remove(temp_fname)
def demo():
# Example usage
# for checkboxes, use "Yes" and "Off"
data = {"Name": "DIF3D", "ExportControlled": "Yes", "Type": "Engineering"}
create_fdf(data, "data.fdf")
fill_pdf(
"software-dedication-form.pdf",
"data.fdf",
"software-dedication-form-filled.pdf",
)

37
src/nrsk/utils/needs.py Normal file
View file

@ -0,0 +1,37 @@
"""Utils for building/managing sphinx-needs data."""
import datetime
def data_to_needs(
needs_data: list[str, str],
prefix="",
type="req",
type_name="Requirement",
links=None,
) -> dict:
"""
Convert list of (titles, texts) to valid needs data.
Format from: https://sphinx-needs.readthedocs.io/en/latest/builders.html#format
"""
now = datetime.datetime.now().isoformat()
need_data = {}
for i, (title, body) in enumerate(needs_data):
id = f"{prefix}{i}"
need_data[id] = {
"description": body,
"id": id,
"title": title,
"type": type,
"type_name": type_name,
"links": links or [],
"tags": [],
}
data = {
"created": now,
"current_version": "1.0",
"project": "nuclear reactor starter kit",
"versions": {"1.0": {"created": now, "needs": need_data}},
}
return data

15
src/nrsk/utils/tokenize.py Normal file
View file

@ -0,0 +1,15 @@
"""
Break input text file into sentences.
"""
from nltk.tokenize.punkt import PunktSentenceTokenizer
def tokenize_sentences(text: str) -> list:
tokenizer = PunktSentenceTokenizer()
tokenizer.train(text)
sentences = tokenizer.tokenize(text)
return sentences