How is a source ledger different from a list of citations?

A citation list is document-first: it records what was read. A source ledger is claim-first: each row starts from a thesis claim and records the source, date, locator, and evidence role for that claim, including claims where no source was found.

What if I cannot find a source for a claim?

That row stays in the ledger with a missing-evidence status. An empty evidence cell is a finding in itself: it names an assumption the thesis needs that the reviewed public record did not support.

Does a complete source ledger validate the thesis?

No. A ledger describes which claims are supported, pressured, or unproven in the reviewed sources as of a stated date. It does not produce a recommendation or a verdict on the stock.

How to build a source ledger for a stock thesis

A stock thesis usually arrives as a paragraph. A source ledger turns that paragraph into rows: one row per claim, each row carrying its evidence, its date, and its status. The source ledger hub explains what a ledger is and how to read one; this guide covers the other direction, how to build one by hand.

The method is descriptive from start to finish. The finished ledger says which claims are supported, which face pressure, and which remain unproven in the reviewed sources. It does not provide buy, sell, hold, rating, sizing, or price-target recommendations.

Start from claims, not documents

The most common failure mode is document-first research: read the filings, highlight interesting passages, and end up with notes that orbit the company rather than the thesis. A ledger is built the other way around. Write the thesis as numbered claims first, then go looking for evidence claim by claim.

A claim earns a row when a public source could, in principle, support or fail to support it. "Segment revenue is growing faster than the company total" is a row. "Management is world-class" is not, until it is restated as something observable, such as capital-allocation history or stated targets versus delivered results.

The fields every row needs

A usable ledger row carries six fields:

Field	What it records	Why it matters
Claim	The thesis statement being checked, in one sentence	Keeps the row testable
Source	Filing type and title, or another named public source	Makes the evidence traceable
Date	The source's publication or filing date	Anchors the row in time
Locator	Section, item, note, or page within the source	Lets a reader re-find the passage
Evidence role	Support, pressure, context, or missing	Prevents everything from reading as confirmation
Retrieval status	Retrieved, not available, or not checked	Separates "no evidence" from "did not look"

The locator is the field most often skipped and most valuable later. "10-K, Item 7, liquidity discussion" is re-findable months later; "the annual report" is not.

Date every row

Evidence has a shelf life. A ledger without dates quietly mixes a three-year-old segment disclosure with last week's filing and presents both as current. Every row gets the source's own date, and the ledger as a whole gets an as-of date: the day the review was performed. Anyone reading the ledger later can then tell exactly what "the record" meant at the time.

Record retrieval failures

The habit that separates a ledger from a scrapbook: when a source cannot be found or accessed, that fact goes into the ledger instead of disappearing. A claim checked against nothing is different from a claim checked and unsupported, and both are different from a claim never checked. This is why the row schema carries a retrieval status. A ledger that only contains successes overstates its own coverage, which is the problem a completeness ledger exists to solve: showing what was checked, not only what was found.

Assign the evidence role honestly

Each retrieved passage gets one of four roles:

Support: the passage directly backs the claim.
Pressure: the passage makes the claim less complete or more conditional.
Context: relevant background that neither backs nor pressures the claim.
Missing: the claim matters and no reviewed source addressed it.

The temptation is to let support absorb everything. A disclosure that confirms revenue grew while also revealing that one customer drove the growth is not pure support; it is support for the growth claim and pressure on the durability claim. Splitting it into two rows is what a source ledger is for. How strongly a passage backs a claim is its own question, which is what a verification tier expresses.

Where the sources come from

For SEC-reporting issuers, the primary shelf is EDGAR. Investor.gov's guide to using EDGAR covers locating a company's filings, the SEC's forms index describes what each form type contains, and EDGAR full-text search lets you search across filings for a phrase, which is useful when a claim mentions something specific like a named product, customer, or covenant.

A worked example row

Suppose the thesis says: "The company can fund its expansion without raising new capital." One pass through the latest 10-K might produce:

Claim	Source	Date	Locator	Role	Status
Expansion is funded internally	10-K	filing date	Item 7, liquidity and capital resources	Support	Retrieved
No near-term refinancing pressure	10-K	filing date	Debt footnote, maturity schedule	Pressure	Retrieved
Expansion is on schedule	none found	n/a	n/a	Missing	Not available

Three rows, three different findings, from one claim cluster. The sample report shows what this structure looks like at full scale, where every claim in a thesis gets this treatment.

Finish with the boundary

A finished ledger is a dated map of the public record against one thesis: supported here, pressured there, silent in these places. It is deliberately not a conclusion. The reader keeps the judgment; the ledger keeps the receipts.