TrustLedger

TrustLedger is a cryptographic audit trail for AI decisions in regulated industries. When an AI model makes a consequential decision — approving a loan, flagging a transaction, scoring an insurance claim — TrustLedger captures it, hashes it deterministically, signs it with AWS KMS, has a second LLM assess its risk, and anchors the proof immutably on Ethereum Sepolia. Every decision becomes independently verifiable after the fact.

The problem: Regulated industries deploying AI have no standardized way to prove what an AI decided, when, and why. When auditors or regulators ask "show me the decision trail," teams scramble through logs. TrustLedger makes the audit trail cryptographically tamper-proof and blockchain-verifiable from day one.

Architecture
User/AI System → POST /decisions (Express API)
↓
Chainlink CRE Workflow
├── Hash payload (RFC 8785 canonical JSON)
├── Sign with AWS KMS (ECDSA_SHA_256) ──┐
└── LLM risk assess (Claude Haiku) ──→ Merge
↓
Anchor to Ethereum Sepolia
(AuditAnchor.sol via EVMClient.writeReport)
↓
Callback → /webhooks/cre (txHash)
↓
Next.js Dashboard
+ Public Proof Page

Tech Stack

1. Frontend - Tech: Next.js 14 (App Router), shadcn/ui, Tailwind, Zustand
2. Backend API - Tech: Express, Drizzle ORM, PostgreSQL
3. Shared types - Tech: TypeScript package with hashDecision utility
4. Smart contract - Tech: Solidity 0.8.20+, Foundry
5. CRE Workflow - Tech: @chainlink/cre-sdk

1. An AI model submits a decision (type, outcome, confidence, top contributing features) to the TrustLedger API.

2. The API computes a deterministic SHA-256 hash using RFC 8785 canonical JSON (sorted keys, no whitespace ambiguity).

3. A Chainlink CRE workflow is triggered via HTTP. Inside the workflow:

   • The hash is signed using AWS KMS (ECDSA_SHA_256, MessageType: RAW).
   • Claude Haiku independently assesses the decision's risk level (LOW/MEDIUM/HIGH) with a written summary.
   • The CRE DON anchors the data directly on-chain via EVMClient.writeReport to AuditAnchor.sol.
   • The workflow notifies the backend with the txHash via callback.

4. The backend updates the decision status to ANCHORED and records the txHash — the on-chain write is already done by the DON.

5. Three-layer verification runs on demand: recompute the hash, verify the KMS signature, and confirm the on-chain transaction via Etherscan.

Status machine: PENDING → SIGNED → ANCHORED → VERIFIED (never backwards, any state can transition to FAILED).