anchor.diff:  
   - Running LRP instances
   
  -- Inflight Tasks
  +- In-flight Tasks
   
  -The [Converger](./diego-pedia.html#converger) operates on the BBS periodically and broadcasts requests to start or stop LRPs as needed, based on a comparison of desired and actual LRPs.
  +The [Converger](./diego-pedia.html#converger) periodically reads from the BBS and broadcasts requests to start or stop LRPs as needed, based on a comparison of the desired and actual LRPs.
   
  -The Diego Brain's [Auctioneer](./diego-pedia.html#auctioneer) distributes Tasks and LRPs to the cluster of Diego Cells via an [auction](./diego-auction.html) involving the Cell [Rep](./diego-pedia.html#rep)s.  
  +The Diego Brain's [Auctioneer](./diego-pedia.html#auctioneer) distributes Tasks and LRPs to the cluster of Diego [Cells](./diego-pedia.html#cell-components) in a process called the [Auction](./diego-auction.html).
   
   See [The Diego Auction](./diego-auction.html) for more information about how tasks and LRPs are distributed in Diego.
   
   Once a Task or LRP is assigned to a Cell, the [Executor](./diego-pedia.html#executor) spins up a [Garden](./diego-pedia.html#garden) container and executes the specified work, which is encoded as a generic, platform-independent, recipe of composable [actions](https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/actions.md).
   
  -Diego interfaces with [Doppler](./diego-pedia.html#doppler) to provide real-time streaming logs for all Tasks/LRPs.  Diego also interfaces with [Gorouter](./diego-pedia.html#router) to automatically route web traffic to running LRP instances.
  +Diego streams logs to Loggregator's [Doppler](./diego-pedia.html#doppler) component to provide real-time logs for all Tasks and LRPs.  Diego also interfaces with [Gorouter](./diego-pedia.html#router) to automatically route web traffic to running LRP instances.
   
  -Diego is packaged up as a bosh release called [**Diego-Release**](https://github.com/cloudfoundry-incubator/diego-release).
  -
  +Diego is packaged up as the bosh release: [**Diego-Release**](https://github.com/cloudfoundry-incubator/diego-release).
   
   ## <a id='diego-cf'></a> Diego and Cloud Foundry
   
   Diego is abstracted away from the Cloud Controller and other Cloud Foundry components such as the Loggregator and the Router. Non-Diego CF components consume Diego via the [Receptor API](https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/README.md).
   
  -Presently, there is a translation layer called the CC-Bridge that converts the [Cloud Controller](./diego-pedia.html#cloud-controller)'s domain-specific requests to stage and run applications into requests terms that Diego understands: Tasks and LRPs.  Eventually Cloud Controller will be modified to communicate directly with a Diego component called the [Receptor](./diego-pedia.html#receptor).
  +Presently, there is a translation layer called the CC-Bridge that converts the [Cloud Controller](./diego-pedia.html#cloud-controller)'s domain-specific requests to stage and run applications into requests terms that Diego understands: Tasks and LRPs.  Eventually Cloud Controller will be modified to communicate directly with the Diego Cell's [Receptor](./diego-pedia.html#receptor) component.
   
  -The process of staging and running a CF application is complex and filled with platform and implementation-specific details.  We encapsulate these concerns in a triad of binaries known collectively as the [App Lifecycle](./diego-pedia.html#app-lifecycles).  The Tasks and LRPs produced by the CC-Bridge download the App Lifecycle binaries and run them to stage, start, and health-check CF applications.
  +The process of staging and running a CF application is complex and filled with platform and implementation-specific details. These concerns are encapsulated in a triad of binaries known collectively as the [App Lifecycle](./diego-pedia.html#app-lifecycles).  The Tasks and LRPs produced by the CC-Bridge download the App Lifecycle binaries and run them to stage, start, and health-check CF applications.
   
   ## <a id='conclusion'></a>Working Together
   
  
positive.code: 
  The Auction package encodes the behavioral details around the [auction](./diego-auction.html).
  
  It includes a simulation test suite that validates the correctness and performance of the auction algorithm.  The simulation can be run for different algorithms, at different scales.  The simulation can either be run in-process (for quick feedback loops) or across multiple processes (to understand the role of communication in the auction) or even across multiple machines in a cloud-like infrastructure (to understand the impact of latency on the auction).
  
  The [Auctioneer](./diego-pedia.html#auctioneer) and [Rep](./diego-pedia.html#rep) components use the Auction package to participate in the [auction](./diego-auction.html).
  
  
negative.code: 
  ### <a id='inigo'></a>Inigo
  
  Inigo is an integration test suite that launches the Diego components and excercises them through various test cases, including component failures and other exceptional cases.  As such, Inigo validates that a given set of component versions are mutually compatible, and that the system of these components is robust and degrades gracefully in its performance.
  
  [**Inigo on GitHub**](https://github.com/cloudfoundry-incubator/inigo)
  
  