AI-assisted work can acquire citations faster than it acquires evidence. A model proposes a sentence, a search retrieves something adjacent, and a polished document makes the chain look complete. The weak point is often not the absence of links. It is the absence of a visible mapping between each decision-relevant claim and the source that actually supports it.

An evidence ledger is that mapping. It is a compact table or list maintained beside the work. Each row names one material claim, its best source, the exact locator, the kind of support, remaining uncertainty and the event that should force a recheck. It does not make the AI trustworthy. It makes the human verification state inspectable.

Hands sorting claim cards beside source documents, page tabs, a date stamp and a review checklist on a dark desk
The ledger connects claims to inspectable evidence and a review state. The papers contain no real citations or private data. This is an original AI-assisted editorial photograph.

Use a ledger when a wrong claim changes a decision

Do not build a research bureaucracy around every sentence. Use the method where an unsupported claim could change money, safety, rights, reputation, a technical design or a public conclusion. A short internal draft may need five ledger rows. A policy, buying guide, analysis or automated decision may need dozens.

The unit is not “one source.” The unit is one claim that matters. A single source may support several rows. One row may require multiple independent sources. This is why a bibliography alone is insufficient: it records presence, not the relationship between evidence and conclusion.

Create nine fields

  1. Claim ID: a stable short label such as C-07.
  2. Exact claim: a sentence narrow enough to challenge.
  3. Decision role: why this claim matters—background, comparison, threshold, safety constraint or final recommendation.
  4. Source: the strongest available document, dataset, manual or direct record.
  5. Locator: page, section, table, figure, timestamp or quoted phrase that allows another person to find the support.
  6. Support type: direct, derived, contextual, conflicting or absent.
  7. Verification state: proposed, located, checked, corroborated, disputed or retired.
  8. Uncertainty and limits: population, date, assumptions, missing cases and alternative explanations.
  9. Owner and refresh trigger: who rechecks it, and when.

Keep the language controlled. “Checked” should mean someone opened the source and compared the claim with the cited passage. “Corroborated” should mean an independent source supports the same material point. A URL generated by a model is only proposed until it resolves to the right document.

Step 1: extract claims before polishing

Take the current draft and highlight statements that could be false, dated or overstated. Split compound sentences. “Product A is faster, safer and supported for five years” is three claims, probably carried by different evidence.

Ignore style claims such as “the interface feels busy” unless the judgment affects the recommendation. Capture factual descriptions, comparisons, causal claims, numerical thresholds, legal or policy statements, compatibility requirements and claims about what a source concludes.

If the draft came from a model, do not ask the same model which claims require verification and accept the result as complete. Use it for candidate extraction if helpful, then perform a human pass guided by consequence.

Step 2: make the claim falsifiable

“This approach improves performance” cannot be verified without defining approach, outcome, comparison and context. Rewrite it: “In the cited trial, participants assigned to X completed Y faster than the control group during the six-week study.” The narrower sentence may sound less impressive. It is more useful because the source can actually carry it.

Separate observed results from explanation. A study may report an association; your draft may add a causal mechanism. Give those separate rows. An AI Explanation Is Not the Mechanism shows why a plausible narrative does not inherit the evidence attached to the outcome.

Step 3: climb the source ladder

Prefer the source closest to the claim. For a product capability, use the current manual or specification page. For a law or rule, use the responsible government body. For a study result, use the paper and its supplementary material. For a quote, use the original speech, transcript or recording. A reputable secondary source may supply context, but it should not replace an available primary record for the key fact.

Record why a weaker source remains. Perhaps the primary document is unavailable, paywalled or ambiguous. The ledger should expose that boundary rather than converting availability into authority.

Step 4: save a locator, not just a link

Links rot, documents change and long pages make vague citations difficult to audit. Record the document title, publisher, publication or revision date, stable URL, access date and a precise locator. For web pages without stable pagination, save the section heading and a short non-copyrighted identifying phrase.

When the stakes justify it and policy permits, preserve a snapshot or document hash in an approved repository. Do not archive private, licensed or sensitive material into a system that should not contain it. Provenance helps only when the storage practice is legitimate.

Step 5: grade the relationship

Use support labels that describe the relationship rather than the prestige of the source:

  • Direct: the source explicitly reports the claimed fact for the relevant context.
  • Derived: the claim is calculated from documented inputs; save the method.
  • Contextual: the source helps frame the claim but does not establish it.
  • Conflicting: credible sources disagree or apply different definitions.
  • Absent: no adequate support has been found.

A primary source can still be weak for your claim. A manufacturer manual directly supports what the manufacturer specifies; it does not independently prove long-term reliability. A research paper directly supports what its study found; it may not support transfer to another population.

Step 6: test entailment

Open the source and ask a strict question: if a skeptical reader saw only this passage, would they agree that the source supports the sentence? Check qualifiers, negative results, population, time period and comparison group. Then read enough surrounding context to avoid quote mining.

Use the citation-verification protocol for existence, identity and entailment. The ledger adds workflow state and responsibility. It records not just that the citation passed today, but who checked it and what could make it stale.

Step 7: expose disagreement and uncertainty

Do not resolve disagreement by keeping only the source that fits the draft. Add the conflicting source, name the difference and decide whether the text should narrow, present both views or defer judgment. Mark inference as inference.

For numerical claims, capture uncertainty, denominators and unit definitions. For model evaluations, record the task, dataset, version and date. A Dataset Is Not the World is the reminder that even a correctly cited number may represent the wrong population or period.

Step 8: assign refresh triggers

A yearly review date is better than nothing, but event-based triggers are stronger. Recheck when a vendor changes a model, a regulator revises guidance, a dataset receives a new release, a linked page moves, the decision crosses a new threshold or the publication is repurposed for a different audience.

Use four states at publication: current, current-with-limit, disputed and removed. Do not leave stale claims appearing verified because nobody owns the review.

Step 9: connect evidence to the decision record

The ledger says what supports the claims. A decision record says what was chosen, by whom, under which constraints and with what rollback path. Link them. Evidence without a decision can become unused research; a decision without inspectable evidence becomes a story hindsight can rewrite.

At final review, sample the highest-consequence rows rather than rewarding the sheer number of citations. A document with forty decorative references and one unsupported safety constraint is not well sourced.

A compact template

C-01 · Claim: [exact sentence]. Role: [decision affected]. Source and locator: [document, date, section/page]. Support: [direct/derived/contextual/conflicting/absent]. Status: [proposed/checked/corroborated]. Limits: [scope and uncertainty]. Owner: [name or role]. Refresh: [date or event].

A spreadsheet works. A plain-text table works. A database can help at scale. Choose the simplest format that preserves stable IDs, history and access control. Tool sophistication cannot compensate for vague claims.

What to avoid

  • Do not paste model-generated citations into the checked column.
  • Do not use a search snippet as support; open the source.
  • Do not treat a citation count as an evidence score.
  • Do not hide unsupported claims in summary or recommendation sections.
  • Do not store sensitive source material in an unauthorized ledger.
  • Do not let “human reviewed” remain an unnamed, unauditable state.

The bottom line

An evidence ledger is not a guarantee of truth. It is a control against invisible source failure. It makes the route from claim to document, judgment and refresh visible enough for another person to inspect.

Use AI to help locate possibilities, reorganize notes or challenge wording. Keep responsibility for verification attached to a person, an exact claim and a source that was actually opened.

Framework and provenance notes

END OF FIELD GUIDE 046

Keep the question. Test the model.

Choose the narrowest claim the evidence can carry, then leave room for revision.