diff --git a/charts/helm.md b/charts/helm.md
index 542b0a1..a4c68ff 100644
--- a/charts/helm.md
+++ b/charts/helm.md
@@ -17,10 +17,10 @@
 and `xos-gui`). This can be useful if you want to work on just the
 CORD data models, without any backend components.
 
-The `xos-services` and `xos-profile` directories contain helm
+The `xos-services` and `xos-profiles` directories contain helm
 charts for individual services and profiles (a mesh of services),
 respectively. While it is possible to use Helm to bring up an
-individual service, typically collections of related services are
+individual service, collections of related services are typically
 installed as a unit; we call this unit a *profile.* Looking in the
 `xos-profiles` directory, `rcord-lite` is an example profile. It
 corresponds to R-CORD, and inspecting its `requirements.yaml`
@@ -94,9 +94,8 @@
 
 ## CORD Example Values
 
-As you may have noticed, there is an `example` folder
-in the `helm-chart` repository.
-The files contained in that repository are examples of possible overrides
+There is an `example` directory in the `helm-chart` repository.
+The files contained in that directory are examples of possible overrides
 to obtain a custom deployment.
 
 For example, it is possible to deploy a single instance of `kafka`,
diff --git a/developer/platform.md b/developer/platform.md
index 677f4ac..25b387f 100644
--- a/developer/platform.md
+++ b/developer/platform.md
@@ -1,8 +1,8 @@
 # Platform Services
 
-In CORD, everything is a service, including the "platform" that provides
-the substrate on top of which other services run. This includes infrastructure
-services like Kubernetes and OpenStack, SDN controllers like ONOS, and
-overlay services like VTN. This section includes information about how these
-platform-level services are integrated into CORD, and the role they plan in
-supporting other services.
+Everything is a service in CORD, including the "platform" on top of
+which other services run. This includes infrastructure services like
+Kubernetes and OpenStack, SDN controllers like ONOS, and overlay
+services like VTN. This section includes information about how these
+platform-level services are integrated into CORD, and the role they play
+in supporting other services.
diff --git a/prereqs/docker-registry.md b/prereqs/docker-registry.md
index 97a409e..2b7c74d 100644
--- a/prereqs/docker-registry.md
+++ b/prereqs/docker-registry.md
@@ -1,8 +1,8 @@
 # Docker Registry (optional)
 
-The guide describes how to install an **insecure** *docker registry* in Kubernetes, using the standard Kubernetes helm charts.
+The section describes how to install an **insecure** *docker registry* in Kubernetes, using the standard Kubernetes helm charts.
 
-Local docker registries can be used to push container images directly to the cluster,
+A local docker registry can be used to push container images directly to the cluster,
 which could be useful for example in the following cases:
 
 * The CORD POD has no Internet access, so container images cannot be downloaded directly from DockerHub to the POD.
@@ -11,7 +11,7 @@
 
 More informations about docker registries can be found at <https://docs.docker.com/registry/>.
 
-> NOTE: *Insecure* registries can be used for development, POCs or lab trials. **You should not use this in production.** There are planty of documents online that guide you through secure registries setup.
+> **Note:** *Insecure* registries can be used for development, POCs or lab trials. **You should not use this in production.** There are planty of documents online that guide you through secure registry setup.
 
 ## Deploy a Registry Using Helm
 
@@ -45,6 +45,6 @@
 Simply modify the values as needed, uninstall the containers previously deployed,
 and deploy them again.
 
-> **NOTE**: it's better to extend the existing helm charts, rather than directly modifying them. This way you can keep the original configuration as it is, and just override some values when needed. You can do this by writing your additional configuration yaml file, and parsing it as needed, adding -f my-additional-config.yml to your helm commands.
+> **Note**: It is better to extend the existing helm charts, rather than directly modifying them. This way you can keep the original configuration as it is, and just override some values when needed. You can do this by writing your additional configuration yaml file, and parsing it as needed, adding `-f my-additional-config.yml` to your helm commands.
 
 The full CORD helm charts reference documentation is available [here](../charts/helm.md).
diff --git a/prereqs/hardware.md b/prereqs/hardware.md
index 5af720b..f29c1fc 100644
--- a/prereqs/hardware.md
+++ b/prereqs/hardware.md
@@ -4,24 +4,49 @@
 
 ## Generic Hardware Guidelines
 
-* **Compute machines**: CORD can be in principle deployed both on any x86 machine, either physical or virtual. For development, demos or lab trials you may want to use only one machine (even your laptop could be fine, as long as it can provide enough hardware resources). For more realistic deployments it's anyway suggested to use at least three machines; better if all equals to one each other. The characteristics of these machines depends by lots of factors. At high level, at the very minimum, each machine should have a 4 cores CPU, 32GB of RAM and 100G of disk capacity. More sophisticated use-cases, for example M-CORD require more resources. Look at paragraphs below for more informations.
+* **Compute Machines**: CORD canin principle be deployed on any x86
+  machine, either physical or virtual. For development, demos or lab
+  trials you may want to use only one machine (even your laptop could
+  be fine, as long as it has enough resources). For more realistic
+  deployments, we suggest using at least three machines (preferably
+  all the same). The characteristics of these machines depends several
+  factors. At the very minimum, each machine should have a 4 cores
+  CPU, 32GB of RAM, and 100G of disk capacity. More sophisticated
+  use-cases, for example M-CORD, require more resources (see below).
 
-* **Network cards**: Whatever server you want to use, it should have at the very minimum a 1G network interface for management.
+* **Network Cards**: For whatever server use, it should have at the
+  very minimum a 1G network interface for management.
 
