Joshua Lock

Hi @kpk47, do you plan to work on the remaining items in this issue for the v1.1 release or would you like us to find another owner?

Thanks Ramon. Are you suggesting `verifiedLevels` becomes optional, or that they are removed entirely?

The text describing [`SlsaResult`](https://slsa.dev/spec/v1.0/verification_summary#emslsaresult-stringem) states that `SlsaResult` conveys "The result of evaluating an artifact (or set of artifacts) against SLSA." That is, the VSA describes the SLSA level _verified_ by...

Thanks for the detailed discussion, I agree with the proposal to remove FAILED from `verifiedLevels` and to not have SLSA_BUILD_LEVEL_N imply SLSA_BUILD_LEVEL_N-1. @AdamZWu would you be open to creating a...

Targeting v1.1 makes sense, thanks. We need to be careful how we introduce this so that we don't break our semver. As we support custom values and don't prefix `FAILED`...

It was suggested that explicitly stating each level verified _may_ simplify policy evaluation. This could easily be something to consider in future. Let's scope this issue only to removing the...

Good question, I [asked something similar](https://github.com/slsa-framework/slsa/pull/1037#pullrequestreview-1993634758) when reviewing the first draft of the Source track. I'd missed a discussion on this very topic in a working meeting which [Arnaud summarised](https://github.com/slsa-framework/slsa/pull/1037#issuecomment-2049595165):...

IMHO such tooling should make sure the squash commit message: - does not include images - is a reasonable length and format - includes DCO for (all) change contributor(s) what...

Thank you for working on this! I like the two-tiered proposal, getting folks (and process) up and running with a self assessment while we figure out third-party feels like a...

This feels like a good thing to add to the specification soon, i.e. v1.1