Offline verification

The verifier checks whether the export is internally consistent and signed under the public key you supply. It checks the projected entry fields, record-hash commitments (fingerprints of stored records), chain, tree head (a signed summary of the history), and anchors.

The export contains selected fields rather than the entire stored record.

To check authorization scope, approver attribution or other stored-record fields against those commitments, obtain the aaes.records/v1 sidecar, a separate file containing the stored records, and perform its separate binding check with aaesctl evidence verify. The public aaesverify CLI checks the export only.

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 tasks that bypass AAES Govern 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

aaesverify v0.2.0 and v0.3.0 are open source under Apache-2.0. No vendor account or separate evaluation authorization is required to use it under that license.

aaesverify --export <export.jsonl> --pubkey <key.pub>

Download the reviewer worksheet (Markdown) to record file provenance, clean and tampered verification results, and remaining uncertainties. It also includes a separate checklist for scoped agent-action evaluations. All result fields start as not run.

The public sample pack

The pack contains a synthetic export of 16 sealed demonstration records (produced by the same offline export tooling the live demos use, labeled as demonstration data), the public key, a tamper demonstration script, checksums, and the public aaesverify v0.2.0 release 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.

The public Apache-2.0 aaesverify v0.3.0 source and release binaries verify the aaes.export/v3 exports that current AAES Govern deployments write, and retained aaes.export/v2 exports such as the public sample. The earlier v0.2.0 release reads v2 only.

The offline demonstration commands are:

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

Expected on the clean export: aaesverify v0.3.0 prints result: CONSISTENT for this witness-less check and reserves result: PASS for independent attestation. The v0.2.0 binaries in this pack print result: PASS; in v0.2.0 that word means the integrity checks passed against the supplied public key. It is not independent attestation, and 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.

The binaries come from the public aaesverify v0.2.0 release. BUILD-INFO.txt records publisher-supplied provenance: source revision, exact toolchains and native test scope. SHA-256 checksums detect differences from the listed files; they do not independently authenticate the binaries. The manifest is unsigned and shares the publisher's distribution channel. Review and build the public source locally if your policy requires that.

The acceptance test: verify with AAES off

The property an auditor can rely on, stated as a procedure. Using the Apache-2.0 verifier, run it on the sample pack above, or on an export from a deployment you operate. Current deployments write aaes.export/v3, which aaesverify v0.3.0 reads; v0.2.0 refuses it.

1. Export a record bundle from the deployment under review and retain the deployment's public key through a channel you control, not a key bundled with the export.
2. Stop the AAES service. Disable networking on the verification machine, or use a machine that never had it.
3. Run the verifier against the retained export with the authenticated public key: aaesverify --export <export.jsonl> --pubkey <key.pub>.
4. Expected from aaesverify v0.3.0: result: CONSISTENT on a witness-less export, and result: PASS only when an independent witness or independent timestamp is pinned. aaesverify v0.2.0 prints result: PASS for a consistent export, meaning integrity against the supplied key only. Then copy the export and change one byte in the first entry's record-hash commitment (the same documented edit tamper-demo.sh automates), and re-run: expected chain: FAILED, merkle root: FAILED, exit 1.
5. After the export and key are retained, no AAES service, vendor account, or network call participates in verification. The public Apache-2.0 aaesverify v0.3.0 source and binaries read aaes.export/v3 and aaes.export/v2; v0.2.0 reads only aaes.export/v2, including this sample.

What passing establishes is integrity of the retained records against the supplied key, nothing more: the limits in section 02 still apply. What this shows is that verifying retained records needs no running AAES service and no vendor account.

In a client-operated deployment, the signing key is created and held inside the client's boundary; AAES, the vendor, holds no copy of a client deployment's private key. In an AAES-hosted deployment, the client agreement defines who holds the signing key and who can access it. The client retains the public key, and should retain signed heads and exports, for later verification. The verifier checks the export locally and does not call a network service.

The synthetic sample pack uses a publicly reproducible demonstration key, as disclosed in BUILD-INFO.txt; anyone can derive its private half and sign another sample.

Its output warning about AAES holding the only signature means there is no independent attestation, not exclusive possession of that demonstration private key; a client deployment's history is signed by that deployment's own key.

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.

An independent witness or timestamp authority is a separate party that signs evidence about the recorded history. Independent attestation requires one to be configured, with trust material obtained separately from the export. Neither is connected in the default deployment.

aaesverify --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 in the first entry's record-hash commitment) 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.

Detecting records removed from the end of the history (truncation) needs a retained checkpoint: a previously saved signed summary to compare against. A valid chain alone does not establish that later records have not been omitted. No external timestamp authority is configured by default.

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.

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.