AVAR spec

Aarmos Verifiable Action Record · AVAR 1.0 (Normative) · avar/1

Receipts that survive the vendor.

AVAR is the receipt format Aarmos emits for each governed action. It is open, unencumbered, and portable. Every AVAR bundle's integrity verifies against the Ed25519 public keys included with it — no Aarmos service required, no proprietary parser, no license lookup. Attributing a bundle to a particular signer additionally needs that signer's key from a channel you trust.

The commitment. AVAR is not a proprietary format we hold hostage. Receipts verify offline against the bundle's contents and independently pinned trust material — no Aarmos server is contacted during the check — and we refuse to build format lock-in as a moat.
What is publicly available today. The in-browser verifier and the @avar-standard/verify and @avar-standard/core libraries on public npm (Apache-2.0). The normative specification repository, the clean-room reference implementation and the conformance suite are not currently publicly published.
Status: AVAR 1.0 (Normative). The wire format, canonical JSON rules, and chain algorithm are frozen, and the normative fixtures are the specification of record — an implementation conforms when it reproduces them. Additive changes land as minor revisions (avar/1.1, avar/1.2) that stay readable by earlier avar/1 verifiers.
v2 extension. Access-model receipts add an x-access-v2 block (action, resource, tenant, policy_hash, obligation ledger) inside each entry. The extension is additive — older avar/1 verifiers ignore it per §2.3. Vocabulary at /docs/actions.

Bundle layout

An AVAR bundle is a ZIP archive with a fixed member set. See spec §5 for the normative definition.

bundle.avar.zip
├── SPEC-VERSION        # exact bytes: "avar/1"
├── manifest.json       # bundle metadata, entry count, chain tips
├── entries.ndjson      # one signed AvarEntry per line, chain-ordered
└── pubkeys.json        # { kid → raw Ed25519 public key (base64url) }

Verification algorithm

Every conforming verifier runs the same steps against the bundle. The normative sequence is in spec §6 (the specification text is not currently publicly published).

  1. Read SPEC-VERSION; reject unknown majors.
  2. Parse manifest.json and pubkeys.json. Load each entry from entries.ndjson.
  3. For each entry, canonically re-serialize the signed body (entry minus signature and devicePubKey) and verify Ed25519 against the devicePubKey in pubkeys.json for the matching kid.
  4. Recompute each entry hash from its canonical bytes; recompute per-step hashes; check that prevHash chains correctly from genesis.
  5. Emit a VerificationReport: overall verification result plus per-entry status (valid, unsigned, tampered, unchained).

What AVAR does not carry

  • Full prompts, chats, or tool-call arguments in the clear — only content hashes.
  • User credentials or vault contents.
  • Any pointer to Aarmos-hosted services. AVAR is a self-contained evidence file.

Verifier

Publicly available today: the browser drop-zone at /trust/verify and the @avar-standard/verify library on npm. The aarmos verify command in the evaluation CLI (approved evaluators; not publicly issued) and the standalone avar binary (not currently publicly distributed) share the same verification code; divergence is guarded by golden fixtures. Example output from the evaluation CLI:

aarmos verify path/to/bundle.avar.zip

✓ verification: valid
  entries:   N
  signed:    N
  unsigned:  0
  unchained: 0

verified locally — no Aarmos service was contacted.

← Back to quickstart · Trust & governance