Cairn Framework

Part 14 of the Cairn series. This one is off the main road: it is about the paper-trading stock funds that run on the same home server as the rest of this work. I asked a panel of AI models why the funds never sold their losers and how to make them profitable. The answer was not the one I expected, and part of it was my own mistake. This is all paper money, and nothing here is financial advice. The question The funds are simulated. Each one holds a basket of picks chosen by a council of AI models, and none of it involves real money. I noticed that stocks down 30 percent were still held, and stocks up a lot were never trimmed. I asked, more or less, why the AI was not smarter than a person with a stop-loss. Then I asked for a plan to make the funds as profitable as possible. What the council found I put the numbers in front of five models and asked for a diagnosis. Two findings stood out. The AI verdict has no edge. Over seven days, stocks the council called BULLISH returned an ...

Part 12 of the Cairn series. Dev log 8 closed the loophole for agents that never held a grant. Since then there have been four changes, each audited by Gemini and by OpenAI: invariant I4 for the require-grants switch, hash-only action payloads, durable storage for the secrets those payloads leave behind, and language-neutral test vectors for all of it. This post covers all four, every audit round, and what the audits got wrong and right. Why this round exists Until now an ACTION entry on the log pointed at its arguments and its result by hash, and the blobs behind those hashes were published with the log. That is the right default for governance, because the replay has to read proposals, votes and grants. It is a poor default for what an agent actually did. A web fetch carries a URL. A tool call carries whatever the model decided to put in it. Putting every argument and every result next to a public log is a privacy problem that nobody asked us to create. The fix has to keep two pr...

Part 8 of the Cairn series. Two pieces landed: a server that sequences the log, and a second program that checks the server and signs only what it can verify. This one is mostly about what the tests found. Dev log 4 ended with an admission: nobody could append to a Cairn log over a network, because there was no log server. That is fixed. The second thing we said was missing, a witness on a separate machine, is also built. Neither is production software, and the end of this post lists what is still missing. The log server cairn-logd is a sequencer. It is the one process that decides the order of entries. The design rule is that nothing in it needs to be trusted, because everything it stores can be re-checked by cairn-verify . The server holds no signing keys . Validators and witnesses fetch the 81-byte checkpoint body, sign it themselves and post the signature back. The server publishes a checkpoint only once the signatures it holds pass the same check a verifier would run. Before...

Part 7 of the Cairn series. Phase 2 is partly built, a survey of similar projects changed the plan, and one external test vector is not a lot. The last dev log stopped at Phase 1: proofs, governance replay, a verifier CLI. This one covers what came after, in the order it happened, and ends with the piece we built most recently: a second way to publish a checkpoint so that other transparency-log tools can read it. Phase 2: the layer that sits in front of the agent Phase 2 added the parts that touch actual agents: a council that evaluates proposed rule changes, provider adapters, a review page, and a gatekeeper . The gatekeeper sits between an agent and its tools. For each call it checks the agent's allow list, writes an intent entry to the log, runs or refuses the call, and writes a completion entry. We keep saying what it is not, so once more: it is a policy layer in the process that calls it. It is not a sandbox . An agent that finds another way to reach a tool is not held by...

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...