anchor.diff:  For the sake of capacity and resilience, you want every feature to run on more than one VM.
   
   To achieve this, you define VM types, where each type supports different features.
  -Then you decide how many instances of each VM type to create. This is how you orchestrate your deployment.
  +Then you decide how many instances of each VM type to create. Now how have orchestrated your deployment.
   
   In the manifest you specify orchestration along with everything else about your deployment,
   including the stemcell, release, and network configuration to use.
   
   ## <a id="release"></a> Translating from Release to Manifest ##
   
  -**Note**: The terms "job" and "template" are used one way in the BOSH release and another in BOSH manifests.
  -In some situations you may need to use the terms "release job", "manifest job", "release template", and "manifest template" for the sake of clarity.
  +When you orchestrate, you allocate features to VM types and then specify a number of instances for each VM type.
  +You need to see what a product calls its features in the BOSH release in order to specify orchestration in the manifest.
   
  -When you orchestrate, you allocate features to VM types and then specify a number of instances for each VM type.
  +The terms "job" and "template" have one meaning in the release and another in the manifest.
   
   * A BOSH release uses the term "job" to describe a _feature_.
   * Meanwhile, a BOSH manifest uses the term "job" to describe a _VM type_,
   and the term "template" to describe a feature.
   * When you allocate a feature to a VM type, the feature described as a "job" in the release becomes a "template" in the `jobs` block in the manifest.
   You name your VM types as "jobs" and specify a number of instances for each.
  +
  +In the illustration below, five features found in a release are allocated to VM types in a manifest.
  +
  + <%= image_tag("orchestrate.png") %>
   
   For example, the manifest fragment below shows two VM types, each of which supports two features.
   
  
positive.code: The `properties` block consists of headings which are the names of features (templates) from the `jobs` block.
  Each heading is followed by one or more lines of configuration information.
  
  
negative.code: 
  ## <a id="anatomy"></a> Anatomy of a Manifest ##
  
  Some of the information in any given BOSH manifest is IaaS-specific.
  The vast majority of manifest content, though, is independent of the cloud infrastructure where you want to deploy.
  This makes it possible to re-use manifests, making minimal changes, even when moving a deployment from one IaaS to another.
  
  A BOSH deployment manifest begins by identifying the deployment as follows:
  
  1. The **name** you give the deployment.
  1. The `director_uuid` _insert text here_ to ensure that you deploy with the correct BOSH.
  1. The **release name** you choose.
  1. The **release version** which _insert description here_.
  
  For example:
  
  