 
 # ## Descent
 #
-# A *decent* is a b-tree operation. It describes a traversal of the b-tree that
-# results in the creation of a cursor and cursor actions, or else balance
-# operation such as a merge or split. We use the term descent to describe both
-# top down and left right traversal of our b-tree.
-#
-# When we navigate to leaf pages of a search b-tree to obtain records, we
+# We use the term *descent* to describe b-tree operations, because all b-tree
+# operations require a descent of the b-tree, a traversal of the b-tree starting
+# from the root. Whenever we are search the tree, insert or delete records, or
+# balance the tree with a page splits and merges, we first begin with a descent
+# of the b-tree, from the root, to find the page we want to act upon.
+#
+# #### Descent as Unit of Work
+#
+# We use the term descent to describe the both traversal of the b-tree and the
+# subsequent actions performed when when the desired page is found.
+# 
+# The descent is the unit of work in our concurrency model.  A descent is
+# analogous to a thread, because when a descent waits on I/O, other descents can
+# make progress.
+#
+# Descents can make progress concurrently, even though Node.js only has a single
+# thread of execution. Descents do not actually make progress in parallel, but
+# their progress can be interleaved. When we descend the tree, we may have to
+# wait for evented I/O to read or write a page. While we wait, we can make
+# progress on another descent in the main thread of execution.
+#
+# Because descents can make interleaved progress, we need to synchronize access
+# to b-tree pages, just as we would with a multi-threaded b-tree implementation.
+# When we descend the b-tree we need to make sure that we do not alter pages
+# that another waiting descent needs to complete its descent when it awakes, nor
+# read pages that a waiting descent had begun to alter before it had to wait.
+#
+# These are race conditions. We use the shared read/exclusive write locks
+# described in the `IO` class above to guard against these race conditions.
+#
+# #### Classes of Descent
+#
+# When we descend to leaf pages of a search b-tree to obtain records, we
 # *search* the b-tree. When we change the size of the b-tree by adding or
 # deleting records we *edit* the b-tree. When we change the structure of the
 # b-tree by splitting or merging pages, we *balance* the b-tree.
 #
+# We talk about search descents, edit descents, and balance descents we we
+# describe the interaction of b-tree operations.
+#
 # We use these terms in this document to save the chore of writing, and the
 # confustion of reading; insert or delete, or split or merge. We also want to
 # draw a distinction between changing the count of records stored in the b-tree,
-# editing, and changing the height of the b-tree, the count of pages, or the
-# choice of keys, balancing.
-#
-# A descent is analogous to a thread, because one can make progress while
-# another descent is waiting on I/O.
-#
-# A decent an make progress while other decents make progress, even though
-# Node.js only has a single thread of execution. When we descend the tree, we
-# may have to wait for evented I/O to read or write a page. While we wait, we
-# can make progress on another descent in the main thread of execution.
-#
-# Because descents can make progress in parallel, we need to synchronize access
-# to b-tree pages, as we would with a multi-threaded b-tree implementation. When
-# we descend the b-tree we need to make sure that we do not alter pages that
-# another waiting descent needs to complete its descent when it awakes, nor read
-# pages that a waiting descent had begun to alter before it had to wait.
-#
-# These are race conditions. We use the shared read/exclusive write locks
-# described in the `IO` class above to guard against these race conditions.
+# *editing*, and changing the height of the b-tree, the count of pages, or the
+# choice of keys, *balancing*.
 #
 # #### Locking on Descent
 #

# to create relationship indexes. You can use Strata to store what ever form of
# JSON suits your needs like NoSQL databases.
#
# It runs anywhere that Node.js runs, in pure JavaScript.
#
# Maybe you need a database server, or maybe Strata is all you need to get your
# next application growing.
#
# ## Terminology
#

# out of memory when they have not been recently referenced. These are behaviors
# that conjure an image of a page of values.
#
# Otherwise, we use common teriminology for *height*, *depth*, *parent*,
# *child*, *split* and *merge*.
#
# There is no hard and fast definition for all the terms. A leaf is a fuzzy
# concept in b-tree literature, for example. We call a page that contains
# records a *leaf page*. We call a non-leaf page a *branch page*. The term
# *order* means different things to different people.  We define the order of a
# branch page to be the maximum number of child pages, while the order of a leaf
# page to be the maximum number of records.
#
# The term *b-tree* itself may not be correct. There are different names for
# b-tree that reflect the variations of implementation, but those distinctions
