High Priority fixes - AI review (#98)

* Hight Priority fixes - AI review

ReapErase document in wrong place - causes confusion, as is not part of Quick Docs.

The Riak Theory Guide is no longer work in progress.  There may be further additions, but nothing planned - there's no TODO.

Avoid confusion caused by referring to reactive management in the proactive reconciliation section.  Describe proactive reconciliation first, be clearer reactive management is providing context.

* Clarify new words

Author: martinsumner

docs/InitialDesignDecisions.md

@@ -190,7 +190,10 @@ To discover what combinations may be supported given a cluster (given a count of
 
 #### Proactive reconciliation
 
-Riak has support for reactive management of data: as part of every GET request a read repair process may be triggered if all vnodes are not up-to-date; as part of failure management a handoff process will merge data captured on temporary fallback vnodes back into primary vnodes.  It can also support proactive reconciliation - known as [active anti-entropy (AAE)](./RiakTheoryGuide.md#anti-entropy).  Configuring AAE will trigger a background process that will continually verify that the most recent version of each object is correctly stored in all required locations, and prompt repairs should the verification process highlight discrepancies.
+Riak has support for proactive reconciliation within a cluster; known as [active anti-entropy (AAE)](./RiakTheoryGuide.md#anti-entropy).  Configuring AAE will trigger a background process that will continually verify that the most recent version of each object is correctly stored in all required locations, and prompt repairs should the verification process highlight discrepancies.  This is in addition to reactive management which is always enabled within Riak: as part of every GET request a read repair process may be triggered if all vnodes are not up-to-date; as part of failure management a handoff process will merge data captured on temporary fallback vnodes back into primary vnodes.
+
+{: .highlight }
+Proactive reconciliation provides continuous assurance that data is correctly secured across multiple devices within a cluster: it is verification as well as correction.  It is of particular use where data may be stored for long periods without being read, nullifying the trigger for reactive management via read repair.
 
 There are two forms of proactive intra-cluster reconciliation in Riak:
 
@@ -206,7 +209,10 @@ There are two forms of proactive intra-cluster reconciliation in Riak:
   - Requires a separate keystore for all backends.
   - More aggressive than Tictac AAE at resolving discovered discrepancies.
 
-If neither reconciliation method is configured there are long-term risks of data loss, when Riak is used to store _cold_ data that is very rarely read.
+{: .warning }
+> If Tictac AAE is not enabled, there is an increased risk of data loss when Riak is used to store _cold_ data that is very rarely read.
+
+Enabling Tictac AAE also adds to the cluster support for the operator-functionality associated with [AAE Folds](./OtherAPI.md#aae-fold-api).
 
 ### Intra-cluster data resilience - changing the choice
 

docs/RiakTheoryGuide.md

@@ -6,7 +6,7 @@ layout : default
 
 # Riak KV - Theory Guide
 
-This guide is a work in progress, and provides insight into the underlying theories and processes which underpin the function of a Riak cluster.  Understanding this theory will be helpful to understand the design, setup and operation of a Riak cluster.
+This guide provides insight into the underlying theories and processes which underpin the function of a Riak cluster.  Understanding this theory will be helpful to understand the design, setup and operation of a Riak cluster.
 
 - [The ring and how data is distributed in Riak](#the-ring---the-distribution-of-vnodes)
 - [Eventual consistency](#eventual-consistency)