Become a sponsor to Antoni (Tony) Jagodka

Most of what software teams call "review evidence" is an assertion: a green checkmark, a vendor log, a screenshot of an approval. I build tools that replace assertions with something a third party can recompute.

The flagship is source-review-coverage, a GitHub Action that issues one signed in-toto attestation per merge: which tree each approval covered, which tree actually shipped, and how one became the other. Anyone with git can replay it offline — no vendor, no dashboard, no trusting the party being audited. The interesting part is the failure case: when bytes ship that no approval covered (a hand-resolved conflict, a push after the last approval), the verifier emits the exact diff, because those lines were reviewed by nobody, by construction. That question — what did the agent change and who reviewed it — is starting to arrive from auditors instead of colleagues, and it deserves a better answer than a screenshot.

Around the flagship sit smaller tools in the same spirit: reversible (undo for what shell commands did to your files), evidence-tier (per-claim provenance: ran it, read it, was told it, recalled it, inferred it), and verified-examples (docs examples CI actually re-runs and attests, instead of hoping they still work).

I hold the work to its own standard: the spec is public, the verifier states plainly what a pass does not establish, and the repo runs its own action on every merge. Upstream, a fix of mine is merged in sigstore-python and the predicate is proposed at in-toto/attestation.

Sponsorship buys maintenance: the fortnightly release train, reviewing and integrating external contributions (credited by name), and the slow careful work of keeping a verifier honest. The organization tier gets priority on issues. If your team is starting to be asked for evidence about AI-written changes, sponsoring keeps the tool that answers that question alive and independent.