What is a Trust Ledger for AI decisions?
A trust ledger is an append-only, hash-chained record of every material answer an AI system gives, capturing the verdict, confidence, sources, and reasoning at the moment it was given, so the history is auditable and tamper-evident.
The difference between one answer and a history
A per-answer trust envelope proves a single response. A trust ledger makes the whole history auditable and self-calibrating. It answers a harder question: why did the AI say this, and was it borne out?
Every entry captures the answer's trust envelope at the moment it was given and chains it to the previous entry by hash. Altering any past entry breaks the chain, which is what makes the record tamper-evident.
Why it compounds
As outcomes are reconciled against what actually happened (borne_out, contradicted, or unclear), the ledger becomes a calibration dataset. It accumulates a track record per verdict type and per name that no data feed or foundation model can buy, because it is a record of this system's own decisions and their results.
Calibration is only meaningful once outcomes are recorded, so the value grows as the loop closes over time.
How LyraMind implements it
Each entry hashes its material fields plus the previous hash with SHA-256, chained from a genesis hash. The actor who asked is stored as a one-way hash, keeping signal without raw identity. A verify walk recomputes every hash and confirms the links, returning intact or the sequence where the chain broke.
The current build is an in-memory MVP that starts accruing from launch, with a shared adapter that mirrors to Supabase when configured. Recording is best-effort by design: it swallows all errors so a ledger write can never break an answer. Readiness and execution decisions record automatically and return a ledger_id for later reconciliation.
Related concepts
The trust ledger persists the trust envelope that every answer carries. It powers Institution Memory (a name's track record), the AI Readiness benchmark and history, and the auditable record behind every execution-readiness decision.
- Append-only chain: each entry links to the prior one by SHA-256 hash
- Captures verdict, confidence, data-mode, sources, and reasoning at decision time
- Tamper-evident: a verify walk recomputes the chain and flags any break
- The asker is stored as a one-way hash, keeping signal without raw identity
- Reconciling outcomes (borne_out / contradicted / unclear) turns it into a calibration dataset
- In-memory MVP today; mirrors to Supabase when configured. Writes never break an answer
Questions
How is a trust ledger tamper-evident?
Each entry hashes its fields together with the previous entry's hash. Changing any past entry changes its hash and breaks every link after it, which a verify walk detects.
Does the ledger store who asked?
Only as a one-way SHA-256 hash. It keeps the signal that a principal acted without retaining raw identity.
Is the ledger persistent?
The current build is an in-memory MVP that resets on restart. It mirrors to Supabase when SUPABASE_URL and a service key are configured.