 # b-tree. Because of this, and because a lookup takes constant time, we can search
 # for a record in a leaf page using binary search in logorithmic time.
 #
-# The first record of every leaf page must be unique in relation to the first
-# record of every other leaf page. The b-tree will accept records that are
-# dupcliates according to the collation. When we split a page, we cannot cannot
-# choose a partition that has the same value as the first record, since that
-# would violate the unique first record constraint.
-#
-# If a page reaches the maximum leaf page size, filled with records that have
-# the same value according to the collation, the leaf page is cannot split,
-# since no suitable partition exists. The page will be allowed to grow beyond
-# the maximum page size.
+# Leaf pages cannot contain duplicate records. Therefore, the b-tree cannot
+# contain duplicate records. You can simulate duplicate records by adding a
+# series value to your key. The cursor implementation is designed faciliate
+# psuedo-duplicates in this fashion.
+#
+# The first record of every leaf page is the key value of the leaf page. When we
+# delete records from the leaf page, if we delete the first reord, we keep a
+# ghost of the record around, so we will know the key value of the leaf page.
+#
+# If a leaf page exceeds the leaf order, the leaf page is split.
 #
 # ### Branch Pages
 #
-# Branch pages contain links to other pages. To find the a record in the b-tree,
-# we first use branch pages to find the leaf page that contains our record.
-#
-# All pages are identified by a unique page address. The page address is an
-# integer assigned to the page when the page is created. Branch pages link to
-# other pages by storing the address of the referenced page in an array of page
-# addresses. This array of page addresses is essentially an *array of children*.
-#
-# A branch page orders its children according to the b-tree collation using a
-# record obtained from a leaf page as a *key*. A branch page always has one more
-# children than the number of keys. Keys are unique. A key used in a branch page
-# will not equal another key used in any branch page according to the collation.
-#
-# There are two special types of branch pages, the root page, and penultimate
-# pages.
-#
-# #### Root Branch Page
-#
-# The root page is the first page we consult to find the desired leaf page. Our
-# b-tree always contains a root page. The b-tree is never so empty that the root
-# page disappears. The root page always has the same address.
-#
-# TK move. Until the root branch page is split, it is both the root branch page
-# and a penultimate branch page.
+# To find the a record in the b-tree, we first use a tree of branch pages to
+# find the leaf page that contains our record.
+#
+# A branch page contains the addresses of child pages. This array of page
+# addresses is essentially an *array of children*.
+#
+# The child addresses are ordered according to the b-tree collation of the keys
+# of the directly or indirectly referenced leaf pages.
+#
+# There are three types of branch pages, penultimate branch pages, interior
+# branch pages, and the root branch page.
 #
 # #### Penultimate Branch Pages
 #


# ## 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
# *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 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.
#
# #### Locking on Descent
#

# its key from the search. We search the subsequent keys to find the first key
# that is grater than or equal to the record sought. Essentially, when we
# encouter a key that is greater than our sought record, we know that the record
# is contained in the leaf page child associated with the key before it. We are
# able to perform this search using binary search in logorithmic time.
#
# By ignoring the key of the first leaf page, the penultimate branch page has a
# number of children that is one greater than the number of keys.
