Assurance

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
01

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.

Break the chainsample data 6 entries · policy pay-core v3.2
  1. 01crm.readallow
    prev genesishash 3f61a0c9
  2. 02docs.searchallow
    prev 3f61a0c9hash a84d2e17
  3. 03payments.queryallow
    prev a84d2e17hash c2917b5e
  4. 04payments.transfer · 24,500 GBPhold
    prev c2917b5ehash 6e0f93ad
  5. 05approve 04 · a.khanallow
    prev 6e0f93adhash f57c4b20
  6. 06mail.send · externaldeny
    prev f57c4b20hash 1b9e6d4c
$ cairn verify ledger.jsonl chain intact · anchor matches
  1. 01

    Hash

    SHA-256 over the canonical JSON of the entry.

  2. 02

    Anchor

    A signed checkpoint records the chain head. Independently protected storage and scheduled publication must be configured and verified for a pilot.

  3. 03

    Verifier

    Open source, one command, no licence.

02

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.

Replaysample data ledger.jsonl · seq 18196 to 18204

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
replay · policy v3.2 loaded · verdict hold · matches
03

What Cairn defends against, and what it does not.

Defends against

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

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

  3. 03

    Changes to retained records. Hash verification detects inconsistent entries. Detection of a full rewrite also requires a trusted checkpoint held separately.

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

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

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

  3. 03

    Bad policy. Cairn enforces the rules you write. Range exists so you can find out what they miss.

We publish this list because an assurance product that claims to cover everything cannot be trusted about anything.
04

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.

frameworkwhat it asks forwhat 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.

05

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 illustration
$ cairn verify --anchor https://example.org/anchors/latest
chain intact · 18,204 entries · 0 gaps
anchor 2026-09-05T07:00:00Z matches · head d02b6f19
  1. 01

    Ledger format

    JSON Lines, documented, versioned.

  2. 02

    Verifier

    One binary, one command, reproducible build.

  3. 03

    Anchors

    Published to a store you choose.

For assessors

Check it yourself.

Format specification, verifier source, threat model in full and the framework mapping. Sent to assessors on request.