anchor.diff:  one can expect to see will vary greatly on how the system is configured.  Given
   that there are pluggable approaches to most of the major NiFi subsystems the
   performance will depend on the implementation.  But, for something concrete and broadly
  -applicable lets consider the out of the box default implementations that are used.
  +applicable, let's consider the out-of-the-box default implementations that are used.
   These are all persistent with guaranteed delivery and do so using local disk.  So 
  -being conservative assume roughly 50 MB/s read/write rate on modest disks or RAID volumes 
  -within a typical server.  NiFi for a large class of data flows then should be able to 
  -efficiently reach one hundred or more MB/s of throughput.  That is because linear growth
  -is expected for each physical parition and content repository added to NiFi.  This will 
  +being conservative, assume roughly 50 MB/s read/write rate on modest disks or RAID volumes 
  +within a typical server.  NiFi for a large class of dataflows then should be able to 
  +efficiently reach 100 or more MB/s of throughput.  That is because linear growth
  +is expected for each physical partition and content repository added to NiFi.  This will 
   bottleneck at some point on the FlowFile repository and provenance repository.  
   We plan to provide a benchmarking/performance test template to 
   include in the build which will allow users to easily test their system and 
   to identify where bottlenecks are and at which point they might become a factor.  It 
  -should also make it easy for system administrators to make changes and to verity the impact.
  +should also make it easy for system administrators to make changes and to verify the impact.
   
   For CPU::
  -The FlowController acts as the engine dictating when a given processor will be
  +The Flow Controller acts as the engine dictating when a particular processor will be
   given a thread to execute.  Processors should be written to return the thread
  -as soon as they're done executing their task.  The FlowController can be given a 
  +as soon as they're done executing their task.  The Flow Controller can be given a 
   configuration value indicating how many threads there should be for the various
   thread pools it maintains.  The ideal number of threads to use will depend on the 
   resources of the host system in terms of numbers of cores, whether that system is
  
positive.code: Architecture <<soa>>, the rise of the API <<api>><<api2>>, Internet of Things <<iot>>,
  and Big Data <<bigdata>>.  In addition, the level of rigor necessary for 
  compliance, privacy, and security is constantly on the rise.  Even still with 
  all of these new concepts coming about the patterns and needs of dataflow is 
  still largely the same.  The primary differences then are the scope of
  complexity, the rate of change necessary to adapt, and that at scale  
  the edge case becomes common occurrence.  NiFi is built to help tackle these 
  
negative.code: A NiFi cluster is comprised of one or more 'NiFi Nodes' (Node) controlled
  by a single NiFi Cluster Manager (NCM).  The design of clustering is a simple
  master/slave model where the NCM is the master and the Nodes are the slaves.
  The NCM's reason for existence is to keep track of which Nodes are in the cluster,
  their status, and to replicate requests to modify or observe the 
  flow.  Fundamentally then the NCM keeps the state of the cluster consistent.  
  While the model is that of master and slave, if the master dies the Nodes are all
  instructed to continue operating as they were to ensure the data flow remains live.
  The absence of the NCM simply means new nodes cannot come on-line and flow changes
  cannot occur until the NCM is restored.
  