anchor.diff:  
   The `monit` file:
   
  -* Specifies the process ID (pid) file for the job.
  -* References each command provided by the templates for the job.
  -* Specifies that the job belongs to the `vcap` group.
  +* Specifies the process ID (pid) file for the job
  +* References each command provided by the templates for the job
  +* Specifies that the job belongs to the `vcap` group
   
   On a deployed release, a BOSH Agent runs on each job VM.
  -BOSH communicates with the Agent, which in turn executes the commands you have
  -provided in the control script.
  -The Agent does this with the help of [Monit](http://mmonit.com/monit/),
  +BOSH communicates with the Agent, which in turn executes commands in the
  +control script.
  +The Agent does this using [Monit](http://mmonit.com/monit/),
   which is open source software for monitoring processes, programs, files, and
   directories.
   
  
positive.code: 9 directories, 5 files
  </pre>
  
  Every deployed job needs a way to start and stop.
  You provide that in the BOSH release by writing a control script for each job,
  and a `monit` file that references the commands in the control script.
  
  ### <a id="control"></a> Create control scripts  ###
  
  
negative.code: * Jobs can depend on packages.
  * Packages can depend on other packages.
  
  Creating a dependency graph helps clarify your understanding of the
  dependencies between the jobs and packages in your release, and provides a
  reference as you add elements to the release.
  
  ### <a id="build-graph">Building the Dependency Graph ###
  
  1. Identify runtime dependencies.
  
  Whenever a control script or other template cites a package name, the job
  the template belongs to depends on the cited package at runtime.
  
  For each job, find all the cases where your control scripts cite packages.
  Add these runtime dependencies to your dependency graph.
  
  In our example, this line in both of our `ctl.erb` scripts cites `ardo_app`:
  
  ~~~
  cd /var/vcap/packages/ardo_app
  