Cairn Framework

Part 6 of the Cairn series. Phase 1 is partly built, and we say exactly which part. Watch the 53-second explainer A 53-second explainer is at the top of this post, in case you are new to the project. The rest is what happened since the last dev log. Two models audited the code We gave the verifier source ( wire/ and ledger/ , about 1,100 lines) and the SPEC to two different models, Google's Gemini and DeepSeek's reasoner, and asked each for real defects only. Then we checked every claim against the code before touching anything. Gemini returned three findings, all rated low. DeepSeek returned eleven, one rated high. They agreed on the most important one and disagreed on its severity. Real, and the worst: small-order Ed25519 keys. Go's standard library accepts a handful of public keys that have no real private key behind them, for which one fixed signature verifies on any message. An entry claiming such an author passed signature checks. Gemini called it low because...

Part 5 of the Cairn series. An outside review found two real problems and one wrong complaint. A project that says "don't trust, verify" shouldn't grade its own homework. So after posts 1 to 4 were written, we gave all four to a different model family (Google's Gemini) together with the real SPEC and the raw output of the tamper suite , and asked it to be adversarial: find factual errors, overclaims and flawed security reasoning. It scored the series 7.5 out of 10 and raised five points. We checked every one against the repository instead of taking its word. Here is how they came out. Real: the SPEC named two error codes differently from the code The SPEC said a checkpoint with too few witnesses fails with below_witnesses , and a malformed checkpoint with bad_checkpoint_length . The code, and the committed test vectors, use below_witness_threshold and bad_checkpoint . The vectors are the ground truth, so the SPEC was wrong. A second implementation written f...

Part 4 of the Cairn series. The first sandbox experiment, with real numbers. Parts 1 to 3 explained what Cairn is and why. They were claims. This post is the first time we test one of them in public: if someone changes a single bit of the log, will an outside checker notice? The claim in the design is that an outside party holding only the log bytes, the checkpoint bytes and the public trust configuration can detect tampering. Let's find out how true that is. The sandbox Every experiment in this series runs in a throwaway container: golang:1.24-alpine , no network at all ( --network none ) 1 GB memory, 2 CPUs, a process limit the source mounted read-only, with the work copy on a RAM disk that disappears afterwards The code under test never touches anything real, and nothing it does can leave the box. It is the same discipline we want from the agents Cairn will eventually govern. One honest limit: the Go race detector needs a C compiler, which the offline container doesn...

Part 3 of the Cairn series. What the finished system does in practice. Parts 1 and 2 covered the why and the how. This post walks through five concrete situations. Each one describes the design the full system is aiming at. Today only the ledger core exists (Phase 0). The gatekeeper, review workflow and fleets come in Phases 1 to 3, so read these as specifications of behaviour, not a demo. 1. The coding agent and the quiet prompt edit Situation. A team gives an AI agent permission to open pull requests and run tests. A month later a bad change ships, and nobody can say which prompt and model produced it. With Cairn. The agent's system prompt, tool list and model are all loaded only from activated ledger entries. Editing the prompt means a PROPOSAL that names the diff and an evaluation result, reviewers' VOTEs, and a delay of a day for prompt wording. Every pull request the agent opens is recorded as an ACTION entry (the design logs intent before the agent acts; see the...

Part 2 of the Cairn series. The short version of the "how," with the real numbers. Part 1 said what Cairn is for. This post shows how the ledger actually works, at the level where you could check it yourself. Everything here is specified in docs/SPEC.md , and the test vectors in testdata/vectors-v1.json are the final authority where the two ever disagree. One entry, 178 bytes Every event in Cairn is one fixed-size entry: version (1 byte), always 1 for now height (8 bytes): 0 for the first entry, then one more each time prev_hash (32 bytes): the hash of the entry before it kind (1 byte): what sort of event this is payload_hash (32 bytes): the SHA-256 of the event's details, stored beside the log author (32 bytes): the Ed25519 public key of whoever wrote it time (8 bytes): unix seconds, and advisory only , never used for ordering signature (64 bytes): the author's signature over everything above That is 178 bytes. The details (a prompt diff, a vote comme...

Introducing Cairn, a tamper-evident ledger for AI agents. 30 September 2026. An AI agent today can read your email, open a pull request, call an API and spend money. It does this on the strength of a prompt, a list of tools, a model version and a set of permissions. Any of those can change overnight, and if something goes wrong, the honest answer to "what changed, who approved it, and when?" is usually "we don't know." Cairn is an attempt to fix that, and this post explains what it is, what it will let you do, and where it is useful in the real world. It also says plainly what exists today, because a security project that oversells itself is worse than none. The two problems Silent change. Nothing stops someone editing an agent's system prompt, swapping its model or widening its permissions. Even if you have version control, the person who can edit the repo can also edit the history, and nobody outside can check. Manipulation. Anything an agent reads...