Truth Ledger: Toward Auditable Knowledge Systems

Summary

A recurring problem in AI systems is that conversation, memory, and knowledge are often treated as if they belong to the same category. They do not. A system can remember something without knowing it. A model can produce a plausible sentence without preserving the evidence that would make the sentence auditable. A user can observe something without that observation becoming durable knowledge. This note introduces Truth Ledger as a public-facing research direction for iLiC: evidence-governed knowledge that remains inspectable, challengeable, and accountable over time.

Core Distinction

The design principle is simple: memory is not knowledge. Memory is retained context. Knowledge is a validated observation admitted through governance. That distinction matters because modern AI systems are very good at producing fluent claims, but fluency is not provenance. A useful trust layer should preserve the difference between what was said, what was observed, what evidence supports it, and what has been accepted for later use.

Working Definitions

iLiC uses several terms more carefully than ordinary conversation usually does:

• Observation: something captured from a source, page, document, interface, or event.
• Claim: a statement extracted from an observation that may require support or challenge.
• Evidence: source material that supports, contradicts, or contextualizes a claim.
• Memory: retained context that may help continuity but is not automatically knowledge.
• Knowledge: a validated observation admitted through governance with provenance attached.

Why Auditability Matters

Most simple AI interaction flows can be described as input, prediction, and output. That is useful, but it is incomplete for systems that are expected to persist, remember, advise, or act across time. A more accountable flow adds evidence and governance before reuse:

Input → Prediction → Evidence → Governance → Output.

In this framing, the model is not asked to become the authority. The model may help identify claims, summarize sources, or propose interpretations, but the knowledge layer must retain source context, validation status, and the reason a claim was accepted, rejected, or left unresolved.

Status Instead of Certainty

Truth Ledger should avoid pretending that every claim can be reduced to a permanent binary label. Publicly, the more useful vocabulary is status-based:

• Unverified: captured but not yet supported by validation.
• Supported: evidence exists, but further challenge may still be appropriate.
• Validated: admitted through the current validation and governance process.
• Disputed: meaningful contradiction or uncertainty has been found.
• Stale: old enough or unstable enough that revalidation is required.

This is intentionally different from assigning permanent certainty labels. The point is to keep evidence, uncertainty, and governance visible.

Wizard's Role

Wizard is the user-facing evidence collector in this architecture. Its role is to act visibly on behalf of the user, not to scrape secretly or observe outside user-approved interactions. In early versions, Wizard should collect evidence through ordinary front-end interfaces: user-approved browser navigation, visible page capture, screenshots, timestamps, source URLs, and local reports. If login is required, the user authenticates manually. Wizard should make what it is reading and saving understandable before that evidence enters a ledger.

Relationship to iLiC

Truth Ledger is not a separate project from iLiC. It is a continuation of the same governed-cognition arc: persistent memory, explicit governance, evidence validation, and auditability. iLiC provides the orchestration layer. EILOG provides governance over admission and authority. Wizard provides visible collection and user interaction. The ledger preserves the claim, evidence, validation history, challenge history, confidence state, and governance decision.

Challengeable Knowledge

A healthy knowledge system should be able to challenge itself. A claim should carry enough evidence for later review. A validator should be able to explain why a claim is supported. A second validator should be able to challenge that result. New evidence should be able to lower confidence, mark a claim stale, or move a claim into dispute. In this sense, the ledger is not a vault of final answers. It is an inspectable history of what the system currently has reason to rely on.

References

• Prior iLiC Notes on governed cognition, memory-native systems, visible mutation, and governed operator layers.
• Public systems literature on provenance, audit trails, evidence retention, and knowledge governance.
• AI safety and reliability discussions about traceability, uncertainty, and model outputs as non-authoritative proposals.