The chain
How the chain works
Atested's whole value rests on the chain being trustworthy. If the record can be quietly edited, the governance is theater. This page is the proof that it can't be. Not as marketing claims, but as specific technical commitments you can verify with the tools Atested ships with.
Append-only, hash-chained, signed
Atested's chain has four properties working together.
Append-only
Records are added to the end of the chain and never modified in place. The chain file is opened in append mode (O_APPEND), with a cross-process mkdir-based lock protocol (INV-010) to prevent concurrent writers from corrupting the tail. The head hash is read inside the lock, and the new record is written atomically. There is no code path in Atested that rewrites existing records. Append-only is enforced, not just claimed.
Hash-chained and immutable
Each record contains a SHA-256 hash of the previous record. Any change to any record — even a single byte — changes that record's hash, which breaks the next record's reference, which breaks every subsequent record. The cascade is the point: you can't edit one record in the middle without leaving evidence that extends to the end of the chain. When Atested detects a hash-chain break, it records the break event, classifies it (restart vs. corruption vs. truncation), and surfaces it in the dashboard.
Ed25519 signed
Each record is cryptographically signed with an Ed25519 key generated on your machine. The signature covers the record's contents including its hash references to the previous record. The private key never leaves your machine. Verifying the signature requires only the public half, which means anyone you share the chain with — an auditor, a regulator, a colleague — can verify it was authored on your machine without needing your private key or any Atested software.
On your disk
The chain lives at gov_runtime/LOGS/decision-chain.jsonl on your machine. Atested never transmits the chain file to Atested servers. In multi-machine installs, remotes sync signed records to the primary you control. There is no cloud chain custody, no backup service, and no telemetry that includes chain content.
How verification works
Atested ships with a verifier. It walks the chain from beginning to end, recomputing each record's hash, checking each reference against the recorded prior-hash, and verifying each signature against the key fingerprint recorded alongside it. If everything matches, the chain passes. If anything is off, the verifier reports the exact record where the break occurred.
You don't have to take Atested's word for the chain's integrity. You run the verifier and look at the output. The verifier is in the same repository as the proxy, written in the same language, reading the same files.
The invariants
Atested publishes the guarantees the governance layer holds itself to. These are the invariants, the specific properties that must be true for the chain to be trustworthy. If any invariant is violated, the system has failed, and the verifier will show you.
INV-001
No privileged action without a decision record.
INV-002
No decision record without a completed policy evaluation.
INV-003
No policy evaluation without action capability metadata.
INV-004
Logs are append-only and tamper-evident via hash chaining.
INV-005
Trust-grade records are signed; verifier must validate chain + signatures.
INV-006
Any denial must include machine-parsable reason codes.
INV-007
Any redaction must be explicit; never silently drop args/evidence.
INV-008
Replay verifier must reproduce policy outcomes for stored inputs.
INV-009
Unknown actions are auto-classified to the nearest governance category and evaluated normally. Learned mappings are persisted.
INV-010
Every writer to decision-chain.jsonl must acquire the chain lock protocol before reading the head hash and appending.
The full list lives in the repository. Every invariant has a number, a short name, and a rationale. When a new one is added, the commit shows when and why.
What can be verified externally
Atested's governance layer is open source. You can read the code for the classifier, the policy rules, the chain recorder, the verifier, and the cryptographic primitives. You can audit how signatures are computed, how records are written, how the lock protocol works, and how the chain handles the boundary between older unsigned records and newer signed ones.
The chain itself is a local file. It moves with you. Export matching records from Audit Search as JSON, CSV, or Excel — all exports require license key authentication and every export is recorded in the chain. For sharing chain evidence with others, create an encrypted evidence package from the Chain Walker: select a range of records, set a password, and Atested produces a ZIP containing the encrypted payload, manifest, and a self-contained browser viewer. The viewer decrypts client-side, verifies hash linkage, and renders the evidence in both a plain-language and a technical view. No install, no Atested account, no network dependency.
Archives
When Atested detects a chain integrity violation at startup — the chain file is missing, truncated, shorter than expected, or its tail hash doesn't match — it archives the existing chain before starting a fresh one. The old chain is moved to gov_runtime/LOGS/archive/ alongside a manifest recording when the archive was created, why, how many records it contains, and the last record hash. Atested never deletes archived chains; disk retention is your decision.
Atested also archives chains based on size. When the live chain exceeds the size threshold (default 20 MB), Atested moves it to the archive directory and starts a fresh chain. A 60-minute quiet period prevents repeated archiving during busy bursts; if the chain reaches 2x the threshold, the quiet period is overridden. Size-based archiving runs in a background thread and never blocks policy evaluation or chain writes.
Each archived chain gets two derived artifacts: a .summary.json with pre-computed counts (by decision, tool, user, category) and a .sqlite database with indexed columns for fast queries. The SQLite artifact includes a SHA-256 hash of the source archive for integrity verification — if the hash doesn't match on access, the artifact is regenerated from the source.
Archived chains are not abandoned. The Activity, Reports, and Audit windows each offer a Live / + Archives toggle. When + Archives is active, queries merge live chain data with archive SQLite data transparently. The Chain Walker can switch between the live chain and any archive from the source picker. You can step through an archived chain, use playback, jump to alerts, and create evidence packages from archived records the same way you would from the live chain.
Background verification
Atested automatically re-verifies the entire chain every 100 records (configurable via ATESTED_CHAIN_VERIFY_EVERY_RECORDS). Verification runs in a background thread and never blocks chain writes. Results are written to a status file and fed into the Health display. When the verifier detects a hash-chain break, Health shows the break reason and a button that opens the Chain Walker centered on the exact record where linkage failed. See Health in the dashboard docs.
Runtime integrity events
The chain is now paired with integrity metadata and startup/runtime checks. Atested records which proxy code hash and policy rules hash were active, and it detects missing or truncated chain files after first run.
proxy_startup_code_hash
Recorded at startup with the current critical proxy source hash.
proxy_code_hash_changed
Recorded when the proxy source hash changes between runs.
policy_rules_loaded
Recorded at startup with the hash of capabilities/policy-rules.json.
policy_rules_changed
Recorded when policy rules change during operation. Atested denies operations until acknowledged.
chain_integrity_violation
Recorded when the chain file is missing, truncated, or does not match expected integrity metadata.
For the full runtime integrity reference, see Integrity monitor.
Where trust can still break
The chain proves the governance process was followed, not that the downstream outcome was correct. That distinction matters.
The proxy records its critical source hash at startup and records code changes. The policy rules hash is recorded and checked before every policy evaluation. The chain file is checked against integrity metadata so missing, truncated, or changed history is detected instead of quietly replaced. When a violation is detected, the old chain is archived with a manifest before a fresh chain begins — nothing is silently discarded.
What remains is the boundary between decision evidence and real-world effect. The chain records what Atested saw, how it classified that evidence, what policy decided, which code and policy hashes were in force, and who signed the record. It does not prove an external command behaved exactly as its parameters suggested, that an allowed operation produced the right business result, or that the human behind a valid key was the intended operator.
That is the honest trust model: Atested makes the governance trail durable, inspectable, and tamper-evident. It does not replace operational review, identity controls, or judgment about outcomes.
Start attesting your AI operations
Stop worrying and start knowing in less than five minutes.