Features

Certificates

Externally verifiable proof of every decision — the artefact you hand to the customer and the regulator.

See the conceptual overview at Concepts → Certificates. This page covers the feature angle: what to do with the certificates Bedrock issues, which API surfaces them, and which FCA rule they satisfy.

What to do with a certificate

Email the PDF to the customer alongside the advice
Store the verify URL on the customer record
Embed the certificate ID on any internal systems linked to that customer outcome
Include the certificate ID on any board pack referencing the case

API surfaces

GET /v1/ledger/certificates — list every certificate the firm has issued (firm-authenticated)
GET /v1/ledger/certificates/{id} — fetch a single certificate envelope by id
GET /v1/ledger/records/{id}/certificate — presigned URL for the certificate PDF tied to a ledger record
POST /v1/ledger/records/{id}/certificate — issue a certificate on demand for any ledger record outside the auto-issue allowlist (idempotent)
GET /v1/verify/{certificateId} — public verification endpoint (no auth)

Polymorphic by event type

A certificate is a thin envelope around a ledger record. Any compliance-relevant event type can carry one — review outcomes (DOCUMENT_APPROVED, DOCUMENT_MODIFIED, DOCUMENT_REJECTED), Consumer Duty impact assessments (IMPACT_ASSESSMENT_APPROVED), and any other event types. Event-specific content (outcome, reviewer name, use case, etc.) lives in the certificate's metadata blob, projected from the ledger record at issue time.

Auto-issue is allowlist-driven and managed by Bedrock staff. For event types outside the allowlist, firms can request a certificate on demand via POST /v1/ledger/records/{id}/certificate.

Evidence produced

The certificate itself — a signed, addressable artefact tied 1:1 to its ledger record
The underlying ledger event (e.g. DOCUMENT_APPROVED) — the cryptographic anchor

FCA mapping