diff --git a/docs/source/request_system.rst b/docs/source/request_system.rst
index 41d8eec4..09e46380 100644
--- a/docs/source/request_system.rst
+++ b/docs/source/request_system.rst
@@ -28,7 +28,7 @@ Just like other aspects of SimComponent, the request typess are not managed cent
         Since ``restart`` is a defined request type in the service's own RequestManager, the service performs a restart.
 
 Technical Detail
-================
+----------------
 
 This system was achieved by implementing two classes, :py:class:`primaite.simulator.core.RequestType`, and :py:class:`primaite.simulator.core.RequestManager`.
 
@@ -38,7 +38,7 @@ This system was achieved by implementing two classes, :py:class:`primaite.simula
 The ``RequestType`` object stores a reference to a method that executes the request, for example a node could have a request type that stores a reference to ``self.turn_on()``. Technically, this can be any callable that accepts `request, context` as it's parameters. In practice, this is often defined using ``lambda`` functions within a component's ``self._init_request_manager()`` method. Optionally, the ``RequestType`` object can also hold a validator that will permit/deny the request depending on context.
 
 ``RequestManager``
--------------
+------------------
 
 The ``RequestManager`` object stores a mapping between strings and request types. It is responsible for processing the request and passing it down the ownership tree. Technically, the ``RequestManager`` is itself a callable that accepts `request, context` tuple, and so it can be chained with other request managers.
 
diff --git a/docs/source/state_system.rst b/docs/source/state_system.rst
index b8a9624e..de4cd093 100644
--- a/docs/source/state_system.rst
+++ b/docs/source/state_system.rst
@@ -5,9 +5,9 @@
 Simulation State
 ==============
 
-``SimComponent``s in the simulation have a method called ``describe_state`` which returns a dictionary of the state of the component. This is used to report pertinent data that could impact agent's actions or rewards. For instance, the name and health status of a node is reported, which can be used by a reward function to punish corrupted or compromised nodes and reward healthy nodes. Each ``SimComponent`` reports not only it's own attributes in the state but also that of its child components. I.e. a computer node will report the state of its ``FileSystem``, and the ``FileSystem`` will report the state of its files and folders. This happens by recursively calling childrens' own ``describe_state`` methods.
+``SimComponent`` in the simulation have a method called ``describe_state`` which returns a dictionary of the state of the component. This is used to report pertinent data that could impact agent's actions or rewards. For instance, the name and health status of a node is reported, which can be used by a reward function to punish corrupted or compromised nodes and reward healthy nodes. Each ``SimComponent`` reports not only it's own attributes in the state but also that of its child components. I.e. a computer node will report the state of its ``FileSystem``, and the ``FileSystem`` will report the state of its files and folders. This happens by recursively calling childrens' own ``describe_state`` methods.
 
-The game layer calls ``describe_state`` on the trunk ``SimComponent`` (the top-level parent) and then pass the state to the agents once per simulation step. For this reason, all ``SimComponent``s must have a ``describe_state`` method, and they must all be linked to the trunk ``SimComponent``.
+The game layer calls ``describe_state`` on the trunk ``SimComponent`` (the top-level parent) and then pass the state to the agents once per simulation step. For this reason, all ``SimComponent`` must have a ``describe_state`` method, and they must all be linked to the trunk ``SimComponent``.
 
 This code snippet demonstrates how the state information is defined within the ``SimComponent`` class: