Changes per feedback

docs/usage.md

@@ -266,6 +266,8 @@ The above syntax is also supported in `deps`.
 
 ## Prevent unnecessary work
 
+### By fingerprinting locally generated files and their sources
+
 If a task generates something, you can inform Task the source and generated
 files, so Task will prevent to run them if not necessary.
 
@@ -321,6 +323,9 @@ tasks:
 
 > TIP: method `none` skips any validation and always run the task.
 
+### Using programmatic checks to indicate a task is up to date.
+
+
 Alternatively, you can inform a sequence of tests as `status`. If no error
 is returned (exit status 0), the task is considered up-to-date:
 
@@ -340,7 +345,8 @@ tasks:
       - test -f directory/file2.txt
 ```
 
-Normally, you would use either `status` or `sources` in combination with
+
+Normally, you would use `sources` in combination with
 `generates` - but for tasks that generate remote artifacts (Docker images,
 deploys, CD releases) the checksum source and timestamps require either
 access to the artifact or for an out-of-band refresh of the `.checksum`
@@ -356,9 +362,13 @@ up-to-date.
 Also, `task --status [tasks]...` will exit with a non-zero exit code if any of
 the tasks are not up-to-date.
 
-If you need a certain set of conditions to be _true_ you can use the
-`preconditions` stanza.  `preconditions` are very similar to `status`
-lines except they support `sh` expansion and they SHOULD all return 0.
+### Using programmatic checks to cancel execution of an task and it's dependencies
+
+In addition to `status` checks, there are also `preconditions` checks, which are
+the logical inverse of `status` checks.  That is, if you need a certain set of
+conditions to be _true_ you can use the `preconditions` stanza.
+`preconditions` are similar to `status` lines except they support `sh`
+expansion and they SHOULD all return 0.
 
 ```yaml
 version: '2'