Concepts

Certificates

The signed, externally verifiable proof that a piece of advice has been reviewed and committed to the ledger.

A certificate is a thin envelope around a ledger record. It is what Bedrock issues when a compliance-relevant event lands on your firm's chain — most commonly the outcome of a review (DOCUMENT_APPROVED, DOCUMENT_MODIFIED,DOCUMENT_REJECTED) or the approval of a Consumer Duty impact assessment (IMPACT_ASSESSMENT_APPROVED). It is the artefact your firm hands to the customer (and, if it ever comes to it, to the regulator). It is cryptographically anchored to the immutable ledger, and can be checked by anyone — no Bedrock involvement required, and no need to trust your firm.

What's in a certificate

The certificate row itself is a thin envelope; the cryptographic proof lives on the linked ledger record (where it cannot be tampered with), and event-specific content lives in a metadata blob assembled at issue time:

  • Envelope — id, firm name, FRN, issue timestamp, public verify URL, PDF URL.
  • Ledger reference — ledgerRecordId linking 1:1 to the underlying record on the chain.
  • Cryptographic proof — document hash, previous hash, record hash, chain hash, ECDSA P-256 signature, public key. These live on the linked record (joined at verify time).
  • Event-specific content — projected from the ledger record by an event-typed assembler. For a review certificate this is reviewer name, FCA reference, document reference, document type, outcome. For an impact-assessment certificate it is the use case, model provider/version, signer.

Because the certificate row is just an envelope, the same machinery issues certificates for every event type on the auto-issue allowlist — review outcomes, impact-assessment approvals, and any future event type Bedrock staff add.

Two formats, same proof

Each certificate is available as JSON and as a customer-friendly PDF. The PDF is a human-readable rendering of the metadata; verification is against the chain hash and signature on the linked ledger record.

bash
# List every certificate the firm has issued (JSON)
curl https://api.bedrockcompliance.co.uk/v1/ledger/certificates \
  -H "X-Bedrock-Key: bk_live_..."

# Fetch a single certificate envelope by id
curl https://api.bedrockcompliance.co.uk/v1/ledger/certificates/cert_01HX5... \
  -H "X-Bedrock-Key: bk_live_..."

# Get a presigned URL for the certificate PDF tied to a specific ledger record
curl https://api.bedrockcompliance.co.uk/v1/ledger/records/rec_01HW2.../certificate \
  -H "X-Bedrock-Key: bk_live_..."

# Issue a certificate on demand for a record outside the auto-issue allowlist
curl -X POST https://api.bedrockcompliance.co.uk/v1/ledger/records/rec_01HW2.../certificate \
  -H "X-Bedrock-Key: bk_live_..."

# Public verification (no auth) — anyone with the certificate id can call this
curl https://api.bedrockcompliance.co.uk/v1/verify/cert_01HX5...

Public verification

Anyone — your customer, a regulator, a journalist — can verify a certificate without ever needing your cooperation. The verify page at verify.bedrockcompliance.co.uk accepts an uploaded certificate (JSON or PDF), fetches the firm's public key from /.well-known/signing-key, validates the signature, walks the ledger chain forward to confirm the referenced entry hasn't been retroactively contradicted, and reports the result.

What this enables

  • Customers can check that the advice they received is genuine and hasn't been altered.
  • Regulators can spot-check any decision without asking the firm to produce records.
  • Future you can re-verify historic advice years later, even if the firm has been sold or the original system replaced.

See also