cleaned up some inconsistencies

Change-Id: I5f8d3c5f05eb3a531b75960b01b87eb329b93445
diff --git a/SUMMARY.md b/SUMMARY.md
index c42479d..9c2393b 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -1,7 +1,7 @@
 # Summary
 
 * [Overview](overview.md)
-    * [Navigating the Guide](navigate.md)
+    * [Navigating CORD](navigate.md)
     * [Quick Start](quickstart.md)
 * [Installation Guide](README.md)
     * [Prerequisites](prereqs/README.md)
diff --git a/developer/workflows.md b/developer/workflows.md
index aa8cf5f..ea8b5da 100644
--- a/developer/workflows.md
+++ b/developer/workflows.md
@@ -31,7 +31,7 @@
 ```
 
 In this folder you can choose from the different charts which one to deploy.
-For example to deploy rcord-lite you can follow [this guide](../profiles/rcord/install.md)
+For example to deploy R-CORD you can follow [this guide](../profiles/rcord/install.md)
 
 ### Deploy a Single Instance of Kafka
 
diff --git a/navigate.md b/navigate.md
index a92bb01..ea73b69 100644
--- a/navigate.md
+++ b/navigate.md
@@ -1,20 +1,8 @@
-# Navigating the Guide
+# Navigating CORD 
 
-The guide is organized around the major stages in the lifecycle of CORD:
-
-* [Installation](README.md): Installing (and later upgrading) CORD.
-* [Operations](operating_cord/operating_cord.md): Operating an already
-  installed CORD deployment.
-* [Development](developer/developer.md): Developing new functionality
-  to be included in CORD.
-* [Testing](cord-tester/README.md): Testing functionality to be
- included in CORD.
-
-## Navigating CORD
-
-These are all fairly obvious. What's less obvious is the relationship among
-the toolset (and corresponding specification files) used for each stage.
-Understanding these relationships is helpful in navigating CORD.
+The relationship between installing, operating, and developing
+CORD—and the corresponding toolsets and specification files
+used by each stage—is helpful in navigating CORD.
 
 * **Installation (Helm):** Installing CORD means installing a collection
   of Docker containers in a Kubernetes cluster. We use Helm to carry out
@@ -24,7 +12,7 @@
   More information about `helm-charts` can be found [here](charts/helm.md).
 
 * **Operations (TOSCA):** A running CORD POD supports multiple Northbound
-  Interfaces (e.g,. a GUI and REST API), but we typically use `TOSCA` to specify
+  Interfaces (e.g., a GUI and REST API), but we typically use `TOSCA` to specify
   a workflow for configuring and provisioning a running system. A freshly
   installed CORD POD has a set of control plane and platform level containers
   running (e.g., XOS, ONOS, OpenStack), but until provisioned using `TOSCA`,
@@ -41,13 +29,6 @@
   other details about on-boarding a service) can be found
   [here](xos/dev/xproto.md).
 
-* **Testing (Jenkins):** Full CORD PODS (as well as individual components
-  of CORD) are installed on both physical and virtual environment, and run
-  through a series of tests. Full PODS are tested nightly, and individual
-  components are tested upon every commit Gerrit. These tests are specified
-  using `Jenkinfiles` and `JJB`. An overview of how CORD is tested can be found
-  [here](cord-tester/README.md).
-
 These tools and containers are inter-related as follows:
 
 * An initial install brings up a set of XOS-related containers (e.g., `xos-core`,
@@ -68,7 +49,7 @@
   package are still specified in the TOSCA workflow.
 
 * Every service (whether implemented in Docker, OpenStack, or ONOS)
-  has counter-part *synchronizer* container running as part of the CORD
+  has a counter-part *synchronizer* container running as part of the CORD
   control plane (e.g., `volt-synchronizer` for the vOLT service). Typically,
   the helm-chart for a service launches this synchronizer container, whereas
   the TOSCA worflow creates, provisions, and initializes the backend container,
diff --git a/operating_cord/general.md b/operating_cord/general.md
index c5ae0d3..154cb47 100644
--- a/operating_cord/general.md
+++ b/operating_cord/general.md
@@ -5,6 +5,8 @@
 interface, and they are auto-generated from the models loaded into 
 CORD, as described [elsewhere](../xos/README.md). Most notably:
 
+* A graphical interface is documented [here](gui.md).
+
 * A RESTful version of this API is documented [here](rest_apis.md). 
 
 * A TOSCA version is typically used to configure and provision a 
diff --git a/operating_cord/gui.md b/operating_cord/gui.md
index 48985ad..6a5db25 100644
--- a/operating_cord/gui.md
+++ b/operating_cord/gui.md
@@ -1,13 +1,13 @@
 # GUI
 
-The GUI is very useful for development and demos. At the moment it's not
-designed to support the amount of datas that we expect to have in production-like
+The GUI is useful for development and demos. At the moment it is not
+designed to support the scale of data one might expect in a production
 deployment.
 
-## How to acces the GUI
+## How to Acces the GUI
 
-Once you have CORD up and running you can find the port on which the GUI is
-exposed by running:
+Once you have CORD up and running, you can find the port on which the
+GUI is available by running:
 
 ```shell
 kubectl get service xos-gui
