diff --git a/source/core/index-ttl.txt b/source/core/index-ttl.txt
index 83d96d1d472..f9f55186eaa 100644
--- a/source/core/index-ttl.txt
+++ b/source/core/index-ttl.txt
@@ -10,9 +10,9 @@ TTL Indexes
 
 TTL indexes are special indexes that MongoDB can use to automatically
 remove documents from a collection after a certain amount of
-time. This is ideal for some types of information like machine
+time. This is ideal for certain types of information like machine
 generated event data, logs, and session information that only need to
-persist in a database for a limited amount of time.
+persist in a database for a finite amount of time.
 
 Considerations
 --------------
diff --git a/source/core/indexes-introduction.txt b/source/core/indexes-introduction.txt
index d3b3888f4e5..f5c957e4c56 100644
--- a/source/core/indexes-introduction.txt
+++ b/source/core/indexes-introduction.txt
@@ -190,6 +190,17 @@ You can combine the sparse index option with the unique index option
 to reject documents that have duplicate values for a field but ignore
 documents that do not have the indexed key.
 
+TTL Indexes
+~~~~~~~~~~~
+
+:doc:`TTL indexes </core/index-ttl>` are special indexes that MongoDB
+can use to automatically remove documents from a collection after a
+certain amount of time. This is ideal for certain types of information
+like machine generated event data, logs, and session information that
+only need to persist in a database for a finite amount of time.
+
+See: :doc:`/tutorial/expire-data` for implementation instructions.
+
 Index Intersection
 ------------------
 
diff --git a/source/includes/toc-sharded-cluster-architectures.yaml b/source/includes/toc-sharded-cluster-architectures.yaml
index c9eebc04696..ccaf5c23788 100644
--- a/source/includes/toc-sharded-cluster-architectures.yaml
+++ b/source/includes/toc-sharded-cluster-architectures.yaml
@@ -4,11 +4,11 @@ description: |
 ---
 file: /core/sharded-cluster-architectures-production
 description: |
-  Sharded cluster for production has component requirements to provide
-  redundancy and high availability.
+  Outlines the components required to deploy a redundant and 
+  highly available sharded cluster.
 ---
 file: /core/sharded-cluster-architectures-test
 description: |
-  Sharded clusters for testing and development can have
+  Sharded clusters for testing and development can include
   fewer components.
 ...
diff --git a/source/reference/operator/aggregation/group.txt b/source/reference/operator/aggregation/group.txt
index 7e1a407b0f3..f6ccf5e080d 100644
--- a/source/reference/operator/aggregation/group.txt
+++ b/source/reference/operator/aggregation/group.txt
@@ -240,3 +240,7 @@ The operation returns the following documents:
           { "_id" : 8645, "title" : "Eclogues", "author" : "Dante", "copies" : 2 }
         ]
    }
+
+.. seealso:: The :doc:`/tutorial/aggregation-zip-code-data-set`
+   tutorial provides an extensive example of the :pipeline:`$group`
+   operator in a common use case. 
diff --git a/source/reference/operator/query/all.txt b/source/reference/operator/query/all.txt
index a794c6235b6..55d15ce0c6b 100644
--- a/source/reference/operator/query/all.txt
+++ b/source/reference/operator/query/all.txt
@@ -231,13 +231,13 @@ you may use the :query:`$all` operator to select against a non-array
 
 .. code-block:: javascript
 
-   db.inventory.find( { qty: { $all: [ 50 ] } } )
+   db.inventory.find( { "qty.num": { $all: [ 50 ] } } )
 
 **However**, use the following form to express the same query:
 
 .. code-block:: javascript
 
-   db.inventory.find( { qty: 50 } )
+   db.inventory.find( { "qty.num" : 50 } )
 
 Both queries will select all documents in the ``inventory``
 collection where the value of the ``qty`` field equals ``50``.
diff --git a/source/tutorial/create-a-unique-index.txt b/source/tutorial/create-a-unique-index.txt
index 961efdac259..99ab9a2a9a3 100644
--- a/source/tutorial/create-a-unique-index.txt
+++ b/source/tutorial/create-a-unique-index.txt
@@ -38,10 +38,14 @@ The :ref:`_id index <index-type-id>` is a unique index. In some
 situations you may consider using the ``_id`` field itself for this kind
 of data rather than using a unique index on another field.
 
-In many situations you will want to combine the ``unique`` constraint
-with the ``sparse`` option. When MongoDB indexes a field, if a
+If a
 document does not have a value for a field, the index entry for that
-item will be ``null``. Since unique indexes cannot have duplicate
+item will be ``null`` in any index that includes it. 
+Thus, in many situations you will want to combine the ``unique`` constraint
+with the ``sparse`` option. ``Sparse`` indexes skip over any
+document that is missing the indexed field, rather than storing
+``null`` for the index entry. Since unique indexes
+cannot have duplicate
 values for a field, without the ``sparse`` option, MongoDB will reject
 the second document and all subsequent documents without the indexed
 field. Consider the following prototype.