Good guidance has a source.

Evidence levels

Guides carry one of three levels. The level describes the guide's evidence, not its usefulness.

• Documentary - every substantive claim is supported by official documentation or official release notes that were read directly.
• Reported - built from public reports, such as issue trackers. These are real reports, but this site did not reproduce them, and they may describe a specific version, platform or account type.
• Reproduced - the behaviour was observed directly.

A lower level is never presented as if it were a higher one. In particular, a fix that has only been reported is never described as verified.

Sources

Each source entry lists the URL, what kind of source it is, when it was checked, and the specific claim it supports.

Sources are ranked, strongest first:

1. Official help pages, release notes and status pages.
2. Verifiable original posts from an official account whose identity has been checked against the platform's own user id.
3. Confirmations from project maintainers.
4. Community reports.
5. Third-party aggregator sites.

The last two categories are leads, not proof. A community report cannot on its own support the claim that all users were reset, and an aggregator is never the only source for a statement of fact.

What a published guide must contain

• A specific user problem, and the exact wording of what the user sees.
• An accurate scope: which client, which systems, which version range - or "Unknown" stated explicitly.
• At least one working source, with the claim it supports.
• Steps written as branches, because most errors have more than one possible cause.
• A success criterion, so the reader knows when to stop.
• A review record: who or what reviewed it, when, and when it is next due.

If the evidence is not there, the guide stays a draft. This site does not publish filler to reach a page count, and it does not invent commands, configuration keys or CLI flags.

Review and freshness

Each guide carries a last-reviewed date and a next-review date. Guides that describe changing rules - limits, resets and signals - carry a shorter review interval than guides that describe a fixed error message.

Automated checks list guides whose review is due. They do not silently rewrite content, and nothing is published automatically.

Corrections

When a claim turns out to be wrong or outdated, the guide is changed and its updated date moves.

• Only substantive changes move the updated date. A rebuild never refreshes every date on the site.
• The first publication date is never overwritten.
• If a source becomes unreachable, the last verified fact is kept and the failed check is recorded rather than quietly deleting the history.

What this site will not do

• It will not say "no reset today" or "no problem exists" from an absence of data. Missing data is reported as missing.
• It will not present an announced event as if it had been predicted.
• It will not show a success rate, a user count, or a probability without a stated sample behind it.
• It will not treat engagement numbers - likes, reposts, comment counts - as evidence that a reset occurred.

Reporting a problem with a guide

There is no working contact channel yet, so there is no correction form. This site will not display a feedback button that cannot deliver. When a reachable channel exists it will be listed here.

Related: About this site · Privacy