Initial commit

documents/procedures/administration/corrective_action.rst

@@ -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.

documents/procedures/administration/doc-types.yaml

@@ -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
+

documents/procedures/administration/document_management.rst

@@ -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',
+        ) }}

documents/procedures/administration/index.rst

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

documents/procedures/administration/procedure_writing.rst

@@ -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

documents/procedures/administration/writers_guide.rst

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

documents/procedures/engineering/calc.rst

@@ -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

documents/procedures/engineering/index.rst

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

documents/procedures/engineering/software.rst

@@ -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.
+

documents/procedures/human_resources/index.rst

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

documents/procedures/index.rst

@@ -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
+    *

documents/procedures/operations/index.rst

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

documents/procedures/procurement/index.rst

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