Concepts

The Ledger

An append-only, hash-linked, signed record of every advice decision in your firm.

The ledger is the foundation everything else in Bedrock is built on. Conceptually it is a single linked list per firm. Each entry contains the canonical hash of the advice artefact, the metadata describing it, the previous entry's hash, a sequence number, and an ed25519 signature.

Why it's built this way

The FCA does not, and never will, accept “trust us, we've got a database.” The whole value of the ledger comes from the fact that it is impossible for the firm — or Bedrock — to retroactively edit it without the edit being visible to anyone holding any earlier certificate. This is what an immutable system of record actually means.

We get this property by chaining records together: each entry includes the hash of the previous one, and the whole thing is signed. Tampering with any historical entry breaks every certificate issued after it.

What's in an entry

json
{
  "id": "rec_01HX5...",
  "firmId": "firm_01HW1...",
  "sequence": 184321,
  "eventType": "DOCUMENT_APPROVED",
  "previousHash": "8a3f...",
  "contentHash": "b5e9...",
  "signature": "7c20...",
  "signedAt": "2026-04-07T12:35:01.000Z",
  "metadata": {
    "documentType": "SUITABILITY_REPORT",
    "clientReference": "client-12345",
    "reviewerId": "user_01HW2..."
  }
}
  • sequence — monotonically increasing per firm; gaps are detectable.
  • contentHash — SHA-256 of the canonical artefact (PDF, JSON, whatever).
  • previousHash — links this entry to its predecessor.
  • signature — ed25519 over sequence || previousHash || contentHash || signedAt || eventType using your firm's key.
  • metadata — arbitrary JSON; round-tripped into certificates.

Why writes are routed through Bedrock and not direct to your DB

The append operation must be performed by something that holds the firm's signing key. That key never leaves the API Lambda's execution context — it's loaded from KMS at cold start, used in-memory, and discarded. If we let firms write to the chain directly, the integrity property would depend on firms keeping their key safe; with Bedrock in the middle, it depends only on AWS KMS access controls.

Verification

Anyone holding your firm's public key can verify any entry — and therefore the entire chain back to genesis — without trusting Bedrock or the firm. The public key is published at:

bash
curl https://api.bedrockcompliance.co.uk/.well-known/signing-key

The verification algorithm is published as an open-source package — see the Notary for the details, or jump straight to Chain integrity for the algorithm walkthrough.

What gets recorded

The full set of ledger event types is defined in the Ledger events reference. The headline ones are:

  • DOCUMENT_SUBMITTED
  • REVIEW_STARTED / REVIEW_COMPLETED
  • DOCUMENT_APPROVED / DOCUMENT_MODIFIED / DOCUMENT_REJECTED
  • IMPACT_ASSESSMENT_APPROVED
  • SLA_BREACHED
  • INCIDENT_LOGGED / INCIDENT_RESOLVED
  • FIRM_SETTINGS_UPDATED

See also