Methodology

Nothing consequential is published from memory or from a single human’s recollection. Each fact is built on a five-link chain, and if any link is missing the fact stays unpublished:

1. Source— a registered document with a type and an authority score: an ITU/regulator record, a provider’s official page, a standards body, an app store listing, or a partner feed. See our source and crawler policy.
2. Snapshot — an immutable, content-hashed capture of that source at a moment in time, so the exact text a fact rests on can always be re-read.
3. Evidence excerpt — the specific quoted passage plus a locator, recorded with how it was extracted (deterministic parser, language model, or manual) and a confidence.
4. Verification state — whether the fact is independently verified, provider-claimed, unverified, stale, or disputed (see below).
5. Freshness — when it was last verified and when it is due for review.

Prices are stored as exact integer minor units in their real currency — never as rounded floating-point money — and version history is preserved so a change can always be traced.

The single most important rule on this site: an absence of evidence is not evidence of absence. A capability we have not been able to confirm is marked Not publicly disclosed— a distinct state that is never collapsed into “No”. Every capability resolves to one of four states:

Yes

The capability is present and backed by a cited source.

No

The source explicitly states the capability is absent — not merely undocumented.

Not publicly disclosed

We could not find an authoritative statement either way. This is UNKNOWN — never silently rendered as “No”.

Not applicable

The capability does not apply to this kind of plan or entity at all.

This is why you will see “Not publicly disclosed” on our pages where a lesser site would guess a “No” or invent a “Yes”. Truth before volume: a smaller verified catalog is worth more than a large one full of confident guesses.

We deliberately separate who an entity is from what it does commercially, because the two are established by different evidence and change at different rates.

• Identity— the legal entity, the brand, and the network are modelled as separate things. A brand can be operated by one legal entity and ride on another company’s network; we record each link explicitly rather than flattening them.
• Commercial role — whether a brand is a mobile network operator, an MVNO, a reseller, a marketplace, or a platform. Where a party holds an ITU E.212 network code but its market role has not been independently established, we classify it precisely as a network-code assignee rather than guessing that it is an MNO.

Network relationships between brands and networks always carry a derivation label (official, test-derived, or reported) so you can see how the link was established.

A fact’s verification state is separate from its source’s authority and from its freshness. We surface all five states — a provider’s own claim is shown as a claim, and a conflict is shown as a conflict:

Independently verified

Confirmed against a source we control the reading of, still within its freshness target.

Provider-claimed

Submitted by a provider who has claimed the brand, but not yet independently confirmed. Shown as claimed, not as verified.

Unverified

No verification is on record yet.

Stale

Previously verified, but the last check is now past twice its review target. Labelled — never hidden.

Disputed

Conflicting evidence exists. We surface the conflict rather than pick a winner silently.

Every published fact records when it was last verified and when it is due for review. Facts that drift past twice their review target are labelled stale and remain visible with that label — we never hide an aging fact to look more current than we are. A background scan re-checks freshness on a schedule and flags what needs re-verifying.

No single actor — human or AI — can push a consequential fact straight to a public page.

• Proposals, not writes. Provider submissions and AI extractions become reviewed proposals. They never mutate canonical records directly.
• Human approval for risk. High-risk facts (price, coverage, hard capabilities) require a human reviewer to approve before they publish. AI proposes candidates; it never self-publishes.
• No self-approval.A reviewer who belongs to the submitting organisation cannot decide that organisation’s own high-risk proposal — a conflict-of-interest rule enforced in the data layer, not just the UI.
• Immutable, audited versions. Published facts change by creating a new version in a single transaction, appending an audit record; prior versions are never edited in place. This is what powers the plan version history.

eSIMRoamly makes no paid rankings. Any ranking or “best-value” recommendation we publish must show its methodology inline: the criteria, the underlying facts, and the evidence and freshness behind each. Rankings are computed independently of any commercial relationship, and sponsored placements are always labelled as such.

Today the live catalog contains verified provider identities and destinations but not yet enough sourced, reviewed plan-level pricing to rank fairly — so we publish no plan rankings rather than a plausible-looking guess. When plan comparisons go live, this methodology is the contract they will be held to.

We never publish a universal PUK, PIN, unlock, or interception/bypass code. Service-code content is gated so that harmful or account-compromising instructions cannot be published, and billing-changing codes require an explicit scope, source, and warning.