Rewrite the reproducible section.

- Better explain the difference between "reproducible" and "verified
  reproducible".
- Clarify that reproducible is required unless there is a justification.

README.md

@@ -179,25 +179,34 @@ more, see [Threats, Risks, and Mitigations in the Open Source Ecosystem].
 
 ### What about reproducible builds?
 
-[Reproducible](https://reproducible-builds.org) and hermetic builds
-[provide](https://reproducible-builds.org/docs/buy-in/)
+When talking about [reproducible builds](https://reproducible-builds.org)
+builds, there are two related but distinct concepts: "reproducible" and
+"verified reproducible."
+
+"Reproducible" means that repeating the build with the same inputs results in
+bit-for-bit identical output. This property
+[provides](https://reproducible-builds.org/docs/buy-in/)
 [many](https://wiki.debian.org/ReproducibleBuilds/About)
 [benefits](https://static.googleusercontent.com/media/sre.google/en//static/pdf/building_secure_and_reliable_systems.pdf#page=357),
 including easier debugging, more confident cherry-pick releases, better build
-caching and storage efficiency, and accurate dependency tracking. For these
-reasons, we require reproducibility and hermeticity at SLSA 3 by default.
-
-In terms of security, _verified_ reproducible builds are often
+caching and storage efficiency, and accurate dependency tracking.
+
+For these reasons, SLSA 3 [requires](#proposed-slsa-definitions) reproducible
+builds unless there is a justification why the build cannot be made
+reproducible.
+[Example](https://lists.reproducible-builds.org/pipermail/rb-general/2021-January/002177.html)
+justifications include profile-guided optimizations or code signing that
+invalidates hashes. Note that there is no actual reproduction, just a claim that
+reproduction is possible.
+
+"Verified reproducible" means using two or more independent build systems to
+corroborate the provenance of a build. In this way, one can create an overall
+system that is more trustworthy than any of the individual components. This is
+often
 [suggested](https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/)
-as a solution to supply chain integrity. The idea is that a system of
-independent reproducers all run the same build commands on the same inputs and
-report the same output. A consumer can gain confidence in an artifact's
-provenance by querying multiple rebuilders, assuming that not all of the
-rebuilders have been compromised.
-
-Indeed, this is one option to secure build steps of a supply chain. When
-designed correctly, such a system satisfies all of the build requirements listed
-below.
+as a solution to supply chain integrity. Indeed, this is one option to secure
+build steps of a supply chain. When designed correctly, such a system can
+satisfy all of the SLSA build requirements.
 
 That said, verified reproducible builds are not a complete solution to supply
 chain integrity, nor are they practical in all cases:
@@ -209,17 +218,14 @@ chain integrity, nor are they practical in all cases:
     and that software has a vulnerability that can be triggered by sending a
     build request, then an attacker can compromise all rebuilders, violating the
     assumption above.
-*   Some builds cannot easily be made reproducible,
-    [such as](https://lists.reproducible-builds.org/pipermail/rb-general/2021-January/002177.html)
-    profile-guided optimizations or code signing that invalidates hashes.
+*   Some builds cannot easily be made reproducible, as noted above.
 *   Closed-source reproducible builds require the code owner to either grant
     source access to multiple independent rebuilders, which is unacceptable in
     many cases, or develop multiple, independent in-house rebuilders, which is
     likely prohibitively expensive.
 
-For these reasons, we do not strictly require reproducible builds as part of
-SLSA. Instead, we only _recommend_ reproducibility at SLSA 3 and allow verified
-reproducible builds as one option for meeting the build requirements.
+Therefore, SLSA does not require verified reproducible builds directly. Instead,
+verified reproducible builds are one option for implementing the requirements.
 
 For more on reproducibility, see
 [Hermetic, Reproducible, or Verifiable?](https://sre.google/static/pdf/building_secure_and_reliable_systems.pdf#page=357)