What changed
since you trusted it?

A version number
isn’t much evidence.

A familiar package name can make an update feel routine. But the release may come from a different build process, lose its provenance, or introduce code that runs as soon as another program imports it.

I wanted the comparison itself to be useful: what changed from the version someone already trusted, where that change appears, and why it deserves attention. The tool reads package artifacts rather than running their code.

Two changes.
A reason to look closer.

The synthetic package above starts at version 1.0 with a simple value and verified-provenance facts. Version 1.1 adds a module-level subprocess.run call and has no attestation. The fixture supplies the provenance facts; this walkthrough does not verify a real publisher’s signature.

The working engine flags both differences. GRN-C003 identifies the new import-time call and its location, demo/__init__.py:2. GRN-T001 identifies the lost attestation and records the earlier publisher and workflow. Both findings carry a warning.

A subprocess call can have an ordinary explanation. A missing attestation can be a release-process mistake. Those are reasons to inspect the change, not enough evidence to call a package malicious.

Keep the uncertainty
beside the finding.

The report pairs a rule with concrete evidence. It distinguishes a warning from a block, and an inspection failure from a completed check. A reader needs to know when the tool could not collect enough evidence.

Comparing releases also keeps the question specific. The useful signal is a trust property that disappeared or a sensitive behavior that appeared. A report with no findings still cannot certify that a package is safe.

The same comparison can produce readable text for a person or structured JSON for another tool. The presentation changes; the underlying evidence stays available.

A working comparison.
A larger tool in progress.

The public source checkout includes the pre-alpha garnet diff command for comparing two PyPI releases, plus rule explanations and text or JSON output. The project README contains setup instructions and the current limits.

Broader integrations, including dependency-update pull requests and agent hooks, remain in development. This case study demonstrates the comparison engine on controlled fixtures; it does not establish production readiness or measure how reliably the tool catches attacks.