diff --git a/onramp/directory.rst b/onramp/directory.rst
index 2469771..9c7f7bc 100644
--- a/onramp/directory.rst
+++ b/onramp/directory.rst
@@ -7,8 +7,8 @@
 of the development pipeline (e.g., source code, deployment artifacts,
 configuration specs).  This rest of this section identifies all the
 Aether-related repositories, with the OnRamp repos listed at the end
-serving as the starting point for anyone that wants to come
-up-to-speed on the rest of the system.
+serving as the starting point for anyone who wants to come
+up to speed on the rest of the system.
 
 .. admonition:: Troubleshooting Hint
 
@@ -88,7 +88,7 @@
 <https://containerd.io/>`__ runtime system instead of Docker. This is
 transparent to anyone using Aether, which manages containers
 indirectly through Kubernetes (e.g., using ``kubectl``), but does
-impact anyone that directly depends on the Docker toolchain. Also note
+impact anyone who directly depends on the Docker toolchain. Also note
 that while Aether documentation often refers its use of "Docker
 containers," it is now more accurate to say that Aether uses
 `OCI-Compliant containers <https://opencontainers.org/>`__.
@@ -108,6 +108,11 @@
 
  | https://gerrit.opencord.org/plugins/gitiles/aether-system-tests
 
+The specification for the CI pipeline, which invokes these QA tests,
+gates merge requests, and publishes artifacts, can be found here:
+
+ | https://gerrit.opencord.org/plugins/gitiles/aether-ci-management
+
 For more information about Aether's CI pipeline, including its QA and
 version control strategy, we recommend the Lifecycle Management
 chapter of our companion Edge Cloud Operations book.
@@ -150,7 +155,7 @@
 other repos as submodules. Note that each of the submodules is
 self-contained if you are interested in deploying just that subsystem,
 but this guide approaches the deployment challenge from an
-integrated/end-to-end perspective.
+integrated, end-to-end perspective.
 
 Because OnRamp uses Ansible as its primary deployment tool, a general
 understanding of Ansible is helpful (see the suggested reference).
diff --git a/onramp/gnb.rst b/onramp/gnb.rst
index b6f548d..9f3c8e7 100644
--- a/onramp/gnb.rst
+++ b/onramp/gnb.rst
@@ -10,9 +10,9 @@
 RAN requires the following hardware:
 
 * One or more 5G small cell radios (e.g., MOSO CANOPY 5G INDOOR SMALL CELL).
-* One or more 5G-capable UEs (e.g., unlocked Moto G 5G).
+* One or more 5G-capable UEs (e.g., unlocked Motorola Moto G 5G).
 * A SIM reader/writer and associated software (e.g., OYEITIMES MCR3516).
-* A set of programmable SIM cards (5 blank cards included with reader).
+* A set of programmable SIM cards (blank cards likely included with reader/writer).
 
 There are multiple options for each component, but finding a
 combination that works together can be challenging. This section makes
@@ -20,6 +20,10 @@
 simplicity, we pared the above list back to a single example for each
 item, but these should not be interpreted as the only possibility.
 
+Note also that our example relies on the availability of spectrum in
+the CBRS band, which is available in the United States. Spectrum
+options are likely to be different in other countries.
+
 .. admonition:: Troubleshooting Hint
 
   We are tracking community experience with different hardware in the
@@ -37,18 +41,19 @@
    $ cd vars
    $ cp main-gNB.yml main.yml
 
-This section focuses on bringing up a single gNB that is on the same
-L2 network as the Aether cluster. In our running example, this implies
-both are on subnet ``10.76.28.0/24``.
+This section focuses on bringing up a single gNB, and assumes that gNB
+is on the same L2 network as the Aether cluster. In our running
+example, this implies both are on subnet ``10.76.28.0/24``.
 
 .. admonition:: Troubleshooting Hint
 
