What the supply chain actually signs

The distinction this ledger exists for

Predictions, written down first

The expectations file was committed and published at digest d089f5dc2f47169f before a single package was checked, and the run refuses to start if that file's digest stops matching its contents. These four predictions were in it.

Where they fail first

Limbs run in a frozen order and a refusal names the first one that failed, so these counts partition the census rather than double-counting it.

Named reasons

Every limb, reported separately

not reached means an earlier limb failed first, so this one was never observed: it is neither a pass nor an exemption. The digest compared against each signature is one this probe computed over bytes it downloaded, never a digest quoted back from an API.

The part that did work

Every attestation that exists in this set verified. All 44 passed Sigstore verification against the Fulcio certificate chain and the Rekor transparency log, the digest computed over the downloaded bytes matched the index in every case, and every one was discoverable in the log. The gap here is adoption, not broken cryptography, and a refusal ledger that only ever prints bad news is not measuring anything.

Anomalies, and why they are not accusations

The signer to source limb compares two facts a maintainer sets in two different places: the repository PyPI reports as the signer, and the source repository the project declares in its own PyPI metadata. They disagreed twice.

A project may build and upload from a repository other than the one it lists as its source, and a repository that has been renamed keeps answering on its old name. Both are ordinary and neither is evidence of wrongdoing. What the receipt records is that an automated consumer pinning the declared source repository would not match the signer, which is a real cost of the naming gap even when nobody did anything wrong.

What the probe found about its own author

The first limb failed on this engine's own declared roots before it failed on anyone else's package.

Both are packages this host publishes. The engine declares a version range the public index cannot satisfy, which means a third party following this requirements.txt cannot reproduce the environment. That is a refusal against the author of the probe, found by the probe, published here rather than fixed quietly first.

Read it yourself

One package's receipt, by normalized name, from the federation origin:

curl -sS https://geniusflow-federation.vercel.app/slsa/receipts/cryptography.json | jq '{package, version, must_admit, first_refuse_reason, limbs}'

Re-run it

The probe is stdlib only apart from the verifier, which is not an engine runtime dependency. When it is missing the signature limb refuses by name rather than passing, so an unverified run can never read as a verified one.

python3 -m venv .slsa && .slsa/bin/pip install pypi-attestations
.slsa/bin/python engine/tools/slsa_provenance_run.py expect
.slsa/bin/python engine/tools/slsa_provenance_run.py run

Version ranges float, so a later run resolves a later set and the counts move. The expectations file pins exactly which artifact filenames and digests a given run covered, so a disagreement is about what the index served rather than about which packages were picked.

What this cannot tell you

• One resolution on one platform at one moment. Wheel filenames are platform specific, so another machine resolves a different artifact list for the same declared versions.
• The signer identity is checked against the publisher PyPI reports and then cross checked against the source repository the project declares in its own PyPI metadata. Both facts come from PyPI, so a PyPI that lies about both consistently would pass that limb. The signature verification itself does not depend on PyPI: it goes to the Fulcio chain and the Rekor log.
• A 404 from the integrity endpoint is recorded as a refusal, not an absence. The uploader may have chosen not to attest, or may predate PEP 740. Neither case is distinguished here.
• Only GitHub publisher slugs are cross checked against declared source. Other publisher kinds refuse that limb by name rather than passing unchecked.
• Version ranges float, so re-running resolves a newer set. The expectations file pins exactly which artifacts a given run covered.
• This is a census of one dependency set. It supports no claim about PyPI as a whole, and no rate here should be quoted as one.