Git shows you what changed. ARF shows what the agent decided, why, under what policy, at what cost, with what approval, in what order, and makes the record impossible to deny or alter. The Attestation & Record Foundation is not a log file. It's a proof bundle.
Every event in an ARF session (request, response, policy decision, approval, circuit breaker state change) is serialized to a canonical JSON record and signed with the ARF instance's Ed25519 signing key.
Each record includes the SHA-256 hash of the previous record. This creates a hash chain. To forge or alter any record, you'd need to recompute every subsequent hash, then forge the Ed25519 signature. With sane key management, that is computationally infeasible.
The chain is stored in a local append-only log. On session seal, ARF produces a proof bundle: a self-contained archive with the full chain, the signing public key, and a verification manifest. Give the bundle to an auditor and they can verify every record without the ARF instance.
When multiple agents work in parallel (say, three agents on three different feature branches), a linear hash chain breaks down. You need a structure that can represent concurrent, branching work and converge it into a single proof.
ARF uses a Merkle DAG for concurrent sessions. Each branch keeps its own hash chain. Merge events become DAG nodes with multiple parent hashes. The root of the merged DAG is a single hash that commits to the entire history of all branches, provably, in one value.
This is how ARF handles orchestration: parallel agents, independent chains, Merkle convergence at the merge point. The compliance bundle for a merged session includes the full DAG, every branch chain, and the convergence proof.
ROOT d4e8f01… │ ├─ MERGE 9b12e4a… │ ├─ Branch-A a3f72c1… │ │ ├── req #1 e7f3a9c… │ │ ├── req #2 c1b2d3e… │ │ └── req #3 f4a5b6c… │ │ │ ├─ Branch-B 7d8e9f0… │ │ ├── req #1 1a2b3c4… │ │ └── req #2 5d6e7f8… │ │ │ └─ Branch-C 0a1b2c3… │ └── req #1 9e0f1a2… │ └─ session.seal b3c4d5e… Verify: arf verify ./proof-bundle.tar.zst ✓ All 3 branches valid ✓ Merkle root matches ✓ Ed25519 signatures valid
Every ARF session gets a ULID (Universally Unique Lexicographically Sortable Identifier). ULIDs are time-ordered, so session timeline reconstruction is trivial. Each request inside a session also gets its own ULID for sub-session attribution.
ARF writes session metadata into git notes on each commit made during a governed session. Pull up any commit with git notes show and see the ARF session ID, policy profile, token cost, and proof bundle hash.
Request latency, token throughput, tool call frequency, policy evaluation time, and cost per request are all captured in structured telemetry. Export to Prometheus, Datadog, or ARF's built-in session analytics.
Run arf provenance export --session [id] --compliance to produce a self-contained compliance bundle: full proof chain, metadata, policy state, and a human-readable PDF summary. Ready for SOC 2 auditors, legal review, or incident investigation.
Each agent session gets a human-readable call sign (e.g., IRON-WOLF-7, COPPER-ANVIL-3) for quick identification in the TUI, in git notes, and in exported bundles. Easier to scan than raw ULIDs.
Any ARF instance, including a cold install with no session history, can verify a proof bundle. The public key is embedded in the bundle. Verification is a single command with a deterministic pass/fail result.
Every event in an ARF session produces a JSON record. The records are canonical (keys sorted, no whitespace variation) before signing and hashing. This is what a tool-call approval event looks like:
The prev_hash field binds this record to the previous one. The hash field is the SHA-256 of the canonical JSON of the entire record (including signature). The signature signs the SHA-256 of the record body (all fields except signature and hash).
Binary files (images, Blender files, PDFs, compiled artifacts, STL/STEP for CAD) can't be diff'd meaningfully. ARF's binary provenance system tracks size, SHA-256 content hash, and git commit for each binary file across the session.
Each change to a binary file produces a provenance record with the before and after hashes. The records are chained to the session. If a binary file's hash changes unexpectedly between commits, ARF detects it and flags the deviation.
Python plugins for Blender and Fusion 360 integrate directly with ARF's provenance system. Each save operation records a hash event. The plugin's begin / modify / commit protocol tracks 3D asset changes with the same cryptographic guarantees as code changes.
The Rust SDK (ArfClient) provides methods for reading and verifying the provenance chain. See the SDK page for the full reference.
The Audit screen shows every event in the current session as it happens. Navigate the Merkle DAG with arrow keys. Press Enter to expand a record and see the full JSON payload, signature, and parent hash.
Filter by event type with f. Search with /. Export a compliance bundle with e.
