Offline verification

Against the supplied public key, a valid record establishes the integrity of recorded authorization, scope, named approver, and sealed bytes.

This is a claim about the recorded evidence, not independent confirmation of the underlying events. Reproduction of a recorded decision is not reproduction of model behavior or the external-world outcome.

• Completeness: a valid export does not prove that it contains the complete action history.
• Truth of inputs: integrity does not establish that recorded inputs were true.
• Independent witnessing: ordinary verification does not establish external attestation. The default deployment has zero independent witnesses.
• Absence of bypass: omitted actions and work that bypasses AAES cannot be ruled out by checking the export.
• Legal non-repudiation: a valid record does not establish this legal property.
• Correctness or outcome: verification does not prove that the underlying decision was correct or that a dispatched call achieved its intended outcome.

<export.jsonl> and <key.pub> are placeholders for local paths to your export and public key.

Verify the export

aaesctl verify --export <export.jsonl> --pubkey <key.pub>

Check inclusion of a record

prove is a local inclusion check against the export's signed tree head. It is not a request to a service. Sequence 42 is an example, not a claim about your export.

aaesctl prove --export <export.jsonl> --seq 42

Inspect the export

aaesctl inspect --export <export.jsonl>

See the CLI reference for command details.

Try it now: the public sample pack

The pack contains a synthetic export of 16 sealed demonstration records (produced by the same cold-path tooling the live demos use, labelled as demonstration data), the public key, a tamper demonstration script, checksums, and standalone verifier binaries:

• sample-export.jsonl: the demonstration export (SHA-256 in SHA256SUMS.txt)
• sample-pubkey.txt: the public key for this synthetic sample. It is distributed separately from the export but through the same AAES-controlled site; this is not an independently authenticated key distribution channel
• tamper-demo.sh: verifies the clean export, flips one byte in a copy, and requires the verifier to refuse it with the documented chain and Merkle-root failures
• Verifier binaries: macOS (Apple silicon) · macOS (Intel) · Linux x86-64 · Linux arm64 · Windows x86-64 · Windows arm64, with publisher-supplied provenance in BUILD-INFO.txt. On Windows, run the demo in Git Bash or WSL.

chmod +x bin/aaesctl-<your-platform>
./bin/aaesctl-<your-platform> verify --export sample-export.jsonl --pubkey sample-pubkey.txt
bash tamper-demo.sh

Expected on the clean export: result: PASS. This means the verifier's integrity checks passed against the supplied public key; it is not an assurance verdict. The verifier also reports: every external timestamp is a noop placeholder: no third party attested to these heads and zero independent witnesses: AAES alone holds the only signature over this history. This demonstration shows internal consistency and detection of the specified edit. It does not establish independent attestation, capture completeness, event truth or enforcement. A party controlling the signing key could produce a different, internally consistent history. Expected on the edited copy: chain: FAILED, merkle root: FAILED, and exit 1. The head signature can remain valid because the signed head itself was not changed.

These are unsigned dev builds supplied for optional evaluation. SHA-256 checksums detect differences from the files listed in the manifest; because the manifest is distributed through the same site, they do not independently authenticate the binaries or protect against compromise of that distribution channel. Run only in a disposable evaluation environment, without production credentials, sensitive data or privileged access. Verifier source is available under a scoped evaluation; the core repository is private. BUILD-INFO.txt lists publisher-supplied provenance (build identifier, source revision, toolchain, supported platforms) which is not independently verified. Buyers whose policies prohibit unsigned downloads can request source review or request-based delivery during a scoped evaluation.

The verification public key is held by the client, not AAES. The verifier checks the export locally and does not call a network service.

A successful check is relative to the public key supplied. Reviewers must establish why that key is trusted for the deployment under review.

Offline integrity verification and independent attestation are separate claims. The public key used to verify the record does not, by itself, establish an independent witness.

Independent attestation requires a configured external witness or timestamp authority, with trust material obtained separately from the export. Neither is connected in the default deployment.

aaesctl verify --export <export.jsonl> --pubkey <key.pub> --witness-trust <trusted-witnesses.json> --require-independent

<trusted-witnesses.json> is a local path to separately obtained witness trust material. The --require-independent option requires independent attestation during verification. It does not configure a witness or create attestation for an export.

Default posture: zero independent witnesses. Do not describe a default export as independently attested.

Internal tests mutate sealed exports and require rejection, as described on the security page. The public sample pack's tamper-demo.sh runs one of those forgeries (a single flipped byte inside a sealed record) against the sample export on your own machine and requires the verifier to refuse it. These checks do not establish production validation or independent certification.

Truncation detection needs a retained checkpoint. A valid chain alone does not establish that later records have not been omitted. No external timestamp authority is wired yet.

Use the security page as the source for the stated internal checks. This page publishes a synthetic verification demonstration, not client evaluation results. Results from a client's test tenant are produced during a scoped evaluation.

Obtain an export from a deployment you operate, or through a scoped evaluation. Evaluation binaries are supplied through evaluation; the core repository is private.

The evaluation page states the control-evaluation scope and exit conditions. Use it to scope verification with your export, trusted key, and any separately configured witness material.