Verify the ledger

Every Axtary decision appends a hash-chained record to a local JSONL ledger. This page covers turning that ledger into evidence a third party can check without trusting Axtary: signed attestations, Merkle inclusion and consistency proofs, and offline incident reconstruction.

The canonical ActionPass v0 draft is public at /spec/actionpass-v0.md; the customer guide is ActionPass spec and verifier.

Create a signed attestation

axtary attest-ledger \
  --ledger .axtary/actions.jsonl \
  --out attestation.json

attest-ledger verifies the full hash chain first, then writes a self-contained bundle: the exported records, an export digest, an RFC 6962 signed tree head (Merkle root + tree size), and a detached ES256 signature. The same date-range and decision filters as export-ledger apply.

Verify it independently

axtary verify-export attestation.json

verify-export is standalone: it checks the signature, the record hash chain, the export digest, and approval↔execution equivalence from the bundle alone — no running proxy, no network, no Axtary service. A single edited, reordered, or deleted record fails the whole bundle, and so does any execution record whose approved and executed payload hashes disagree. On success it prints an equivalence summary alongside the digest.

Prove approvals executed exactly

Every execution that carried a human approval records two hashes: the payload hash the approval was bound to and the hash of the payload that actually executed. prove-equivalence turns that pair into a queryable, exportable proof:

axtary prove-equivalence --ledger .axtary/actions.jsonl --out equivalence.json

Each execution record reports proved (approved == executed, and the executed hash matches the record's own hash-chained payload hash), unproven (no approval evidence was attached — reported truthfully, never presented as proved), or failed. Any failed entry exits non-zero and also fails verify-export for the same ledger: an execution that escaped its approval is treated as tamper, not as a warning. Combine with prove-inclusion to hand a third party the proof for one specific approved execution against the signed Merkle head.

Prove one record is included

Use an inclusion proof when someone needs to check a single decision without receiving the whole export:

axtary prove-inclusion attestation.json --record ap_<jti> --out proof.json
axtary verify-proof proof.json --bundle attestation.json

The proof commits the record to the signed Merkle head, so the verifier learns that this exact record is in the attested ledger — nothing else about the other records.

Verify a foreign issuer

For cross-issuer audits, a verifier can pin another issuer's public trust root and check one ActionPass, its ledger attestation, its inclusion proof, and its fresh revocation/status evidence together. The local proxy publishes the public descriptor at:

curl http://127.0.0.1:7331/.well-known/axtary-trust-root.json

The descriptor contains only public JWKS, the issuer id, and the status-list URI. It is an Axtary verify-only profile with OpenID-Federation-compatible typing markers; it is not a trust-network UI and does not resolve arbitrary federation chains.

Prove the ledger only grew

A consistency proof shows a later attestation append-only-extends an earlier one — records were added, never rewritten:

axtary prove-consistency first.json second.json --out proof.json
axtary verify-proof proof.json --first first.json --second second.json

If any historical record changed between the two heads, verification fails.

Reconstruct an incident offline

axtary forensics attestation.json

forensics replays delegation and execution structure from ledger records alone: whether delegated authority only ever narrowed, whether every execution correlates to exactly one authorization, and whether a revocation cascade contained its descendants. It is a read-only auditor primitive, not anomaly detection.

What this does and does not prove

• The proofs are post-signing tamper evidence: they detect any change to records after they were attested, and they work offline against public keys.
• They do not make claims about events that were never recorded, and — like any local-first evidence — the signing boundary is your machine's key custody.
• Ledger records are payload-free by design: hashes, decisions, reasons, and audit dimensions, never file contents, tokens, or raw shell commands.