squash: Add verification scenarios

Signed-off-by: Aditya Sirish <[email protected]>

spec/predicates/test-results.md

@@ -24,6 +24,28 @@ verify:
 Therefore, each attestation corresponds to one invocation of a test suite, and
 may include the results of several individual tests.
 
+### Asserting Test Configurations Used
+
+The supply chain owner creates a policy that records the expected test
+configurations. During verification, the policy checks that the test attestation
+used the right configurations. A custom inspection may optionally parse the
+`testRun.link` field to verify attestation matches the test run.
+
+### Asserting Test Results
+
+In addition to the previous use case, the supply chain owner creates a policy
+verifying that test results passed. In the simplest case, the policy applies to
+all tests. Therefore, it asserts the contents of `result` and that
+`testRun.failedTests` is empty. In more nuanced cases, a subset of tests may
+matter. For example, the tested artifact may be an OS image that's to be
+deployed to three types of devices. As such, the test harness tests the new
+image on an instance of each device. When verifying the attestation prior to an
+image being installed on a device, it only matters that the tests passed on the
+corresponding test device and not necessarily the others.
+
+As before, a custom inspection may examine the `testRun.link` contents to verify
+the contents of the attestation.
+
 ## Prerequisites
 
 Understanding of the
@@ -35,6 +57,8 @@ This predicate type includes one compulsory field, `result`, that describes the
 result of the test run. The `testRun` object can be used to communicate a link
 to the test run and list tests that passed, failed, and passed with warnings. It
 also may optionally contain a reference to the configuration for the test run.
+The expected `subject` for this are the source artifacts themselves or some
+reference to them such as a Git commit.
 
 ## Schema