A Hash-Chained Record of Every Decision
Each verdict becomes a ledger entry chained to the one before it with SHA-256. verify_chain recomputes the chain and reports whether it is intact - tamper-evident, not a blockchain.
Illustrative product view
How the chain is built
The Trust Ledger keeps a per-org monotonic sequence. Each entry’s hash is computed as compute_entry_hash over prev_hash, org, seq, kind, evidence_id, delta, narrative, and content_hash - so entry N depends on entry N−1. Sequence 1 uses a fixed genesis hash. Because each link binds to the one before it, altering any entry changes its hash and breaks every subsequent link.
Entry hash
entry_hash = SHA-256(prev_hash | org | seq | kind | evidence_id | delta | narrative | content_hash)
Every field that matters to the decision is folded into the hash, and prev_hash chains it to the previous entry. Recomputing the chain reproduces every hash if nothing was tampered with.
Verifying integrity
verify_chain(db, org_id) walks the org’s entries in order, recomputes each hash from the stored fields, and reports whether the chain is intact. The result is surfaced at GET /api/trust-ledger/ and GET /internal/evidence/ledger/verify, so an auditor can independently confirm that the record has not been altered since it was written.
What gets recorded
| Field | Purpose |
|---|---|
| org + seq | Per-tenant monotonic ordering |
| prev_hash | Binds the entry to the previous one |
| kind | What the entry represents (decision, evidence, mitigation) |
| evidence_id + content_hash | Links to the underlying evidence item |
| delta + narrative | The change and a human-readable explanation |
| entry_hash | The reproducible SHA-256 over all of the above |
How it feeds compliance evidence
When the govern→evidence loop is enabled, ingesting a governed action writes an EvidenceItem plus a hash-chained TrustLedgerEntry with control links. So the same chained events become the evidence that a control operated, and the ledger is the spine that makes that evidence tamper-evident.
Frequently asked questions
Is the Trust Ledger a blockchain?
No. It is a hash-chained, tamper-evident local ledger - each entry’s SHA-256 hash includes the previous entry’s hash - but there is no distributed consensus, token, or network. You get detectable tampering without the cost and complexity of a blockchain, which is what an auditor actually needs.
How do you verify the ledger has not been tampered with?
verify_chain recomputes each entry’s hash from its stored fields and confirms the chain links are intact, reporting any break. It is exposed at GET /api/trust-ledger/ and GET /internal/evidence/ledger/verify, so integrity can be checked independently at any time.
What is written to the ledger?
Each governed decision, along with linked evidence and simulated mitigations, is written as an entry carrying org, seq, prev_hash, kind, evidence_id, delta, narrative, and content_hash. The entry_hash over those fields chains it to the prior entry.
Why hash without a timestamp?
Hashing the decision content rather than the wall-clock time makes each entry reproducible: an auditor can replay the same action, recompute the hash, and confirm it matches - proving the record was not altered after the fact.
Stay in the loop
One practical finance briefing a week - new guides, checklists, and benchmarks.
Make every decision provable
Record tamper-evident, reproducible evidence for every governed action.
Talk to us