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.3.1 · Beta · Audit status and limits
Known limitations for 6.3.1 · Earlier risk record · Release notes · Release scope
What was checked, and what remains open
A patch release following 6.3.0, with stricter verification and changed result reporting. Statement validation is reported separately from DSSE signature checks, and reference-check results and executed-outcome evidence levels change as described below. The release also improves handling of specific invalid inputs, extends the inspect_ai adapter and updates repository tools. Review the changed fields and remaining exception paths when upgrading.
- Statement validation is separate from DSSE signature verification. The eval-result, in-toto and SVR verifiers require the in-toto Statement v1 layer and report
statement_okseparately fromsignature_ok. These and the decision, outcome, relation statement, verification summary, run ledger and trust pack verifiers require subjects that identify artifacts by digest. A successful DSSE signature check alone does not establish that the Statement passes validation. - Reference reporting changes for callers upgrading from 6.3.0.
automation.referencesResolvedisNonewhen no reference was checked;safeForAutomationandautomationBlockersare unchanged. Executed-outcome evidence levels useREFERENCE_WELL_FORMEDfor a well-formed digest reference, orCONTENT_RESOLVEDwhen the evidence resolver confirms it, instead of always reportingCLAIMED.action_outcome_provenandokare unchanged. Review code that depends on these fields. - Stricter validation and more specific errors for the corrected cases. The decision validator rejects JSON null in required fields that do not allow it. The validators named below enforce the corrected digit restrictions and closed
sha256Digestobjects. The corrected error paths return reason codes, blocking verdicts or module-specific errors. Eight public functions remain open for the formatting cases described below, and the twocanonicalprimitives still propagate canonicalization errors. - The inspect extra admits inspect_ai up to 0.3.281. Version 0.3.281 is the latest version measured in a fresh environment. The adapter includes sample counts and early-stopping metadata when supplied by the log, allowing a reported early stop to be distinguished from a completed run. The reported
nis unchanged.
In the tagged tree, check audit_artifacts/631/pre_tag_receipt_v6.3.1.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.
Quick start
Install the verifier, download an example, then verify the local file.
python -m pip install proofbundle==6.3.1
curl -fsSLo receipt.json \
https://raw.githubusercontent.com/b7n0de/proofbundle/v6.3.1/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.3.1'
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.
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.
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.3.1'
PROOFBUNDLE_EMIT=1 PROOFBUNDLE_THRESHOLD=0.9 pytest
Inspect AI
python -m pip install 'proofbundle[inspect,eval]==6.3.1'
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.
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
1 maintainer
Metadata
1 maintainer
Release files for proofbundle 6.3.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| proofbundle-6.3.1.tar.gz | 4.8 MB | With provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| proofbundle-6.3.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 5.6 MB
Release files / proofbundle-6.3.1.tar.gz
| Download URL | proofbundle-6.3.1.tar.gz |
|---|---|
| Size | 4.8 MB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
534b1680800286d2000d96e124a39d3439ed1a9a35e0069078861eb79577ed6d
|
|
BLAKE2b-256 checksum How to use checksums |
46446290152c126cb572424109669f1f47234befe2ac511964c4e912f5f5d3a5
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.
Transparency logRelease files / proofbundle-6.3.1-py3-none-any.whl
| Download URL | proofbundle-6.3.1-py3-none-any.whl |
|---|---|
| Size | 888.1 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
7614dccf76b9b02afd8d228952b97cbb7d9a1f4282965561b04b61105267af7e
|
|
BLAKE2b-256 checksum How to use checksums |
3e78fb20473f47034ea1804ab0ab796dad913a24d8a45e8182640736390a0350
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.
Transparency logSecurity for proofbundle 6.3.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
Full provenance
All 2 files in this release have been uploaded with provenance metadata.
Attestation for proofbundle-6.3.1.tar.gz
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Oct 22, 2026.
Transparency logA note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