-* **Fabric switches**: Fabric switches should be compatible with the ONOS Trellis application that controls them. In this case, it's strongly suggested to stick with one of the models suggested, depending on the requirements. 10G switches are usually preferred for initial functional tests / lab deployments, since cheaper. Moreover, 10G ports can be usually downgraded to 1G speed, and the user can connect copper SFPs to them. The number of switches largely depends by your needs. For basic scenarios one may be enough, for more complete fabric tests, it's suggested to use at least four switches. More for more complex deployments. Developers sometimes emulate the fabric in software (using Mininet), but this can only apply to specific use-cases.
+* **Fabric Switches**: Fabric switches should be compatible with the
+  ONOS Trellis application that controls them. We strongly recommend
+  using one of the tested models suggested. 10G switches are usually
+  preferred for initial functional tests and lab deployments since
+  they are less expensive. Moreover, 10G ports can be usually
+  downgraded to 1G speed, and it's possible to connect them using
+  copper SFPs. The number of switches largely depends by your needs.
+  For basic scenarios one may be enough. For more complete fabric
+  tests, we recommend at least four switches. Developers sometimes
+  emulate the fabric in software (e.g., using Mininet), but this applies
+  only to specific use-cases.
 
-* **Access equipment**: At the moment, both R-CORD and M-CORD work with very specific access equipment. It's strongly suggested to stick with the models suggested in the following paragraphs.
+* **Access Devices**: At the moment, both R-CORD and M-CORD work
+  with very specific access devices, as described below. We strongly
+  recommend using these tested devices.
 
-* **Optics and cabling**: Some hardware may be picky on the optics. Both optics and cable models tested by the community are provided below.
+* **Optics and Cabling**: Some hardware may be picky about the optics.
+  Both optics and cable models tested by the community are provided below.
 
-* **Other**: Besides all above, you will need a development/management machine and a L2 management swich to connect things together. Usually a laptop is enough for the former, and a legacy L2 switch is enough for the latter.
+* **Other**: In addition to the above, you will need a
+  development/management machine and an L2 management swich to
+  connect things together. Usually a laptop is enough for the former,
+  and a legacy L2 switch is enough for the latter.
 
-## Suggested Hardware
+## Recommended Hardware
 
 Following is a list of hardware that people from the ONF community
 have tested over time in lab trials.
 
-* **Compute machines**
+* **Compute Machines**
     * OCP Inspired&trade; QuantaGrid D51B-1U server. Each
     server is configured with 2x Intel E5-2630 v4 10C 2.2GHz 85W, 64GB of RAM 2133MHz DDR4, 2x 500GB HDD, and a 40 Gig adapter.
 
@@ -36,7 +61,7 @@
         * OCP Accepted&trade; EdgeCore AS7712-32X
         * QuantaMesh BMS T7032-IX1/IX1B
 
-* **Fabric optics and DACs**
+* **Fabric Optics and DACs**
     * **10G DACs**
         * Robofiber QSFP-10G-03C SFP+ 10G direct attach passive
         copper cable, 3m length - S/N: SFP-10G-03C
@@ -44,7 +69,7 @@
         * Robofiber QSFP-40G-03C QSFP+ 40G direct attach passive
         copper cable, 3m length - S/N: QSFP-40G-03C
 
-* **R-CORD access equipment and optics**
+* **R-CORD Access Devices and Optics**
     * **XGS-PON**
         * **OLT**: EdgeCore ASFVOLT16 (for more info <bartek_raszczyk@edge-core.com>)
         * Compatible **OLT optics**
@@ -54,7 +79,7 @@
         * Compatible **ONU optics**
             * Hisense/Ligent: LTF7225-BC, LTF7225-BH+
 
-* **M-CORD specific requirements**
+* **M-CORD Specific Requirements**
     * **Servers**: Some components of CORD require at least a Intel XEON CPU with Haswell microarchitecture or better.
     * **eNodeBs**:
         * Cavium Octeon Fusion CNF7100 (for more info <kin-yip.liu@cavium.com>)
diff --git a/prereqs/helm.md b/prereqs/helm.md
index 1fb5b6b..9c8ded4 100644
--- a/prereqs/helm.md
+++ b/prereqs/helm.md
@@ -42,5 +42,5 @@
 ## Done?
 
 Once you are done, you are ready to deploy CORD components using their
-helm charts! See [Bringup Up CORD](../profiles/intro.md). For more detailed
+helm charts! See [Bringing Up CORD](../profiles/intro.md). For more detailed
 information, see the [helm chart reference guide](../charts/helm.md).
diff --git a/prereqs/k8s-multi-node.md b/prereqs/k8s-multi-node.md
index 48ed502..d606416 100644
--- a/prereqs/k8s-multi-node.md
+++ b/prereqs/k8s-multi-node.md
@@ -16,12 +16,12 @@
 
 ## Requirements
 
-* **Operator machine** (1x, either physical or virtual machine)
+* **Operator/Developer Machine** (1x, either physical or virtual machine)
     * Has Git installed
     * Has Python3 installed (<https://www.python.org/downloads/>)
-    * Has Stable version of Ansible installed (<http://docs.ansible.com/ansible/latest/intro_installation.html>)
+    * Has a stable version of Ansible installed (<http://docs.ansible.com/ansible/latest/intro_installation.html>)
     * Is able to reach the target servers (ssh into them)
-* **Target machines** (at least 3x, either physical or virtual machines)
+* **Target/Cluster Machines** (at least 3x, either physical or virtual machines)
     * Run Ubuntu 16.04 server
     * Able to communicate together (ping one each other)
     * Have the same user *cord* configured, that you can use to remotely access them from the operator machine