Local-first plus proof-chain demo
Start with three commands on your own repo: install AIIR, generate a receipt, and verify the local ledger. Then inspect a public end-to-end proof chain for a release-bound artifact before exploring AIIR's public receipts in the browser.
Start local
The smallest useful workflow fits in one terminal before you touch CI, hosted tooling, or the public explorer.
pip install aiir
aiir --pretty in your repo
aiir --verify .aiir/receipts.jsonl
End-to-end proof chain
This public value demo uses a release handle as the canonical key. It shows the outcome AIIR is aiming at: one artifact, one proof bundle, one offline verification path, and one clear tamper failure.
The first public value demo uses a release-bound artifact because every file is inspectable without private infrastructure. The same proof shape can later bind to runtime handles, but this variant keeps the rollout public-safe and easy to audit.
1. Source evidence
The artifact aiir-demo-release.txt is bound to a stable SHA-256 digest and named in the
bundle manifest.
2. Transparency anchor
A reduced Rekor bundle, pinned trust root, and witnessed checkpoint carry the offline transparency proof.
3. Canonical handle
The binding record uses one release handle so auditors can start from a single public key instead of a pile of screenshots.
4. Offline verification
The verifier succeeds offline with a 1-of-1 witness policy and no private service dependency.
5. Tamper failure
Swap in the tampered artifact and verification fails closed with one clear error: the artifact hash no longer matches the Rekor bundle.
The generated bundle verifies offline with valid: true, Rekor inclusion proof intact,
and policy=1-of-1 witness satisfaction.
The tampered artifact flips the digest and the verifier returns artifact hash does not match Rekor bundle.
Bundle manifest
{
"variant": "release-evidence",
"artifact": {
"path": "aiir-demo-release.txt",
"sha256": "sha256:28b1f596828a1240a885b8adf64e9c5f3b10cfce174682c126a2e43f80064365",
"tampered_path": "aiir-demo-release-tampered.txt"
},
"binding": {
"handle": "release:aiir-demo/2026-04/value-demo"
},
"verification": {
"policy": "release"
}
}
Download the bundle
Inspect the proof assets
Verification flow
aiir --artifact aiir-demo-release.txt \
--rekor-bundle rekor-bundle.json \
--trust-root aiir-trust.json \
--witnessed-checkpoint witnessed-checkpoint.txt \
--require-witnesses release
aiir --artifact aiir-demo-release-tampered.txt \
--rekor-bundle rekor-bundle.json \
--trust-root aiir-trust.json \
--witnessed-checkpoint witnessed-checkpoint.txt \
--require-witnesses release
Public commit receipt explorer
After you try the local workflow, browse AIIR's own commit receipts here to
inspect real examples, filters, and classifications. The data comes from the
project's public ledger — the same repo receipting itself on every push to main.
The dedicated /verify page explains the verification tiers directly: browser verification proves Tier 1 content integrity, while signed receipts add stronger provenance. This page stays focused on public examples.
false negatives
Some AI-assisted commits still land in the “no durable AI marker” bucket when the
editor adds no explicit provenance markers such as
Co-authored-by trailers.
false positives Some commits are classified under “declared AI signal” because they mention tool names in the commit text, even when those tools were discussed rather than used to write the change.
| Commit | Subject | Author | Class | Signals | Date |
|---|
Try it on your repo
pip install aiir
aiir --pretty
aiir --verify .aiir/receipts.jsonl