diff --git a/source/user/tutorial/add_arche.rst b/source/user/tutorial/add_arche.rst
index eed023a4..33d48bd9 100644
--- a/source/user/tutorial/add_arche.rst
+++ b/source/user/tutorial/add_arche.rst
@@ -118,7 +118,7 @@ The archetypes we will use in our simulation include:
 -  ``cycamore Sink``: to act as the geological repository. 
 
 A user identifies the simulation ``archetypes`` in the archetype block of the |Cyclus| input file. 
-The ``archetype`` block is located after the simulation control block and takes the form:
+The ``archetype`` block is located after the simulation ``control`` block and takes the form:
 
 .. code-block:: XML
 
@@ -164,7 +164,7 @@ fill in the template with the variables listed in the table below.
 The order of the archetypes in this block is of no consequence. Once complete, append the archetypes section under the control section of input file [#f1]_.
 
 Check: Complete Archetypes block
-+++++++++++++++++++++++++++++++++++++++
+=================================
 
 The archetypes section of your input file should now look like:
 
diff --git a/source/user/tutorial/add_arche_commod_recipe.rst b/source/user/tutorial/add_arche_commod_recipe.rst
index bfca70f9..04eca53a 100644
--- a/source/user/tutorial/add_arche_commod_recipe.rst
+++ b/source/user/tutorial/add_arche_commod_recipe.rst
@@ -15,7 +15,7 @@ We will need two additional archetypes:
 Activity: Adding Recipes
 --------------------------
 
-We'll continue with very approximate recipes by adding a single recipe for Used-MOX-Fuel:
+We'll continue with very approximate recipes by adding a single recipe for ``used_mox`` with a mass ``basis``:
 
 +------------+-----------------+
 |  U-235     |   0.002         |
diff --git a/source/user/tutorial/add_commod_recipe.rst b/source/user/tutorial/add_commod_recipe.rst
index 7773a4cd..27a95100 100644
--- a/source/user/tutorial/add_commod_recipe.rst
+++ b/source/user/tutorial/add_commod_recipe.rst
@@ -9,7 +9,7 @@ called the `dynamic resource exchange (DRE) <https://fuelcycle.org/arche/dre.htm
 The concept of a **commodity** is
 used to simply indicate which facilities may be interested in trading with
 each other through the DRE. A commodity is therefore nothing more than a
-unique name that is used to define a set of producers and consumers of a
+unique name that is used to define a set of suppliers and consumers of a
 common resource.  A commodity does not necessarily have a specific
 composition; this will be determined by the agents during the simulation.
 Suppliers then respond to the series of requests with a **bid**. A bid
@@ -94,8 +94,9 @@ Activity: Creating a Recipe
 For this input file, we need to define three recipes: natural uranium, fresh fuel, 
 and spent fuel. We'll be using simple mass basis recipes to define the isotopic 
 composition of these materials.
-Using the tables below, fill out three recipe
-templates for natural uranium, fresh fuel, and spent fuel.
+Using the template above and the tables below, fill out three recipe
+templates for natural uranium , fresh fuel, and spent fuel with ``name`` for each being 
+``nat_u``, ``fresh_uox``, and ``spent_uox``. 
 
 +---------------------+--------------------+--------------------+
 | Natural Uranium Composition                                   |
diff --git a/source/user/tutorial/add_proto.rst b/source/user/tutorial/add_proto.rst
index b0c2ffb1..ca466b98 100644
--- a/source/user/tutorial/add_proto.rst
+++ b/source/user/tutorial/add_proto.rst
@@ -21,7 +21,7 @@ include:
 
 * input/output commodity name: Name of the `commodity <https://fuelcycle.org/basics/glossary.html#term-commodity>`_ that the prototype will request (input) or trade away (output).
 * input/output recipe name: Name of the **recipe** or isotopic composition for the input or output commodity. Recipe names used in defining a prototype must be defined in a `recipe block <https://fuelcycle.org/user/tutorial/add_commod_recipe.html#understanding-recipes>`_ of the input file. 
-* throughput: The rate at which the process of a facility occurs. Common units are kg/time step, although you should check the archetypes documentation
+* throughput: The rate at which the process of a facility occurs. Common units are kg/time step, although you should check the archetypes documentation for archetype-specific units. 
 * buffer size: The size (typically in kg) of an inventory within a prototype. A prototype may have multiple buffers, such as a reactor having an inventory for fresh fuel and one for fuel in the core. 
 
 Example: Source Prototype
@@ -29,7 +29,7 @@ Example: Source Prototype
 The Source facility acts as a source of material with a fixed throughput (per 
 time step) capacity and a lifetime capacity defined by a total inventory size. 
 It offers its material as a single commodity. If a composition recipe is 
-specified, it provides that single material composition to requesters. If 
+specified, it provides that exact recipe composition to requesters. If 
 unspecified, the source provides materials with the exact requested compositions. 
 The inventory size and throughput both default to infinite. Supplying material 
 from an instance of a Source prototype that is deployed in a simulation
@@ -83,14 +83,14 @@ Optional parameters:
 Activity: Configure the Source prototype
 ++++++++++++++++++++++++++++++++++++++++
 Our source, ``UraniumMine``, will provide the natural uranium ore for our enrichment facility.
-This facility takes two inputs, ``name`` and ``outcommod``. Using the Source archetype template above and the table below, create the UraniumMine prototype.
+This facility takes two inputs, ``name`` and ``outcommod``. Using the Source archetype template above and the table below, create the Source facility prototype.
 
 +-----------------------+---------------------------+
 | Variable              | Value                     |
 +=======================+===========================+
 | ``name``              | ``UraniumMine``           |
 +-----------------------+---------------------------+
-| ``out_commodity``       | ``u_ore``                 |
+| ``outcommod``         | ``u_ore``                 |
 +-----------------------+---------------------------+
 
 Once complete, append this facility under the archetypes section and before the recipe section of your input file [#f1]_.
@@ -113,6 +113,7 @@ The Enrichment archetype is of the form:
             <feed_recipe>[string]</feed_recipe>
             <product_commod>[string]</product_commod>
             <tails_commod>[string]</tails_commod>
+            <max_feed_inventory>[double]</max_feed_inventory>
           </Enrichment>
         </config>
       </facility>
@@ -163,9 +164,9 @@ Optional parameters:
 
 Activity: Creating the Enrichment Prototype
 +++++++++++++++++++++++++++++++++++++++++++
-The enrichment facility, ``EnrichmentPlant`` will intake the natural ``u_ore`` 
+The Enrichment facility, ``EnrichmentPlant`` will intake the natural ``u_ore`` 
 from ``UraniumMine`` and create ``fresh_uox`` and ``tails`` as its products. 
-Using the Enrichment archetype template above and the table below, generate the input enrichment facility prototype.
+Using the Enrichment archetype template above and the table below, generate the Enrichment facility prototype.
 
 +-------------------------+---------------------------+
 | Variable                | Value                     |
@@ -189,8 +190,8 @@ Once complete, append this facility under the Source prototype of your input fil
 Example: Reactor Prototype
 ++++++++++++++++++++++++++
 The Reactor is a simple, general reactor based on static compositional transformations to model fuel burnup. 
-The user specifies a set of fresh fuel compositions the Reactor accepts and corresponding spent fuel 
-compositions the reactor discharges from the core. No incremental transmutation takes place. Rather, 
+The user specifies a set of fresh fuel compositions the Reactor accepts and a set of corresponding spent fuel 
+compositions the Reactor discharges from the core. No incremental transmutation takes place at each time step. Rather, 
 at the end of an operational cycle, the batch being discharged from the core is instantaneously transmuted 
 from its original fresh fuel composition into its spent fuel form.
 
@@ -200,16 +201,16 @@ when requesting. Changes in these preferences can be specified as a function of
 variables. Changes in the input-output recipe compositions can also be specified as a function of time using 
 the ``recipe_change`` variables.
 
-The reactor treats fuel as individual assemblies. Fuel is requested in assembly-sized quanta. If real-world
+The Reactor treats fuel as individual assemblies. Fuel is requested in assembly-sized quanta. If real-world
 assembly modeling is unnecessary, parameters can be adjusted (e.g. ``n_assem_core``, ``assem_size``, 
 ``n_assem_batch``). At the end of every cycle, a full batch is discharged from the core consisting of
-``n_assem_batch`` assemblies of ``assem_size`` kg. The reactor also has a specifiable refueling time 
+``n_assem_batch`` assemblies of ``assem_size`` kg. The Reactor also has a specifiable refueling time 
 period following the end of each cycle at the end of which it will resume operation on the next cycle if it 
 has enough fuel for a full core; otherwise it waits until it has enough fresh fuel assemblies.
 When the reactor reaches the end of its lifetime, it will discharge all material from its core and trade away all its 
-spent fuel as quickly as possible. Full decommissioning will be delayed until all spent fuel is gone. If the reactor 
-has a full core when it is decommissioned (i.e. is mid-cycle) when the reactor is decommissioned, half (rounded 
-up to nearest int) of its assemblies are transmuted to their respective burnt compositions.
+spent fuel as quickly as possible. Full decommissioning will be delayed until all spent fuel is gone. If the Reactor 
+has a full core when it is decommissioned (i.e. is mid-cycle), half (rounded 
+up to nearest int) of its assemblies are transmuted to their respective spent compositions.
 The Reactor archetype is of the form:
 
 .. code-block:: XML
@@ -243,12 +244,12 @@ The Reactor archetype is of the form:
 Where:
 
 * ``fuel_incommods``: input fuel commodity -- you can list more than one by adding more ``val`` blocks
-* ``fuel_inrecipes``" input fuel recipe -- you can list more than one
+* ``fuel_inrecipes``: input fuel recipe -- you can list more than one
 * ``fuel_outcommods``: output fuel commodity -- you can list more than one
 * ``fuel_outrecipes``: output fuel recipe -- you can list more than one
 * ``cycle_time``: amount of time the reactor operates between refueling outages
 * ``refuel_time``: duration of refueling outage
-* ``assem_size``" size of a single assembly
+* ``assem_size``: size of a single assembly
 * ``n_assem_core`` : number of assemblies in the core
 * ``n_assem_batch``: number of batches replaced per refueling.
 * ``power_cap``: amount of electricity the reactor generates.
@@ -261,45 +262,45 @@ Activity: Creating the Reactor Prototype
 
 Now let's model the reactor this fuel will go through! In this simple example, 
 let's model a single PWR in the United States. It has a power capacity of 1178 
-MWe. Using the Reactor archetype template above and the table below, create the Reactor prototype.
+MWe. Using the Reactor archetype template above and the table below, create the Reactor facility prototype.
 
 +-----------------------+-----------------------------------+
 | Variable              | Value                             |
 +=======================+===================================+
 | ``name``              | ``1178MWe ReactorPlant Unit 1``   |
 +-----------------------+-----------------------------------+
-| ``in_commod1``        | ``fresh_uox``                     |
+| ``fuel_incommods``    | ``fresh_uox``                     |
 +-----------------------+-----------------------------------+
-| ``in_recipe1``        | ``fresh_uox``                     | 
+| ``fuel_inrecipes``    | ``fresh_uox``                     | 
 +-----------------------+-----------------------------------+
-| ``out_commod1``       | ``spent_uox``                     |
+| ``fuel_outcommods``   | ``spent_uox``                     |
 +-----------------------+-----------------------------------+
-| ``out_recipe1``       | ``spent_uox``                     |
+| ``fuel_outrecipes``   | ``spent_uox``                     |
 +-----------------------+-----------------------------------+
-| ``cycle_length``      | ``18``                            |
+| ``cycle_time``        | ``18``                            |
 +-----------------------+-----------------------------------+
-| ``refuel_length``     | ``1``                             |
+| ``refuel_time``       | ``1``                             |
 +-----------------------+-----------------------------------+
-| ``assem_mass``        | ``33000``                         |
+| ``assem_size``        | ``33000``                         |
 +-----------------------+-----------------------------------+
-| ``n_core``            | ``3``                             |
+| ``n_assem_core``      | ``3``                             |
 +-----------------------+-----------------------------------+
-| ``n_batch``           | ``1``                             |
+| ``n_assem_batch``     | ``1``                             |
 +-----------------------+-----------------------------------+
-| ``power``             | ``1178``                          |
+| ``power_cap``         | ``1178``                          |
 +-----------------------+-----------------------------------+
 
-Once complete, append this facility under the Enrichment facility of your input file [#f1]_.
+Once complete, append this facility under the Enrichment prototype of your input file [#f1]_.
 
 
 Example: Sink Prototype
 +++++++++++++++++++++++
 
-A sink facility that accepts materials and products with a fixed throughput (per time step) capacity and a lifetime 
+The Sink facility accepts materials and products with a fixed throughput (per time step) capacity and a lifetime 
 capacity defined by a total inventory size. The inventory size and throughput capacity both default to infinite. If a 
 recipe is provided, it will request material with that recipe. Requests are made for any number of specified 
 commodities.
-The Sink archetype section is of the form:
+The Sink archetype is of the form:
 
 .. code-block:: xml
 
@@ -362,9 +363,9 @@ create the NuclearRepository prototype.
 +=========================+===========================+
 | ``name``                | ``NuclearRepository``     |
 +-------------------------+---------------------------+
-| ``input_commodity1``    | ``spent_uox``             |
+| ``in_commods``          | ``spent_uox``             |
 +-------------------------+---------------------------+
-| ``input_commodity2``    | ``tails``                 |
+| ``in_commods``          | ``tails``                 |
 +-------------------------+---------------------------+
 
 Once complete, append this facility under the Reactor prototype of your input file [#f1]_.
diff --git a/source/user/tutorial/add_reg_inst.rst b/source/user/tutorial/add_reg_inst.rst
index 779226ca..6f9016ca 100644
--- a/source/user/tutorial/add_reg_inst.rst
+++ b/source/user/tutorial/add_reg_inst.rst
@@ -27,9 +27,9 @@ than the ``cycamore`` library. The ``agents`` library comes with Cyclus, and
 you can run ``cyclus --a`` to check that the archetypes are installed. 
 
 Since these are all archetypes, no matter what library they're from, we must include 
-them into the the Archetypes block that we already have.
+them into the the ``archetypes`` block that we already have.
 Using the template on the `Understanding Archetypes <https://fuelcycle.org/user/tutorial/add_arche.html>`_ codepage,
-append two ``spec`` blocks into the Archetypes block for the variables listed in the table below.
+append two ``spec`` blocks into the ``archetypes`` block for the variables listed in the table below.
 
 +-------------+-------------+------------------+
 | Archetype # | Variable    | Value            |
@@ -79,9 +79,9 @@ Concept: Regions
 ----------------
 
 Regions tie together a fuel cycle as they designate what institutions and facilities are
-in the region's fuel cycle. Regions may apply preferences to each
+under a region's management. Regions may apply preferences to each
 potential request-bid pairing based on the proposed resource transfer.
-The basic structure of a region block is:
+The basic structure of a ``region`` block is:
 
 .. code-block:: XML
 
@@ -129,7 +129,7 @@ Concept: Institutions
 -----------------------------------------------------------------------
 In |Cyclus| input files, each institution controls the deployment of 
 the prototypes in the simulation, among other things. An institution block can only
-appear within a region block. Each institution block has the following
+appear within a ``region`` block. Each institution block has the following
 sections in any order:
 
 -  ``name`` (required, once) - a name for the prototype
diff --git a/source/user/tutorial/add_second_reactor.rst b/source/user/tutorial/add_second_reactor.rst
index 10542620..32df06e8 100644
--- a/source/user/tutorial/add_second_reactor.rst
+++ b/source/user/tutorial/add_second_reactor.rst
@@ -17,7 +17,7 @@ prototype.
 +-----------------------+---------------------------+
 | Variable              | Value                     |
 +=======================+===========================+
-| ``name``              | ``1000MWe Lightwater_1``   |
+| ``name``              | ``1000MWe Lightwater_1``  |
 +-----------------------+---------------------------+
 | ``lifetime``          | ``360``                   |
 +-----------------------+---------------------------+
diff --git a/source/user/tutorial/add_sep.rst b/source/user/tutorial/add_sep.rst
index 2713c99e..838a1e5c 100644
--- a/source/user/tutorial/add_sep.rst
+++ b/source/user/tutorial/add_sep.rst
@@ -44,15 +44,15 @@ The following is the input template for ``Cycamore::Separations`` archetype:
 
 
 * Our feed commodity list should include both:
-   * Used-UOX-Fuel
-   * Used-MOX-Fuel
+   * Used UOX Fuel: ``used_uox``
+   * Used MOX Fuel: ``used_mox``
 * The maximum feed inventory is the most feed material that we'll have on
   hand: 1000 tonnes.
 * The maximum separations throughout is the size of our plant: 80 tonnes/timestep
-* This simple scenario will have a single output stream: Separated_Fissile
-    * we will hold no more than 5 tonnes of separated material on hand at any time
+* This simple scenario will have a single output stream: ``Separated_Fissile``
+    * We will hold no more than 5 tonnes of separated material on hand at any time
     * 99% of all Pu (94000) will go into that stream
-* all other material will go to Separated_Waste
+* all other material will go to ``Separated_Waste``
 
 Filling in the template, the input block looks like:
 
diff --git a/source/user/tutorial/run_cyclus_native.rst b/source/user/tutorial/run_cyclus_native.rst
index 4f579c13..c647dc86 100644
--- a/source/user/tutorial/run_cyclus_native.rst
+++ b/source/user/tutorial/run_cyclus_native.rst
@@ -13,12 +13,14 @@ Command Line Execution
 Running Cyclus from the command line requires running the command 
 
 .. code-block:: bash 
+
     $ cyclus 
 
 
 You can view all of the input flags for this command by running
 
 .. code-block:: bash 
+    
     $ cyclus -h 
 
 
diff --git a/source/user/tutorial/sim_parm.rst b/source/user/tutorial/sim_parm.rst
index e974e083..044d6c95 100644
--- a/source/user/tutorial/sim_parm.rst
+++ b/source/user/tutorial/sim_parm.rst
@@ -12,7 +12,7 @@ cycle.  For the purpose of this tutorial, the scenario will include:
 * LWR reactor consuming fresh fuel and producing used fuel
 * repository to house all spent fuel and waste
 
-More details about each of these facilities will discussed when we are
+More details about each of these facilities will be discussed when we are
 required to provide that input.
 
 Concept: Simulation Time Steps
@@ -25,16 +25,16 @@ how to build an XML input.
 
 The XML |Cyclus| input file begins with the ``<simulation>`` tag and ends with the 
 ``</simulation>`` tag. Within this space, the ``<control>`` block is the first
-section of the CYCLUS input file and is of the form:
+section of the |Cyclus| input file and is of the form:
 
 .. code-block:: XML
 
     <simulation>
       <control>
-        <duration>duration_val</duration>
-        <startmonth>start_month_val</startmonth>
-        <startyear>start_year_val</startyear>
-        <decay>decay_val</decay>
+        <duration>[int]</duration>
+        <startmonth>[int]</startmonth>
+        <startyear>[int]</startyear>
+        <decay>[string]</decay>
       </control>
 
 
@@ -51,16 +51,16 @@ Each of the elements shown are user-defined and required for each
 
 4. Start year: the first year of the simulation
 
-5. Decay mode:The |Cyclus| kernel has built-in experimental support for 
+5. Decay mode: The |Cyclus| kernel has built-in experimental support for 
 `Decay <http://fuelcycle.org/devdoc/decay.html>`_ calculations. Materials 
-store the time since their last decay and agents are free to invoke the 
+store the time since their last decay, and agents are free to invoke the 
 decay function on them as desired to decay them to the current simulation 
 time. |Cyclus| can operate in 3 decay modes, with 1 additional mode 
 likely to be added in a future release:
 
-   - 'never', all decay is turned off
-   - 'manual', meaning it is only on if the individual archetype decays their own inventory
-   - 'lazy', which will compute decay only when archetypes fetch a particular composition.
+   - ``never``, all decay is turned off
+   - ``manual``, meaning it is only on if the individual archetype decays their own inventory
+   - ``lazy``, which will compute decay only when archetypes fetch a particular composition.
 
 There are other `optional parameters <http://fuelcycle.org/user/input_specs/control.html>`_ 
 that could be given but are not in the scope of this tutorial. For simplicity, 
@@ -87,7 +87,7 @@ decay of materials.
 
 Activity: Set Simulation Parameters
 -----------------------------------
-Using the simulation control template above and the table below, let's fill in the template 
+Using the simulation control template above, let's fill in the template 
 with the variables listed in the table below in your favorite text editor.
 
 +-------------------+---------------+---------------------------------+
@@ -108,7 +108,7 @@ the rest of the simulation parameter blocks (commodities, facilities, regions,
 institutions, and recipe blocks).
 
 Check: Complete Control block
-+++++++++++++++++++++++++++++++
+------------------------------
 
 The control section of your input file should now look like: