Add source-review-coverage predicate

[DrVelvetFog]

Proposes a new predicate, source-review-coverage, per the new predicate guidelines. Answering the four questions asked there:

What's your use case?

SLSA v1.2 Source Track Level 4 requires that changes to protected branches "be agreed to by two or more trusted persons prior to submission," and requires this of the final revision submitted — with re-review if changes occur during review. That requirement currently has no verifier. SLSA states that it "leaves source provenance attestations undefined and up to the SCSs to determine what works best," and does not address how squash merges or rebases interact with approval, nor how post-approval changes are detected.

So the property is asserted by the source control system that performed the merge, to a consumer who cannot check it. This predicate carries what a third party needs to recompute it: the tree each approval covered, the tree that shipped, and how one became the other.

Why don't existing predicates cover this?

• SLSA Provenance — describes how an artifact was built, not how a change was admitted.
• SLSA Verification Summary — communicates that a revision meets a source level. A conclusion, not the evidence to reach it independently.
• Source Provenance Attestations — the natural home, deliberately left undefined by SLSA.
• Link / SCAI / SBOM — describe steps, attributes and contents. None binds an approval to a tree.

What does it look like?

See the Schema and Example sections. The Example is a complete Statement taken from a real repository, not composed by hand. Subjects use the existing gitCommit and gitTree digest types, so the central claim needs no new encoding.

What policy questions does it answer?

• Did an approval cover the exact tree that shipped?
• If not, is the shipped tree the reviewed change replayed onto its base, with nothing added?
• Which bytes shipped that no approval covers?
• Did the checks run over a tree an approval covers, or over some other tree?
• Was the evidence signed by a party other than the one being audited?

Each is answerable offline from the repository, without calling the system that produced the claim.

---

Measured before proposing

The replay model was checked against production history rather than reasoned about, on Git 2.50.1:

repository	workflow	sampled	identity	replay	residual	unexplained
huggingface/huggingface.js	squash	160 squash commits	87	73	0	0
x402-foundation/x402	squash	250 squash commits	88	162	0	0
maziyarpanahi/openmed	merge	400 merge commits	336	—	64	0

810 merges, every one accounted for as identity, replay, or a named residual — no third category and no special cases. All 64 residuals are conflict resolutions: unreviewed by construction, and ordinary. Zero merge commits carried content absent from their parents.

Notes for reviewers

Type URI. The specification is currently self-hosted at https://drvelvetfog.github.io/source-review-coverage/v0.1, because the predicate is already being issued and verified. If you would prefer it under in-toto.io/attestation/source-review-coverage/v0.1, I am happy to switch it and file the redirect PR — the namespace is yours to decide, and I did not want to assume it.

Protobuf. A definition exists and compiles under protoc 35.1, with the emitted JSON validated against it. I have left it out of this PR because generated bindings for four languages are committed in this repository, and it seemed better to have the design reviewed before adding that surface. Happy to open it as a follow-up, or add it here if you would rather review both together.

Reference implementation. Issues and verifies these attestations, including Sigstore signing by a workflow identity: https://github.com/DrVelvetFog/source-review-coverage.

One implementation note that may interest maintainers: sigstore-python rejects Statements whose subject uses gitCommit or gitTree, since its DigestSet is restricted to SHA-2 and SHA-3. That is a deliberate choice on their side (sigstore/sigstore-python#1018) rather than a problem with this predicate, but it does mean such statements cannot currently travel in a DSSE envelope signed by that client.