When a regulator asks how a firm used AI on a matter, most firms are in trouble before they open their mouth. Not because they did anything wrong: because they cannot prove they did anything right. The record is scattered: drafts in a version history, a fee-earner's notes in email, the AI tool's own logs in a separate vendor portal, if those logs still exist. Reconstructing what happened is an afternoon's work and, when it is done, it is still just an assertion. "This is what we think happened." An open question, not evidence.

The signed reasoning ledger closes that question.

What the ledger records

Covered runtime paths write AI and human-decision events to the ledger. The result is a readable record of events that were successfully written. It is not a claim that every AI step or every product path is captured; known write failures are surfaced.

Note carefully what the entry contains, because this is where privilege and evidence had to be reconciled. The input is recorded as a fingerprint: a hash, never the prompt text in the clear. The output is stored as an excerpt, alongside call metadata such as model, tokens, skill and timestamp. HMAC authentication and chain links can reveal alteration when verified with the firm-held key. The mechanism is tamper-evident, not tamper-proof, and a record does not prove that an unrecorded event did not occur.

Why "signed" is the load-bearing word

A log you can quietly edit is not evidence: it is a claim with extra steps. So each entry is HMAC-signed under a per-firm secret, and the entries are hash-chained: each links to the one before it, so any tampering breaks the chain and shows. At the close of each UTC day, the chain's position is sealed under the firm key. That gives an auditor one line to check per day instead of a walk through every row, and it fixes that day's record: rewrite a sealed day afterwards and the seal stops matching, even if the hash chain itself is carefully repaired.

When the moment comes, you export a readable audit pack in markdown or CSV. The firm-held HMAC key is not included, so the pack cannot independently verify itself. A reviewer needs the firm-controlled verification step and must keep the coverage limits in view.

Honest about who this is for, and what is live

The ledger runs today, on every plan: append-only, HMAC-signed, daily-sealed, exportable in one click. There is no tier gate on it and we are not adding one. A compliance record you can only afford at the top of the price list is not much of a compliance record.

What is not built is per-office cryptographic isolation. A multi-office firm today keeps one ledger for the firm, not one sealed ledger per office. This page previously described that isolation as shipped, which is precisely the kind of claim this ledger exists to make impossible: so: it is on the roadmap, and it is not in the product.

The difference this makes

General-purpose tools keep session logs. This ledger adds HMAC authentication, chain links and daily seals to the events it records. Those controls improve the firm's ability to detect alteration; they do not turn the export into independent proof.

That distinction matters in a regulatory review. Built for solicitors, the ledger provides qualified, tamper-evident records while stating exactly what it does not establish.

← All posts