#2068: Further typo and formatting changes.

docs/source/game_layer.rst

@@ -26,6 +26,7 @@ Agents
 ^^^^^^
 
 All agents inherit from the :py:class:`primaite.game.agent.interface.AbstractAgent` class, which mandates that they have an ObservationManager, ActionManager, and RewardManager. The agent behaviour depends on the type of agent, but there are two main types:
+
 * RL agents action during each step is decided by an appropriate RL algorithm. The agent within PrimAITE just acts to format and forward actions decided by an RL policy.
 * Deterministic agents perform all of their decision making within the PrimAITE game layer. They typically have a scripted policy which always performs the same action or a rule-based policy which performs actions based on the current state of the simulation. They can have a stochastic element, and their seed will be settable.
 

docs/source/request_system.rst

@@ -5,12 +5,12 @@
 Request System
 ==============
 
-``SimComponent`` in the simulation are decoupled from the agent training logic. However, they still need a managed means of accepting requests to perform actions. For this, they use ``RequestManager`` and ``RequestType``.
+``SimComponent`` objects in the simulation are decoupled from the agent training logic. However, they still need a managed means of accepting requests to perform actions. For this, they use ``RequestManager`` and ``RequestType``.
 
-Just like other aspects of SimComponent, the request typess are not managed centrally for the whole simulation, but instead they are dynamically created and updated based on the nodes, links, and other components that currently exist. This was achieved in the following way:
+Just like other aspects of SimComponent, the request types are not managed centrally for the whole simulation, but instead they are dynamically created and updated based on the nodes, links, and other components that currently exist. This was achieved in the following way:
 
 - API
-    An ``RequestType`` contains two elements:
+    A ``RequestType`` contains two elements:
 
     1. ``request`` - selects which action you want to take on this ``SimComponent``. This is formatted as a list of strings such as `['network', 'node', '<node-uuid>', 'service', '<service-uuid>', 'restart']`.
     2. ``context`` - optional extra information that can be used to decide how to process the request. This is formatted as a dictionary. For example, if the request requires authentication, the context can include information about the user that initiated the request to decide if their permissions are sufficient.

docs/source/simulation_components/system/data_manipulation_bot.rst

@@ -16,15 +16,17 @@ The bot is intended to simulate a malicious actor carrying out attacks like:
 - Dropping tables
 - Deleting records
 - Modifying data
-On a database server by abusing an application's trusted database connectivity.
+on a database server by abusing an application's trusted database connectivity.
 
 Usage
 -----
 
 - Create an instance and call ``configure`` to set:
+
   - Target database server IP
   - Database password (if needed)
   - SQL statement payload
+
 - Call ``run`` to connect and execute the statement.
 
 The bot handles connecting, executing the statement, and disconnecting.

docs/source/simulation_components/system/database_client_server.rst

@@ -17,8 +17,6 @@ Key capabilities
 - Initialises a SQLite database file in the ``Node`` 's ``FileSystem`` upon creation.
 - Handles connecting clients by maintaining a dictionary of connections mapped to session IDs.
 - Authenticates connections using a configurable password.
-- Executes SQL queries against the SQLite database.
-- Returns query results and status codes back to clients.
 - Leverages the Service base class for install/uninstall, status tracking, etc.
 
 Usage
@@ -33,7 +31,6 @@ Implementation
 - Uses SQLite for persistent storage.
 - Creates the database file within the node's file system.
 - Manages client connections in a dictionary by session ID.
-- Processes SQL queries via the SQLite cursor and connection.
 - Returns results and status codes in a standard dictionary format.
 - Extends Service class for integration with ``SoftwareManager``.
 
@@ -46,17 +43,14 @@ Key features
 ^^^^^^^^^^^^
 
 - Connects to the ``DatabaseService`` via the ``SoftwareManager``.
+- Handles connecting and disconnecting.
 - Executes SQL queries and retrieves result sets.
-- Handles connecting, querying, and disconnecting.
-- Provides a simple ``query`` method for running SQL.
-
 
 Usage
 ^^^^^
 
 - Initialise with server IP address and optional password.
 - Connect to the ``DatabaseService`` with ``connect``.
-- Execute SQL queries via ``query``.
 - Retrieve results in a dictionary.
 - Disconnect when finished.
 
@@ -71,6 +65,5 @@ Implementation
 
 - Leverages ``SoftwareManager`` for sending payloads over the network.
 - Connect and disconnect methods manage sessions.
-- Provides easy interface for applications to query database.
 - Payloads serialised as dictionaries for transmission.
 - Extends base Application class.

docs/source/state_system.rst

@@ -5,9 +5,9 @@
 Simulation State
 ==============
 
-``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.
+``SimComponent`` objects in the simulation have a method called ``describe_state`` which return a dictionary of the state of the component. This is used to report pertinent data that could impact an 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`` object reports not only its own attributes in the state but also those 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 the 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`` 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 passes the state to the agents once per simulation step. For this reason, all ``SimComponent`` objetcs 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:
 

src/primaite/exceptions.py

@@ -1,6 +1,6 @@
 # © Crown-owned copyright 2023, Defence Science and Technology Laboratory UK
 class PrimaiteError(Exception):
-    """The root PrimAITe Error."""
+    """The root PrimAITE Error."""
 
     pass