Create one row per useful source. Give it a stable source ID, URL, publisher, date, source type, freshness status, the exact claim it supports, important qualifiers, and a confidence or evidence-quality field. Then make every factual claim in the draft point back to one or more source IDs. The ledger is not a bibliography; it is an operational map between evidence and claims.
Why a normal bookmark list is not enough
A bookmark tells you where you found something. A Source Ledger tells you why that source matters and what it is allowed to prove. That distinction becomes important when AI is involved because a model can blend details from several pages into a sentence that no single page actually supports.
The ledger reduces that ambiguity. Instead of feeding a model ten URLs and asking it to "use the sources," you give it structured notes that say which facts are supported, which are still uncertain, and which qualifiers must stay attached.
The minimum Source Ledger schema
| Field | Why it exists | Example |
|---|---|---|
| source_id | Stable reference used by the draft and claim table | S001 |
| url | Direct location of the evidence | Official pricing page |
| publisher | Who owns or issued the information | Vendor / regulator / research group |
| source_type | Primary, official, secondary, study, commentary | Primary |
| published_or_updated | Helps detect stale information | 2026-10-31 |
| retrieved_at | Records when you actually checked it | 2026-11-10 |
| supports | The exact claim or narrow fact the source supports | "Plan X includes feature Y" |
| qualifiers | Conditions that must remain attached | "Annual plan only" |
| freshness | Current, stale, unknown, recheck before publish | Recheck before publish |
| confidence | Your confidence in the fit between source and claim | High |
| notes | Conflicts, missing context, or follow-up work | Secondary source disagrees |
Start with source authority, then check source fit
A primary source is often preferable for claims about a product, policy, law, official statistic, or research result. But authority alone is not enough. The source also has to support the exact sentence you want to publish.
For example, a vendor pricing page may prove the current monthly price but not prove that the product is "the cheapest." A research paper may show an effect in one population but not justify a universal claim. A regulator may describe a rule but not support your interpretation of how it applies to a specific business.
Use stable source IDs everywhere
Do not rely on row numbers that can change when a spreadsheet is sorted. Assign IDs such as S001, S002, and S003. Use those IDs in the article brief, internal draft annotations, claim table, and review notes.
This makes it possible to say, "C014 is supported by S003 and S008," without copying full URLs through every stage of the workflow.
Separate the Source Ledger from the Claim Check table
The Source Ledger describes evidence. The Claim Check table describes what the draft says. Keeping them separate creates a many-to-many relationship: one source can support several claims, and one claim can require several sources.
| claim_id | claim_text | source_ids | status | action |
|---|---|---|---|---|
| C001 | Current product price is $X | S001 | SUPPORTED | Keep, recheck before publish |
| C002 | Product is the cheapest option | S001 | UNSUPPORTED | Research competitors or remove |
| C003 | Feature Y is available on paid plans | S002,S004 | PARTIAL | Add plan qualifier |
Track freshness as a first-class field
Some evidence ages faster than others. A historical date may remain stable for years. A SaaS price, feature limit, refund rule, or policy can change overnight. Treat those categories differently.
A practical freshness field can use four values:
- CURRENT: recently checked and unlikely to change before publication.
- RECHECK_BEFORE_PUBLISH: volatile information such as prices or plan limits.
- STALE: source is old enough that the claim needs a newer source.
- UNKNOWN: no visible date or update history is available.
Record contradictions instead of hiding them
When two credible sources disagree, do not force the model to pick one silently. Add a conflict note. Decide whether one source is more authoritative, whether the sources refer to different dates or scopes, or whether the article should state the uncertainty explicitly.
A useful conflict record includes:
Capture quotes carefully
If you use a direct quotation, store the exact quoted text, source ID, page or section location when available, and a short surrounding-context note. This helps prevent a quote from being technically accurate but misleading outside its original context.
What to give the AI model
Do not dump the entire web page into every prompt. Give the model only the source notes relevant to the section being written. A structured evidence packet might look like:
How the ledger changes the writing workflow
- Research before prose.
Collect evidence and identify gaps before the draft has momentum. - Draft from evidence packets.
Generate each section from the relevant source notes rather than from general model memory. - Extract claims after drafting.
Turn the article into a list of checkable factual statements. - Match claims back to source IDs.
Mark each claim Supported, Partial, or Unsupported. - Repair only weak areas.
Do not rewrite good sections just because one sentence failed verification. - Recheck volatile facts near publication.
Refresh prices, policies, dates, and plan limits immediately before approval.
Source quality is not a single score
A high-quality source for one claim may be poor for another. Think in dimensions:
- Authority: Is the publisher responsible for the information?
- Directness: Does it directly support the claim or merely discuss the topic?
- Freshness: Is it current enough for the claim?
- Scope: Does it apply to the same product, country, plan, population, or time period?
- Independence: Is a second source needed because the claim is self-promotional or contested?
Avoid the fake-citation failure mode
One common AI failure is a citation that looks credible but does not support the sentence beside it. The URL may be real. The publisher may be reputable. The problem is source fit. A Source Ledger makes fit explicit because the "supports" field must be written before the source is used in the draft.
Why this matters for search content
Google's current guidance for generative AI search emphasizes original, useful, people-first content and says core SEO practices still apply. It also advises site owners not to mass-produce low-value pages simply to cover query variations. An evidence ledger does not guarantee rankings, but it gives a content operation a practical way to keep accuracy, originality, and human review visible as production scales.
Use ready-made Source Ledger and Claim Check files
The AI Research-to-Publish Engine includes editable Source Ledger and Claim Check CSVs, plus the Article Brief, publishing checklist, prompt workflow, operations guide, and n8n starter workflow.
See the AI Research-to-Publish Engine — $29