-  Physical gNBs connect to SD-Core (both the AMF in the control plane
-  and the UPF in the user plane) in exactly the same way as external
-  instances of gNBsim. Going through the process of bringing up gNBsim
-  in a second server, as described in the previous section, is a good
-  way to validate that your Core is "gNB-ready".
-
+  Be aware that enterprise and campus networks have been known to
+  filter packets in ways that impact gNB-to-Core connectivity.
+  Fortunately, physical gNBs connect to SD-Core (both the AMF in the
+  control plane and the UPF in the user plane) in exactly the same way
+  as external instances of gNBsim. Going through the process of
+  bringing up gNBsim in a second server, as described in the previous
+  section, is a good way to validate that your Core is "gNB-ready".
 
 Modify Configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/onramp/gnbsim.rst b/onramp/gnbsim.rst
index f1c1514..e841495 100644
--- a/onramp/gnbsim.rst
+++ b/onramp/gnbsim.rst
@@ -3,7 +3,7 @@
 
 gNBsim emulates a 5G RAN, generating (mostly) Control Plane traffic
 that can be directed at SD-Core. This section describes how to
-configure gNBsim, so as to both customize and scale the workload it
+configure gNBsim to customize and scale the workload it
 generates. We assume gNBsim runs in one or more servers, independent
 of the server(s) that host SD-Core. These servers are specified in the
 ``hosts.ini`` file, as described in the section on Scaling Aether. This
diff --git a/onramp/inspect.rst b/onramp/inspect.rst
index de56601..3394c4d 100644
--- a/onramp/inspect.rst
+++ b/onramp/inspect.rst
@@ -88,7 +88,7 @@
 
    $ make aether-amp-uninstall
 
-Viewing Logs
+View Logs
 ~~~~~~~~~~~~~~~~
 
 You've already seen the log file generated by gNBsim for each
diff --git a/onramp/scale.rst b/onramp/scale.rst
index b5cbd50..6f5feea 100644
--- a/onramp/scale.rst
+++ b/onramp/scale.rst
@@ -49,8 +49,8 @@
 gNBsim workload generator (gNBsim scales across multiple Docker
 containers, but these containers are **not** managed by Kubernetes).
 Note that having ``master_nodes`` and ``gnbsim_nodes`` contain exactly
-one/common server is what triggers Ansible to instantiate the Quick
-Start configuration.
+one common server (as we did previously) is what triggers Ansible to
+instantiate the Quick Start configuration.
 
 You need to modify ``hosts.ini`` to match your target deployment.
 Once you've done that (and assuming you deleted your earlier Quick
@@ -61,7 +61,7 @@
 
    $ make aether-k8s-install
    $ make aether-5gc-install
-   $ aeither-amp-install
+   $ make aether-amp-install
    $ make aether-gnbsim-install
    $ make aether-gnbsim-run
 
diff --git a/onramp/start.rst b/onramp/start.rst
index 54be6ca..3990965 100644
--- a/onramp/start.rst
+++ b/onramp/start.rst
@@ -7,10 +7,10 @@
 5G Core. It assumes a low-end server that meets the following
 requirements:
 
-* Haswell CPU (or newer), with at least 4 CPUs and 16GB RAM.
+* Haswell CPU (or newer), with at least 4 CPU cores and 16GB RAM.
 * Clean install of Ubuntu 20.04 or 22.04, with 5.15 (or later) kernel.
 
-For example, something like an Intel NUC is more than enough to get
+For example, something like an Intel NUC is likely more than enough to get
 started.
 
 While it's possible to use OnRamp to deploy Aether on a laptop (e.g.,
@@ -167,7 +167,7 @@
    data_iface: ens18
 
 need to be edited to replace ``ens18`` with the device interface for
-you server, and the line specifying the IP address of the Core's AMF
+your server, and the line specifying the IP address of the Core's AMF
 needs to be edited to reflect your server's IP address:
 
 .. code-block::