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.

1
Install the CLI Run pip install aiir
2
Generate a receipt Run aiir --pretty in your repo
3
Verify the ledger Run aiir --verify .aiir/receipts.jsonl
4
Explore public examples Use the browser below to inspect public receipts

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.

Why release-first?

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.

Pass path

The generated bundle verifies offline with valid: true, Rekor inclusion proof intact, and policy=1-of-1 witness satisfaction.

Fail path

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"
  }
}

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.

Verification lives on the verifier page

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.

251
Commit receipts
79%
No durable AI marker
17%
Bot
4%
Declared AI signal
10
Unique signal types
Known provenance gaps

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
Page 1

Try it on your repo

pip install aiir
aiir --pretty
aiir --verify .aiir/receipts.jsonl