Source Trust

---
name: source-trust
description: How to weigh what a source is worth, how to read community opinion without mistaking volume for truth, and how to notice that several sources are really one. Use whenever a finding is going to be reported as fact.
---

# What a source is worth

## Weigh it for the specific claim, not in general

There is no such thing as a reliable source, only a source that is reliable
*about a particular kind of claim*. The same vendor page is the best source in
the world for "what do they say this costs" and the worst for "is it any good".

Ask what the source is in a position to know, and what it has an interest in:

- **The vendor's own pages, docs and changelog** — authoritative for claims,
  features, prices and dates. Not evidence about quality, adoption or whether
  the feature works.
- **Documentation and source code** — the strongest evidence there is for what
  something actually does. A feature in the docs and absent from the changelog is
  worth a second look.
- **Independent write-ups** — check for affiliate links, a "sponsored" line, or a
  comparison table where one column wins every row. Any of those makes it an
  advertisement; it can still be useful for the *axes* it compares on.
- **Community threads** — evidence about experience and sentiment. See below.
- **Aggregators and "top 10" pages** — usually derivative. Follow them to their
  source and cite that instead.

## Community sources, without mistaking volume for truth

Communities are where the things nobody publishes get said: what broke in
production, what the migration actually cost, why a team left. That is why they
are worth the trouble of reaching.

They are also the easiest place to be wrong, in four specific ways:

- **One loud thread is not a pattern.** A single angry post is evidence that one
  person was angry. Look for the same complaint in unrelated places before
  calling it a trend.
- **Complaints outnumber satisfaction structurally.** People post when something
  breaks, not when it works. A product with more complaint threads may simply
  have more users.
- **Threads are dated and products move.** A performance complaint from two
  versions ago may have been the reason the current version exists. Always carry
  the date.
- **Some of it is marketing.** An enthusiastic account with a posting history of
  one topic is a data point about marketing, not about the product.

Report community findings as what they are: *"several unrelated threads in
mid-2026 report X; the vendor's changelog says it was addressed in version Y,
which I did not find anyone confirming."* That sentence is worth more than either
half alone.

## Two sources that are one

The most common way a research report is confidently wrong: five pages all say
the same number, and all five got it from the same press release. Volume of
agreement is not independence.

Before treating agreement as confirmation, check whether the sources could have
known it separately. Look for the earliest one that states it as its own finding
rather than repeating it. If everything traces to one origin, say **one source**,
and name it.

The same applies to a figure that appears everywhere with no attribution at all.
A number nobody will stand behind is a rumour with good typography.

## What to write down

For every fact that will be reported:

- where it came from, specifically enough to open again
- when it was published or last updated, or that it does not say
- what kind of claim it is — the vendor's own, measured, or somebody's experience
- what would change your mind about it

That last one is the difference between research and a summary. A finding you
cannot say how to falsify is a finding you have not finished checking.