{subsection: Lambda function}
 
-The examples directory includes a CloudWatch template [FIXME] (the file =template-3.json=) you can use to create the necessary AWS Lambda function (and grant it the permissions necessary for it do its job).  After logging into the AWS web console, do the following for each region you intend to use:
+The examples directory includes a CloudWatch template [FIXME] (the file =template-3.json=) you can use to create the necessary AWS Lambda function (and grant it the permissions necessary for it do its job); instructions follow for readers who haven't created a stack from a template file before.  After logging into the AWS web console, do the following for each region you intend to use:
 
 1: Switch to the region.  (The second drop-down box in from the upper right.)
 1: Switch to CloudFormation.  (In the _Services_ menu, under _Management_.)
@@ -59,13 +59,13 @@
 
 {subsection: options}
 
-*: Like most other HTCondor tools, you can specify which daemon =condor_annex= should contact using the =-pool= and =-name= flags.  This is probably not useful in this version.
-*: You may specify the endpoints with the =-service-url=, =-events-url=, and =-lambda-url= flags.
-*: If you'd like to change (or specify) the user data from the command line, use the =-user-data[-file]= and =-default-user-data[-file]= flags.  The =-file= form specifies a file containing the user data.  The default flag will set an instance's user data as specified only if the JSON configuration file did not; the normal form sets it unconditionally.
-*: The tool also support the =-debug-] and =-help= flags.
+*: Like most other HTCondor tools, you can specify which daemon =condor_annex= should contact using the =-pool= and =-name= options.  This is probably not useful in this version.
+*: You may specify the endpoints with the =-service-url=, =-events-url=, and =-lambda-url= options.
+*: If you'd like to change (or specify) the user data from the command line, use the =-[default-]user-data[-file]= options.  The =-user-data= flag sets the user data for each instance to the value passed on the command line; appending =-file= sets the user data for each instance to the data in the file, instead.  Prepending =-default= only sets the user data for instances which would otherwise lack it.  You may set default user data from a file.
+*: The tool also support the =-debug= and =-help= flags.
 
 {section: advanced usage}
 
-The basic usage, above, possibly in conjuction with some of the other options, should suffice for the efficient provisioning of many instance from pre-existing images.  If you'd like to use the prototype to start annexes, the procedure is somewhat involved.  The basic idea is as follows: when HTCondor starts up (this may be replaced by "when the OS finishes booting" in future releases), it runs a script which looks at the permissions which have been granted to the instance.  (Obviously, this fails if the instance hasn't been granted permission to look at its own permissions.)  If one of those permisssions is read access to a specific file in a specific S3 bucket, the script downloads the file into the HTCondor =config.d= directory, or, if the file is a tarball, untars it there.  Because this mechanism is entirely independent of the usual userdata-dependent contextualization methods, it can be used to dynamically configure HTCondor regardless of an how an instance otherwise might configure itself.  We expect this ability to generally be used to configure HTCondor to join one specific pool or another.
+The usage above should suffice for the efficient provisioning of many instance using the images you already are.  If you'd like to use the prototype to start annexes, the procedure is somewhat involved.  The basic idea is as follows: when HTCondor starts up (this may be replaced by "when the OS finishes booting" in future releases), it runs a script which looks at the permissions which have been granted to the instance.  (Obviously, this fails if the instance hasn't been granted permission to look at its own permissions.)  If one of those permisssions is read access to a specific file in a specific S3 bucket, the script downloads the file into the HTCondor =config.d= directory, or, if the file is a tarball, untars it there.  Because this mechanism is entirely independent of the usual userdata-dependent contextualization methods, it can be used to dynamically configure HTCondor regardless of an how an instance otherwise might configure itself.  We expect this ability to generally be used to configure HTCondor to join one specific pool or another.
 
 We have provided a second CloudWatch template to help construct this mechanism.  Actually, because it was easier, we have provided a script which -- given the S3 bucket name and file -- outputs a CloudWatch which creates the corresponding IAM role and instance profile. ....