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 three properties working together.
Append-only means records are added to the end of the chain and never modified in place. The chain file is opened in append mode, with a cross-process lock to prevent concurrent writers from corrupting the tail, and no code path in Atested rewrites existing records.
Hash-chained means 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. You can't edit one record in the middle of the chain without leaving evidence that extends to the end of the chain.
Signed means each record is cryptographically signed with an Ed25519 key stored on the machine running Atested. The signature is computed over the record's contents including its hash references. Verifying the signature requires only the public half of the key, which means anyone you share the chain with can verify it was authored on your machine.
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 rules 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.
The current invariants include: no governed action without a decision record. No decision record without a completed policy evaluation. Logs are append-only and tamper-evident via hash chaining. Trust-grade records are signed, and the verifier must validate both the chain and the signatures. Every denial must include machine-parsable reason codes. Every redaction must be explicit. Atested never silently drops evidence. And every writer to the chain must acquire a lock before reading the head hash and appending, because a race between concurrent writers was the cause of a real corruption incident Atested learned from.
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. You can export it, archive it, share it with an auditor, hand it to a compliance reviewer. They verify it with the same tools Atested ships with, running on their own machine, against the public key you share. No network dependency, no third-party verification service, no Atested-controlled endpoint in the verification path.
Where trust can still break
Atested is honest about what the chain does and doesn't prove.
The chain proves what was decided, not what happened. If Atested allows a command and the command runs and does something other than what the agent claimed it would do, the chain faithfully records that Atested allowed it. It doesn't know what actually executed.
The chain proves the record was authored on a machine holding the signing key, not that the operator at that machine was the person you think they were. Operator identity is a separate layer Atested is building and will ship when it's ready. For now, signatures prove the machine, not the human.
The chain proves integrity against tampering after the fact, not against a malicious writer at the moment of writing. If an attacker with code execution on your machine modifies the proxy to write false records, the chain will verify because the signature is computed by the same compromised code. The threat model is an honest proxy producing verifiable records, not a compromised proxy that still somehow proves its honesty. These limits are not bugs. They're the boundaries of what a software governance layer can honestly claim.