Check the record. Understand its limits.
This page explains the mechanisms, the threat model and the limits. It is written for the person who has to check, not the person who has to buy.
Ask for the pack- hash
- sha-256
- format
- jsonl
- checkpoint
- signed
- verifier
- open source
- head
- d02b6f19
Each entry seals the one before it.
Every entry's hash is computed over its own fields and the hash of the previous entry. The first entry seals a genesis record. Changing an entry without recomputing the following chain is detectable. A trusted checkpoint held separately is also needed to detect a complete chain rewrite.
Tamper-evident means changes can be detected against a retained chain and trusted checkpoint. It does not make the host or storage tamper-proof.
-
01crm.readallowprev genesismismatchhash 3f61a0c9
-
02docs.searchallowprev 3f61a0c9mismatchhash a84d2e17
- gap: seq 03 missing
-
03payments.queryallowprev a84d2e17mismatchhash c2917b5e
-
04payments.transfer · 24,500 GBPholdprev c2917b5emismatchhash 6e0f93ad
-
05approve 04 · a.khanallowprev 6e0f93admismatchhash f57c4b20
-
06mail.send · externaldenyprev f57c4b20mismatchhash 1b9e6d4c
- 01
Hash
SHA-256 over the canonical JSON of the entry.
- 02
Anchor
A signed checkpoint records the chain head. Independently protected storage and scheduled publication must be configured and verified for a pilot.
- 03
Verifier
Open source, one command, no licence.
The same inputs, the same policy version, the same verdict.
A recorded decision can be reviewed alongside its policy identity, rule, arguments and prior state. Re-running it reproducibly requires retaining those inputs and the exact policy. The preview below illustrates that review; it is not a live verification service.
Replay is how a decision made in July is explained in December.
Drag the marker along the ledger to replay any entry.
- seq
- 18204
- ts
- 2026-09-05T07:41:12Z
- agent
- ops-agent-07
- action
- payments.transfer · 24,500 GBP · Northwind Ltd
- policy
- pay-core v3.2
- rule
- transfer-high-value
- verdict
- hold
- hash
- d02b6f19
What Cairn defends against, and what it does not.
Defends against
- 01
A compromised agent. Prompt injection, a hostile tool result, a poisoned document: whatever the cause, the agent's tool calls still pass through the policy engine.
- 02
Tool misuse. An action that is technically permitted but out of policy is held or denied by rule, not by hoping the model refuses.
- 03
Changes to retained records. Hash verification detects inconsistent entries. Detection of a full rewrite also requires a trusted checkpoint held separately.
- 04
Unexplained decisions. The recorded policy identity and rule help an examiner trace why an action was allowed, held or denied.
Does not defend against
- 01
A compromised host running Cairn itself. Hash chaining cannot protect the running process. Strong access controls, separately held checkpoints and tested recovery are required deployment controls.
- 02
A tool that lies. Cairn records what was asked and what was answered. It does not verify that the payments system did what it said.
- 03
Bad policy. Cairn enforces the rules you write. Range exists so you can find out what they miss.
Designed against the frameworks your assessors already use.
Cairn is built to produce the records that these frameworks ask for. It is not certified against them, and this page will say so plainly until it is.
| framework | what it asks for | what cairn produces |
|---|---|---|
| NCSC guidelines for secure AI system development | Logging, monitoring and controls around model actions | A control point on connected tool calls and a record of each verdict |
| ISO/IEC 42001 | Evidence of AI governance controls operating as designed | Versioned policies, approval records and a replayable ledger |
| EU AI Act, record-keeping obligations | Automatic logging over the lifetime of a high-risk system | Hash-chained entries and signed checkpoints; external anchoring requires deployment |
| UK GDPR, Article 5 | Integrity and accountability of processing records | Argument digests instead of clear payloads; a chain that shows any change |
Framework names are given for orientation. Mapping to specific clauses is provided in the assurance pack.
Open where trust needs it, commercial where it does not.
The ledger format, the hash chain and the verifier are open source under a permissive licence. Anyone can read a Cairn ledger and confirm it is intact without a licence, a login or a call to us.
Policy authoring, the approvals workflow and Range are commercial. The line is drawn so that the evidence never depends on the vendor.
The format specification and the verifier source are included in the assurance pack.
$ cairn verify --anchor https://example.org/anchors/latest chain intact · 18,204 entries · 0 gaps anchor 2026-09-05T07:00:00Z matches · head d02b6f19
- 01
Ledger format
JSON Lines, documented, versioned.
- 02
Verifier
One binary, one command, reproducible build.
- 03
Anchors
Published to a store you choose.
Check it yourself.
Format specification, verifier source, threat model in full and the framework mapping. Sent to assessors on request.