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 10 of the Cairn series. Dev log 6 was the OpenAI audit. This one covers what we built since, the two audits of it, and, because we were asked for it, the pains and mistakes of the project so far, not just the progress. What got built Cairn is a tamper-evident log of what AI agents were allowed to do and what they did. Until now the log could say who may delegate a capability (invariant I11: a grant handed down must be strictly narrower than the one it came from). It could not say whether an agent then stayed inside the grant it held. That gap was written into the roadmap as "I11 only as far as delegation", and it was the next thing to close. It is closed for agents that hold a grant. Replay now checks every action an agent logs against its grant: Tool. The action type must be in the grant's tool list. Host. The host the action declares must be in the grant's host list. Expiry. A grant past its not_after time permits nothing. Budget. Each action declar...

Part 9 of the Cairn series. Dev log 5 shipped a log server and a witness. This one is about the outside review that followed: what it found, what we fixed, and what we decided not to. Every earlier audit of Cairn used Gemini, with DeepSeek on a few passes. Models from one family share blind spots, so we ran a different one. We gave gpt-5.5 the code verbatim, pasted from git diff and cat rather than retyped, in four separate passes: A: ledger, governance and the verifier. B: review, gatekeeper and providers. C: log server, witness and CI. D: every phase in the roadmap, plus every public claim in the README and docs. Each pass was asked for ranked findings, trigger conditions, tests that would pass even if the code were wrong, and documentation that overclaims. Each ran three to four minutes. We then checked every finding against the repository before changing anything. A model reviewer is a lead generator, not an oracle. Here is how the leads came out. Where it was right and...

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