anchor.diff:  
   Diego is a complex system with many moving parts. The interactions and high-level behavior of an entire Diego runtime deployment can be monitored and tested using the following releases:
   
  -### <a id='runtime-schema'></a>Runtime-Schema
  -
  -- encodes all communication between Diego components and the BBS.  The Receptor, Rep, and Converger are the primary consumers of Runtime-Schema.
  -
  -- access to the consistent store is mediated via the BBS.  The BBS is comprised of several domain-specific sub-BBS packages.  Each Diego component is then given a *view* into the BBS (implemented as a Golang interface) to clarify the role and responsibility of the component.
  -
  -- the models by which components communicate are encoded in the models package.
  -
  -[**Runtime-Schema on GitHub**](https://github.com/cloudfoundry-incubator/runtime-schema)
  -
  -### Inigo
  +### <a id='inigo'></a>Inigo
   
   - is an integration test suite that launches the various Diego components and excercises them through various test cases.  As such, Inigo *validates* that a given set of component versions are mutually compatible.
   
  
positive.code: 
  [**Inigo on GitHub**](https://github.com/cloudfoundry-incubator/inigo)
  
  ### Auction
  
  - encodes the behavioral details around the auction.
  
  - 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).
  
  
negative.code: 
  Diego schedules and runs **Tasks** and **Long Running Processes**:
  
  - A **Task** is a one-off job and is guaranteed to be run at most once.
  
  - A **Long Running Process**, (LRP) such as an app, is meant to run until explicitly terminated, and may have multiple instances.  
  
  Diego maintains a representation of the desired and actual LRPs, and moves the total state of actual LRPs toward the total state of desired LRPs by creating and destroying LRPs if requirements change, or in response to crashes or network failures.
  
  Diego's Receptor components recieve requests to add or delete LRP instances, such as app instances, using a [RESTful HTTP API](https://github.com/cloudfoundry-incubator/receptor/blob/master/doc/README.md).
  
  Receptors manipulate Diego's representation of its desired LRPs in the [Bulletin Board System \(BBS\)](./diego-pedia.html#bbs), an up-to-date cache of the state of the Diego cluster, including: 
  
  - Desired LRPs 
  
  - Running LRP instances
  
  - Inflight 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 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.  
  
  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.
  
  ## <a id='diego-cf'></a> Diego and Cloud Foundry
  
  