proofbundle

README

proofbundle

Portable evidence for AI work, verifiable offline. Integrity, not truth

One file. No verification server. No network required.

Quick start · What it proves · Current release · Adoption review · Documentation

Current release

v6.4.0 · Beta · Audit status and limits

Known limitations for 6.4.0 · Earlier risk record · Release notes · Release scope

What was checked, and what remains open

A feature release following 6.3.1. The installed package adds an experimental reader for SCITT Transparent Statements with CCF receipts and a verifier for TRACE v0.2 Trust Records, and its strict JSON reader now rejects non-finite numbers and applies explicit integer and encoding limits. The Rust cross verifier gains three SCITT commands, and the release workflows select fixed versions of the build frontend and backend. Review the input restrictions when upgrading.

• SCITT Transparent Statements with CCF receipts, experimental. proofbundle.scitt_ccf reads a Transparent Statement, its receipts and section 4 consistency receipts under the narrow profile scitt-ccf/v1 of ADR 0009, as draft -06 of the CCF profile reads them. It needs the [scitt] extra; without it every entry point refuses with no_lib. Only a direct call reaches it. No verify path of the package does.
• TRACE v0.2 Trust Records. proofbundle verify-trace checks a record against keys, a time window and expectations that the relying party supplies. A pass is evidence for that policy, and safeForAutomation is false in every verdict.
• The strict JSON reader applies explicit number and encoding limits. It refuses non-finite numbers, integer literals outside the inclusive range -(2^53 - 1) to 2^53 - 1, and JSON bytes with a UTF-8 byte order mark or encoded as UTF-16 or UTF-32, with BundleFormatError. With an sd_jwt_vc whose issuer signature verifies, verify_bundle demands and fails sd-jwt-bundle-binding when that reader refuses the signed payload. Review code that hands such input to a verifier.
• The Rust cross verifier and the build path. pb_verify_rs verifies statement signatures, Transparent Statements and consistency receipts of the profile on shared vectors; it is not part of the Python package. The release workflow installs the build frontend and backend at fixed versions and refuses a wheel whose recorded backend is not the pinned one.

In the tagged tree, check audit_artifacts/640/pre_tag_receipt_v6.4.0.json for the recorded audit command and result.

The package being published and its closing audit passing are separate facts. An audit that was not run makes no statement about the absence of defects.

Residual risks for 6.4.0 · Earlier risk record

Quick start

Install the verifier, download an example, then verify the local file.

python -m pip install proofbundle==6.4.0

curl -fsSLo receipt.json \
  https://raw.githubusercontent.com/b7n0de/proofbundle/v6.4.0/examples/example_bundle.json

proofbundle verify receipt.json

Python 3.10 or newer. Installation and download use the network. Verification reads the local file only.

Exit codes and the tamper demo

These exit codes apply to proofbundle verify, not to every command in the package.

Exit code	Meaning
0	Verified
1	Verification failed
2	Malformed input or usage error
3	Relying party policy not met

decision verify, outcome verify and relation-statement verify have separate contracts in their own --help.

To try deliberate tampering, install the evaluation extra and run the demo.

python -m pip install 'proofbundle[eval]==6.4.0'
proofbundle demo

The demo checks an honest receipt, tampered variants and a sample swap. It exits with a nonzero code if a tamper is accepted.

Guided walkthrough · Inspect plugin

What a receipt proves

What verification can establish	What it does not establish
Which key signed the content	Whether you should trust that key
Whether signed content has changed	Whether the reported result is true
Whether supplied proofs and requested policy checks pass	Whether the work was correct or complete

A valid signature does not make a reported result true. Checks depend on the receipt format and the policy you request.

A PASS means: the signature is valid, the explicitly checked artefacts match the signed digests, and a trust policy passed if you gave one with --policy (without it the output says POLICY: NOT_EVALUATED). Truth, code quality and provenance from a particular AI model are not confirmed by it.

Threat model · Non claims

Choose your task

I want to	Start here
Verify a receipt	Quick start
Create evaluation evidence	Evaluation walkthrough
Add receipts to Inspect AI	Inspect plugin
Assess proofbundle for adoption	Adversarial review guide

Other workflows and optional features

Workflow	Package or reference
Evaluation receipts and preregistration	proofbundle[eval] · Claim format
Inspect AI	proofbundle[inspect] · Plugin setup
Agent review disclosures	Profile inventory · Conformance examples
RFC 3161 and OpenTimestamps	proofbundle[anchors] · Anchor guide
ML-DSA-44 witness cosignatures	proofbundle[pq] · Anchor guide
TEE attestation bridge	proofbundle[experimental] · Experimental bridge

