The Claim Ledger

What it is

The Claim Ledger is a structured record created for every AI inference. It captures:

1. Query ID: Unique identifier for this inference.
2. Requester profile: User identity, role, REBAC clearances.
3. Compiled query plan: How the prompt compiler interpreted the request.
4. Evidence scope: Which documents were eligible for retrieval.
5. Retrieved documents: What was actually fetched (with evidence metadata).
6. Evidence coverage: How much of the eligible evidence was examined (percentage).
7. Gate outcomes: Which policy gates fired and their decisions.
8. Output state: AUTHORIZED, PARTIAL, REQUIRES_SPEC, or BLOCKED.
9. Model and prompt versions: Full reproducibility.
10. Claim mappings: Each claim in the output mapped to its source evidence.
11. Timestamps: Immutable proof of when this happened.
12. Cryptographic signatures: HMAC-SHA-256 on each field for tamper detection.

Why it matters

Without a Claim Ledger, an AI audit is a guessing game. You can log what the model said, but not what it was allowed to know. You can’t prove whether a wrong answer was a hallucination or authorized data access. You can’t show regulators that policy was enforced.

The Claim Ledger closes that gap. It’s the evidence file. When someone asks “How did this AI reach this conclusion?” you can replay the ledger and show exactly what it knew, what it could access, and what policy gates it passed.

Data model

Key schema fields (JSON):

• id: UUID of this ledger entry
• query_id: Request identifier
• created_at: ISO 8601 timestamp
• requester: { user_id, email, clearances: [list] }
• evidence_scope: { total_eligible, retrieved, coverage_pct }
• gates: [{ name, rule, outcome, timestamp }]
• output_state: enum (AUTHORIZED | PARTIAL | REQUIRES_SPEC | BLOCKED)
• claims: [{ claim_text, source_id, evidence_text, matched }]
• model: { name, version, adapter_version }
• signature: HMAC-SHA-256 of all fields

How Kenshiki Labs implements this

1. Integration point: After model inference, before output emission.
2. Recording: Every retrieval, gate, and output decision is logged.
3. Signature: Each entry is signed with a service key (key rotation every 90 days).
4. Export: JSON/CSV export for compliance audits.
5. Replay: Deterministic replay of any inference decision.
6. Long-term storage: Encrypted at-rest in compliance-audited storage.

Use cases

1. Compliance audit: Prove to regulators that policy was enforced.
2. Incident investigation: Understand exactly what an AI did and why.
3. Model evaluation: Measure coverage, gate performance, and output state distributions.
4. User transparency: Show users what evidence backed their answer.
5. Forensics: Detect unauthorized access or policy violations.

The Claim Ledger is the difference between “trusting” an AI system and “proving” an AI system works the way you think it does.