AegisAI Feature
A hash-chained record of every decision
AegisAI, Trust Ledger
Example figures- CHAIN STATE
- intact
- verify_chain
- SEQ
- per-org
- monotonic
- HASH
- SHA-256
- prev, then entry
- Genesis entry (seq 1)
- genesis hash
- Policy decision recorded
- entry_hash chained
- Evidence item linked
- content_hash
- GET /internal/evidence/ledger/verify
- intact
- Any altered entry
- breaks the chain
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 to 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.
Questions people ask
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.
Keep reading
Guides
Calculators
One finance briefing a week
New guides, checklists and benchmarks, by email. Unsubscribe from any issue.
Make every decision provable
Record tamper-evident, reproducible evidence for every governed action.