A feature release following 6.2.1. The installed package adds opt-in eval-result v0.2 export and verification, changes the default DSSE key ID handling, and fixes two pytest receipt behaviours. The repository also adds SCITT statement identification material, a pilot profile and contract, and an incremental Merkle accumulator.

• DSSE key IDs are included by default when available. Envelopes created by dsse.sign_envelope, including in-toto exports, carry the signer's OpenSSH SHA256 fingerprint as an unsigned keyid by default when the signer exposes its Ed25519 public key. Use keyid="" to omit it; signers without an exposed Ed25519 public key omit it unless supplied explicitly.
• eval-result v0.2 for the revised in-toto draft. An opt-in export and verification under its own predicate type; exports still default to v0.1, and --verify accepts both.
• Statement identification material for SCITT. The repository includes requirements and a verification package in docs/scitt/statement_identification/.
• Repository pilot material and an incremental accumulator. A profile and vectors for the shipped decision and outcome predicates, the first pilot contract, and an incremental Merkle accumulator with a restart rule are provided under docs/ and tools/.

In the tagged tree, check audit_artifacts/630/pre_tag_receipt_v6.3.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.3.0 · Earlier risk record

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

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.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

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.

pytest

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

Inspect AI

python -m pip install 'proofbundle[inspect,eval]==6.3.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.

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.

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

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.

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.

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