@@ -17,20 +17,21 @@
 xos-gui   NodePort   10.102.239.199   <none>        4000:30001/TCP   2h
 ```
 
-> By default the GUI is exposed on port `30001`
+By default, the GUI can be accessed on port `30001`
 
 To connect to the GUI you can just open a browser at `<cluster-ip>:<gui-port`,
 where `cluster-ip` is the ip of any node in your kubernetes cluster.
 
-> Username and password for the GUI are defined in the [`xos-core`](../charts/xos-core.md) helm chart.
+The *username* and *password* for the GUI are defined in
+the [`xos-core`](../charts/xos-core.md) helm chart.
 
-### Opening the GUI in minikube
+## Opening the GUI in minikube
 
-The above workflow will work just the same way when running on `minikube`, but
+The above works the same way when running on `minikube`, but
 this helper is also available:
 
 ```shell
 minikube service xos-gui
 ```
 
-> This command will open the GUI in you default browser
\ No newline at end of file
+This command opens the GUI in your default browser.
diff --git a/overview.md b/overview.md
index 8119167..564dcaa 100644
--- a/overview.md
+++ b/overview.md
@@ -9,7 +9,22 @@
 and design notes that have shaped [CORD's
 architecture](https://wiki.opencord.org/display/CORD/Documentation).
 
-## Making Changes to Documentation
+## Navigating the Guide
+
+The guide is organized around the major stages in the lifecycle of CORD:
+
+* [Installation](README.md): Installing (and later upgrading) CORD. 
+* [Operations](operating_cord/operating_cord.md): Operating an already 
+  installed CORD deployment. 
+* [Development](developer/developer.md): Developing new functionality 
+  to be included in CORD. 
+* [Testing](cord-tester/README.md): Testing functionality to be 
+ included in CORD. 
+
+These are all fairly obvious. What's less obvious is the relationship among 
+these stages, which is helpful in [Navigating CORD](navigate.md).
+
+## Making Changes to the Guide
 
 The [http://guide.opencord.org](http://guide.opencord.org) website is built
 using the [GitBook Toolchain](https://toolchain.gitbook.com/), with the
diff --git a/profiles/rcord/configuration.md b/profiles/rcord/configuration.md
index 3858d92..097d1be 100644
--- a/profiles/rcord/configuration.md
+++ b/profiles/rcord/configuration.md
@@ -1,7 +1,7 @@
 # R-CORD Configuration 
 
-Once all the components needed for RCORD-Lite are up and running on your POD,
-you'll need to configure XOS with the proper configuration. 
+Once all the components needed for the R-CORD profile are up and
+running on your POD, you'll need to configure XOS with the proper configuration. 
 Since this configuration is environment specific, you'll need to create your own,
 but the following can serve as a reference for it:
 
diff --git a/profiles/rcord/install.md b/profiles/rcord/install.md
index 0231ae1..1bcae02 100644
--- a/profiles/rcord/install.md
+++ b/profiles/rcord/install.md
@@ -2,9 +2,9 @@
 
 The latest version of R-CORD differs from versions included in earlier
 releases in that it does not include the vSG service. In the code this
-configuration is called RCORD-Lite, but since it is the only version
+configuration is called `rcord-lite`, but since it is the only version
 of Residential CORD currently supported, we usually simply call it
-"R-CORD."
+the "R-CORD" profile.
 
 ## Prerequisites
 
@@ -15,25 +15,25 @@
 
 ## CORD Components
 
-RCORD-Lite has dependencies on this charts, so they need to be installed first:
+R-CORD has dependencies on this charts, so they need to be installed first:
 
 - [xos-core](../../charts/xos-core.md)
 - [onos-fabric](../../charts/onos.md#onos-fabric)
 - [onos-voltha](../../charts/onos.md#onos-voltha)
 
-## Install the RCORD-Lite Helm Chart
+## Installing the R-CORD Profile
 
 ```shell
 helm dep update xos-profiles/rcord-lite
 helm install -n rcord-lite xos-profiles/rcord-lite
 ```
 
-Now that the your RCORD-Lite deployment is complete, please read this 
-to understand how to configure it: [Configure RCORD-Lite](configuration.md)
+Now that your R-CORD deployment is complete, please read this 
+to understand how to configure it: [Configure R-CORD](configuration.md)
 
-## How to Customize the RCORD-Lite Helm Chart
+## Customizing an R-CORD Install
 
-Define a `my-rcord-lite-values.yaml` that looks like:
+Define a `my-rcord-values.yaml` that looks like:
 
 ```yaml
 # in service charts
@@ -60,6 +60,6 @@
 and use it during the installation with:
 
 ```shell
-helm install -n rcord-lite xos-profiles/rcord-lite -f my-rcord-lite-values.yaml
+helm install -n rcord-lite xos-profiles/rcord-lite -f my-rcord-values.yaml
 ```