# Build an evidence ledger for AI-generated documentation

Canonical: https://githtml.com/guides/ai-documentation-evidence-ledger
Published: 2026-09-26
Publisher: WaveTech LLC / gitHtml

An evidence ledger connects each important generated claim to the source that supports it. Record the claim, source location, revision, evidence type, and review outcome. Mark unsupported statements for correction or removal, and distinguish a source that merely mentions a topic from one that actually establishes the claimed behavior.

## Choose claims that deserve individual review

Not every connecting sentence needs its own row, but behavioral guarantees, limits, permissions, and data handling do. An illustrative claim that failed imports are retried automatically needs evidence of the retry path and its conditions. A function named retryImport is not enough if the documentation describes an unconditional guarantee. NIST's generative AI profile identifies confidently incorrect output as a risk; the ledger is an editorial technique for making such mistakes visible. Keep the review focused on the statements that would change a reader's decisions.

## Create a compact ledger entry

For each claim, write the exact proposition, a stable source link, the relevant symbol or configuration, what the evidence shows, what it does not show, and the reviewer decision. An illustrative entry might conclude that retries exist for transient network failures but not for invalid input. The corrected documentation should preserve that condition. GitHub's permanent file links help keep evidence tied to a particular revision instead of a moving branch. Do not manufacture a source location because the model's suggested line number looks plausible.

1. Claim: express one behavior that can be checked independently.
2. Evidence: identify the revision and the condition demonstrated by the source.
3. Decision: accept, qualify, remove, or ask the responsible maintainer.

## Use the ledger to revise the document

Review the highest-consequence claims first, then propagate corrections into summaries, diagrams, captions, and examples. A qualified sentence in the body does not fix an overconfident title. Retain unresolved rows when publishing is blocked rather than silently dropping inconvenient questions. Keep the ledger accessible to maintainers, with sensitive source material restricted appropriately. If you export the approved guide to HTML, include a short scope and revision note. The ledger establishes what was reviewed at that time; it does not certify future revisions or substitute for testing.

## Sources and further reading

- [NIST AI 600-1: Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf)
- [GitHub Docs: Getting permanent links to files](https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files)

## Related guides

- [Write a read-only AI documentation prompt with explicit boundaries](https://githtml.com/guides/read-only-ai-documentation-prompt)
- [Verify AI-generated API documentation against the actual contract](https://githtml.com/guides/verify-ai-generated-api-documentation)
- [Review AI-generated architecture diagrams for invented relationships](https://githtml.com/guides/review-ai-generated-architecture-diagrams)
- [Verify AI-generated documentation code examples before publication](https://githtml.com/guides/verify-ai-generated-code-examples)

Editorial approach: https://githtml.com/guides/about