Where our facts come from
Sources & crawler policy
Every fact we publish is anchored to a registered source. This page explains how sources are classified and scored, the rules our crawler follows before it ever fetches a page, and how each fetch becomes an immutable snapshot in a verifiable evidence chain. For how those sources turn into published facts, see the methodology.
Source types
Sources are registered with a type and an authority score. The type records what kind of evidence it is; the score (below) records how much weight it carries. The counts shown are from our live register.
| Source type | What it is | Registered |
|---|---|---|
| Regulator | National telecom regulators and the ITU — the authority of record for network-code assignments and licensing. | 0 |
| Provider official | A provider's own site, documentation, or terms — authoritative for that provider's plans and policies. | 191 |
| Standards body | Industry standards organisations (e.g. GSMA) for definitions and technical baselines. | 59 |
| App store | Official app-store listings, used for device/app facts and version details. | 0 |
| Partner API | Structured feeds from partners who supply data under an agreement. | 0 |
| Editorial test | Facts derived from our own controlled testing, always labelled as test-derived. | 0 |
| User report | Reports from the public — the lowest authority, corroborated before anything is published. | 0 |
| Third party | Reputable third-party references, used to corroborate rather than as a sole basis. | 0 |
250 sources registered, 179 with a reviewed crawl policy currently permitting crawling.
Authority score
Each source carries an authority score between 0 and 1. It is kept deliberately separate from freshness: a regulator’s filing is highly authoritative even if it is a few months old, while a brand-new user report is fresh but low-authority. A regulator or standards body outranks a provider’s marketing page, which in turn outranks a third-party mention or a user report. When sources conflict, the higher-authority source prevails and the conflict is recorded rather than hidden.
Robots & terms review before crawling
A source cannot be crawled just because it exists in the register. Crawling is disabled by default and only enabled once a policy has been reviewed:
- Robots and terms reviewed. We record when a source’s
robots.txtand terms were reviewed. Crawling stays off until that review has happened and explicitly permits it. - Identified and polite. Our crawler identifies itself with a descriptive user agent, honours
robots.txt, applies a per-source rate delay and a single-request concurrency cap, and enforces byte and time limits. - Scoped fetching.Only the path patterns a source’s policy allows are fetched, on the interval that policy sets.
- Safe by construction. The fetcher blocks private, reserved, and metadata addresses, re-validates on every redirect, and pins each connection to the address it validated — so a source can never be used to reach internal infrastructure.
Snapshot & evidence chain
Every fetch that yields new content is stored as an immutable snapshot: the retrieved content, a content hash, and the time it was fetched. Identical content is de-duplicated by hash so we do not re-process unchanged pages, and each snapshot is preserved so the exact text a fact rests on can always be re-read.
A published fact then points at a specific evidence excerpt inside a specific snapshot, together with a locator, how it was extracted, and a confidence. That chain — source, snapshot, excerpt, verification, freshness — is what lets any fact on this site be traced back to the document it came from.
Corrections & takedowns
If a fact is wrong, out of date, or a source should not be crawled, we want to know. Providers can claim their brand to submit corrections through the review process, and anyone can report an issue for a fact via its page. Correction requests are reviewed on the same evidence-and-approval basis as any other change — nothing is altered without a source and an audit trail.