Shipped features do not all have the same maturity. Agent review disclosures are self declarations. Anchor and enclave paths have experimental boundaries. Check the predicate inventory for the exact profile before relying on it.

Plugins

proofbundle ships plugins for pytest and Inspect AI. Receipt emission is opt-in and requires an explicit pass threshold.

Plugin	Package
pytest	proofbundle[pytest,eval]
Inspect AI	proofbundle[inspect,eval]

Commands, threshold and output

pytest

python -m pip install 'proofbundle[pytest,eval]==6.4.0'
PROOFBUNDLE_EMIT=1 PROOFBUNDLE_THRESHOLD=0.9 pytest

Inspect AI

python -m pip install 'proofbundle[inspect,eval]==6.4.0'
PROOFBUNDLE_EMIT=1 PROOFBUNDLE_THRESHOLD=0.9 inspect eval task.py --model <model>

These commands use POSIX shell syntax. Run pytest in your test project; replace task.py and <model> with your Inspect task and configured model.

0.9 is an example, not a default. pytest records pass_rate; Inspect selects the first available metric unless you set PROOFBUNDLE_METRIC. The comparison defaults to >=; set PROOFBUNDLE_COMPARATOR to change it. The threshold verdict is recorded in the receipt and does not change the test or eval exit status. Without PROOFBUNDLE_THRESHOLD, receipt emission is skipped.

Receipts go to the current directory by default, and the plugin prints the output path. Set PROOFBUNDLE_OUT to choose a file or directory. Set PROOFBUNDLE_KEY to the path of a file containing a 32-byte raw Ed25519 seed for a reusable signing key. Otherwise, an emitted receipt uses a temporary key and is not tied to a lasting identity.

Documentation

Your question	Reference
How do I implement the format?	Specification · Conformance
How do I integrate my workflow?	pytest and Inspect plugins · Other integrations · Glossary
Which keys and claims should I accept?	Policies · Trust anchors
How is security assessed?	Threat model · Security policy
How was this release prepared?	Release process · Pre tag audit

How it works

Your evaluation, review, decision or action
                    ↓
Canonical statement, signature and supplied proofs
                    ↓
One portable receipt file
                    ↓
Offline verification and explicit policy checks

The verifier checks the evidence it receives. Expected subjects, trusted keys, freshness requirements and acceptance policies come from the relying party. Missing evidence is not evidence that omitted work never happened.

Capabilities and maturity

The core supports signed receipts and Merkle inclusion proofs. Evaluation receipts can bind metrics, thresholds, provenance and commitments. Selective disclosure can hide selected values while preserving the checks supported by its profile.

Decision receipts record a verdict over named evidence. That does not establish that the decision was correct. Outcome, relation, run ledger, trust pack and verification summary profiles have their own maturity limits.

The Rust cross verifier is experimental and advisory. Agreement on recorded cases does not prove either implementation correct, and the Rust tool is not part of the Python package.

Predicate inventory · Conformance boundaries

Security and trust

The core uses cryptography and rfc8785, rather than implementing its own cryptographic primitives. The test approach includes external vectors, mutation checks and parser fuzzing. Those are test signals, not a proof of correctness.

Receipt signatures are Ed25519, not post quantum. ML-DSA-44 witness cosignatures and the experimental renewal path do not turn the payload signature into a post quantum signature. See the anchor documentation.

Build provenance and package attestations answer questions about the build and its bytes. They do not establish the truth of an evaluation or replace a security audit. See the release process.

Report a vulnerability · Conformance · Adoption review

The OpenSSF Scorecard is a heuristic, not a product verdict. Read the per check explanations and self assessment.

Standards and interoperability

proofbundle complements other evidence systems. A format mapping or an open proposal is not the same as adoption by the upstream project.

Tool comparison · Receipt envelope profile · in-toto mapping · SCITT mapping · Related work

The interop discussion with inspect-receipts records a specific envelope comparison. It must not be read as evidence of a second independent implementation of every predicate.

Scope, citation and contributing

proofbundle is not a hosted transparency service, a complete in-toto client, a trusted execution environment, a consensus system or a compliance product by itself.

Release scope records what belongs to this release. Deferred work is not a delivered capability.

Use CITATION.cff for citation metadata. The software archive has concept DOI 10.5281/zenodo.21110642. The Technical Note has concept DOI 10.5281/zenodo.21230466. Software and Technical Note versions are separate records.

Contributing guide · Code of Conduct · Good first issues · Security reports

---

MIT license · Part of b7n0de, Verified AI Work