Methodology

What counts as a fact

A fact is one atomic claim about one plan: a duration, a rate, a ceiling, a price, or a capability that is either present or not. Anything that cannot be tied to a single plan and a single key is not stored.

Every fact carries its evidence

We keep the vendor's original wording next to a normalised value, plus the source URL, the type of source, the moment it was retrieved, and the moment the fact was last verified. If evidence cannot be retrieved, the fact is not published.

Normalisation

Values are converted into one canonical unit per key, so seconds stay seconds and tokens stay tokens. Units are always explicit, never implied by the key name. Prices keep their currency.

Status

• verified checked against its source inside the recheck window.
• stale past the recheck window; still the last known good value.
• conflicting two credible sources disagree; both are retained.
• removed the vendor withdrew the limit; kept for history.
• inferred derived rather than published, and never served publicly.

Automated rechecks

Every night the source pages behind each fact are fetched again and their content compared with what was recorded at capture time. An unchanged page re-verifies its facts. A changed page never rewrites a value: the facts drop to stale and a change record flags them for a human re-read. Run history is on the status page.

Failed checks never overwrite

If a verification run cannot reach a source or cannot parse it, the previous verified value stays in place and is marked stale instead. A broken crawl must never look like a product change.

Proposed updates need a human

When a recheck finds a page changed, an extraction job re-reads that page and drafts a suggested value for each out-of-date fact — with the sentence it came from, a confidence score and the model used. These drafts are proposals: they are stored privately, never served by the public API, and they change nothing until a reviewer reads them and approves. An approval updates the fact, sets it back to verified and writes a change record; a rejection keeps the old value on record. The review queue is only reachable to signed-in reviewers with a server-side role.

Change history

When a value genuinely moves, we write a change record with the old value, the new value, when it was detected and when it takes effect. Wording changes that leave the value intact are not changes.

Corrections

The dataset will be wrong sometimes. Sources are linked on every row precisely so a claim can be checked, disputed and fixed.