How I Check a Claim Before Publishing It

A wrong price does not survive. Somebody pays it, notices, and complains loudly enough that the number gets fixed. A wrong capability survives for years, because nobody is out of pocket when an article says a tool can do something it cannot.

So that is what I look for first. The thing I catch most often is a claimed feature that the documentation never states, repeated from one article to the next until it reads as settled. I start with a plain search to find who said it first, rather than going straight to the vendor, because the origin tells me whether I am looking at one source or ten copies of one source. On recent work, 3 vendor pages would not load for me at all, so whatever figures those pages hold could not be used and I left them out. The checking costs me about an hour an article, and the worst part is that it goes out of date almost immediately: a figure confirmed today is wrong next month, and the article still states it with the same confidence.

Why the search comes before the vendor page

Going straight to the vendor feels more rigorous and it hides the useful information. If ten articles say a tool does something, the question is not whether the vendor agrees, it is whether those ten are ten sources or one source copied nine times. A plain search shows you that in about a minute, because the same sentence turns up in the same shape everywhere.

Once I know where it started, checking the primary page is quick, and I know what I am looking for rather than reading hopefully.

A worked example

Take a claim that circulates about Pocket shutting down: various write-ups give a specific shutdown date. Mozilla's farewell page, read on 2 October 2026, says it is phasing out the Pocket web, Android, iOS and macOS apps and the browser extensions, and points people towards Firefox tab groups and bookmarks. It gives no date.

That is the pattern exactly. The date is not a lie invented by anyone in particular. It got stated once, repeated, and now sits in a dozen articles with no primary page behind it. The honest thing is to say the page gives no date, which is less satisfying to read and is what the source supports.

What each failure looks like

Failure	How it shows up	What to do
Source does not say it	You follow the link and the claim is not on the page	Drop the claim, or state only what the page says
Page will not load	A block, a login wall or a region restriction	Leave the figure out rather than taking it second hand
Everyone copied one origin	The same sentence, word for word, across sites	Find the origin and check that instead
It was true once	Nothing on the page admits it changed	Date the fact, so a reader knows when it was true

The part that does not work

None of this stays true. A price verified this morning can change this afternoon, and the sentence in the article does not get any less confident when it does. Dating every fact is the only honest answer I have, and it is a label rather than a fix. It tells a reader when to stop trusting the number; it does not keep the number right.

The other cost is that this is invisible. An hour of checking produces nothing a reader can see, except the occasional sentence that says a figure could not be confirmed. That is also why I will leave a fact out rather than soften it, which is the same instinct that turned up when two of five cited links did not support what they were cited for.

The short version

Search before you trust a vendor page, because the origin matters more than the agreement. Treat capability claims with more suspicion than prices. If a page will not load, drop the number instead of borrowing it. And put the date next to anything that can change, because it will.