multiple minor grammatical edits

Arch-topics.md

@@ -70,7 +70,7 @@ Often, code is written and tested first without consideration for configurabilit
 
 ### Configuration reader process
 
-At the heart of the Essentials framework is the configuration system. While not technically necessary for a system written with the Essentials framework, it is the preferred and currently, the only way to build an Essentials system. The configuration file is JSON, and well-defined (but not well documented, yet). It is comprised of blocks:
+At the heart of the Essentials framework is the configuration system. While not technically necessary for a system written with the Essentials framework, it is the preferred and, currently, the only way to build an Essentials system. The configuration file is JSON, and well-defined (but not well documented, yet). It is comprised of blocks:
 
 - info (object) Contains metadata about the config file
 - devices (array) Contains, well, the devices we intend to build and load
@@ -78,7 +78,7 @@ At the heart of the Essentials framework is the configuration system. While not
 - sourceLists (object) Used by one or more rooms to represent list(s) of sources for those rooms
 - tieLines (array) Used by the routing system to discover routing between sources and displays
 
-In addition, a downloaded portal config file will most likely be in a template/system form, meaning that the file contains two main objects, representing the template configuration and its system-level overrides. Other metadata, such as Portal UUIDs or URLs may be present.
+In addition, a downloaded Portal config file will most likely be in a template/system form, meaning that the file contains two main objects, representing the template configuration and its system-level overrides. Other metadata, such as Portal UUIDs or URLs may be present.
 
 At startup, the configuration file is read, and a ReadyEvent is fired. Upon being ready, that configuration is loaded by the ConfigReader.LoadConfig() method. The template and system are merged into a single configuration object, and that object is then deserialized into configuration wrapper classes that define most of the structure of the program to be built. (Custom configuration objects were built to allow for better type handling rather than using JToken methods to parse out error-prone property names.)
 
@@ -111,7 +111,7 @@ namespace PepperDash.Essentials.Core.Config
 }
 ```
 
-_Every_ `Device` present must adhere to those five properties plus a properties object. The properties object will have it's own deserialization helpers, depending on what it's structure is.
+_Every_ `Device` present must adhere to those five properties plus a properties object. The properties object will have its own deserialization helpers, depending on what its structure is.
 
 Once the ConfigReader has successfully read and deserialized the config file, then `ControlSystem.Load()` is called. This does the following in order:
 
@@ -121,7 +121,7 @@ Once the ConfigReader has successfully read and deserialized the config file, th
 4. Loads LogoServer
 5. Activation sequence
 
-This ordering ensures that all devices are at least present before building tie lines and rooms. Rooms can be built with their required devices being present. In principle, this could break from the loosely-coupled goal we have described, but it is the most-clear way to build the system in code. The goal is still to build a room class that doesn't have functional dependencies on devices that may not be ready for use.
+This ordering ensures that all devices are at least present before building tie lines and rooms. Rooms can be built without their required devices being present. In principle, this could break from the loosely-coupled goal we have described, but it is the clearest way to build the system in code. The goal is still to build a room class that doesn't have functional dependencies on devices that may not be ready for use.
 
 In each device/room step, a device factory process is called. We call subsequent device factory methods in the various libraries that make up Essentials until one of them returns a functional device. This allows us to break up the factory process into individual libraries, and not have a huge master list of types and build procedures. Here's part of the code:
 
@@ -143,10 +143,10 @@ if (newDev == null)
     newDev = PepperDash.Essentials.Devices.Displays.DisplayDeviceFactory.GetDevice(devConf);
 ```
 
-In each respective factory, or device constructor, the config's properties object is either converted to a config object or read from using `JToken` methods. This builds the device which may be ready to go, or may require activation as described above.
+In each respective factory, or device constructor, the configuration's properties object is either converted to a config object or read from using `JToken` methods. This builds the device which may be ready to go, or may require activation as described above.
 
 A similar process is carried out for rooms, but as of now, the room types are so few that they are all handled in the `ControlSystem.LoadRooms()` method.
 
 _This process will soon be enhanced by a plug-in mechanism that will drill into dynamically-loaded DLLs and load types from factories in those libraries. This is where custom essentials systems will grow from._
 
-After those five steps, the system will be running. That's it.
+After those five steps, the system will be running and ready to use.