Build an AI Knowledge System With Provenance

An AI knowledge system becomes less trustworthy when it remembers the sentence but loses where the sentence came from, when it was true, who may see it, and whether it was confirmed or merely proposed.

Provenance is the structure that preserves those connections. It allows a later reader—or a retrieval system—to answer not only “what does the record say?” but also “why should I rely on it here?”

Start with claims, not documents

Documents remain important evidence, but they are often too large and ambiguous to serve as the only unit of knowledge. Extract material claims into records that can be reviewed independently while retaining a link back to the source passage.

A useful claim is narrow enough to confirm or dispute. “The project is healthy” is not a durable claim. “The staging release passed the approved acceptance checks on a recorded date” can be evaluated if the checks and source record are retained.

Use a complete evidence record

For every material claim, store:

• Fact or claim: the exact statement.
• Source: document, URL, dataset, observation, or decision record.
• Source date: when the evidence was created or observed.
• Confidence: how strongly the evidence supports the claim.
• Context: where the claim applies and where it may not.
• Privacy: who may access or publish it.
• Status: confirmed, inferred, unknown, or conflict.
• Authority: who may decide or approve its use.

These fields prevent confidence from being confused with status. A record can have high confidence that two sources conflict while the underlying answer remains unresolved.

Keep source date and review date separate

The date a source was created is not the date someone last checked that it still applies. Store both. Add an expiry or review condition when the subject changes frequently.

Do not silently overwrite old evidence. If a source is superseded, preserve the relationship so later readers can understand why the conclusion changed.

Treat privacy as retrieval logic

Privacy is not only a label shown after retrieval. It should control which records enter an index, which tools can query them, which outputs may leave the system, and which people can approve publication.

Use explicit allow-lists for sensitive collections. Minimize copied content. Do not place credentials, session data, private client information, or unnecessary personal data into a general knowledge index.

Preserve conflicts instead of averaging them away

When credible sources disagree, create a conflict record that links the competing claims. State what evidence would resolve the conflict and who has authority to decide.

Summarization can hide disagreement by producing a smooth sentence. Retrieval should surface the conflict when it is relevant, not choose a winner without authority.

Separate corrections from deletion

A correction should add a new state and connect it to the record it changes. Deletion is appropriate for data that should not have been retained, but it is a poor substitute for an audit trail when the history itself is legitimate and useful.

Record who approved the correction, when it took effect, and which downstream views or indexes need refresh.

Design retrieval around the question

Not every task needs semantic retrieval. Exact identifiers, dates, statuses, and authorities may work better with structured filters or search. Long context may be sufficient for a small, stable evidence pack. RAG may help when a larger corpus must be retrieved repeatedly.

Choose the smallest approach that preserves the required evidence. The decision framework in RAG vs Long Context vs Search explains the trade-offs.

Make citations inspectable

A citation should point to the evidence a human can inspect, ideally to the relevant passage or structured record. A list of filenames at the end of an answer is weaker than a link between each important claim and its source.

If a source cannot be disclosed, say that the claim relies on restricted evidence and limit the output accordingly. Do not fabricate a public citation.

Keep human approval at the publication boundary

The system may help find, compare, or draft from evidence. A responsible human should approve material claims before they become public or trigger consequential action.

Approval should be attached to the exact version of the claim and output. A general approval of a source collection does not approve every future summary generated from it.

Create export views, not duplicate truths

Different audiences may need a public summary, an internal working view, and a technical audit view. Generate those views from the same governed records when possible. Do not maintain independent copies that can drift without visible reconciliation.

Minimum Source & Claim Ledger

A practical ledger can begin with these columns:

claim_id, claim, source_id, source_date, observed_or_reviewed_date, confidence, context, privacy, status, authority, supersedes, review_condition

Before adding automation, test whether a reviewer can trace a material output back to a source, see conflicts, identify privacy restrictions, and determine who can approve a change.

The goal is not to collect everything. It is to preserve enough evidence and authority for the knowledge to remain useful after the original context fades.

Related reading: Workflows, Technology Foundations, and AI Use & Corrections.