Three input types
The label matters as much as the number. A documented rule can be used as a default with a source. A public observation needs its limitations. A volatile or unknown value belongs in an editable field.
Documented rule
A developer announcement, official support page, patch note, public game file, or other checkable primary source.
Referenced estimate
A named public dataset or community reference with enough context to inspect its collection method and limits.
User input or example
A volatile price, route time, unknown rate, or planning target entered by the user or clearly labeled as illustrative.
Models used by the calculators
Fixed independent probability
If each eligible attempt has fixed success probability p, the chance of at least one success after n independent attempts is 1 - (1 - p)^n. This model must not be used when a pity ramp, shared reward pool, or mutually exclusive roll changes the trials. See theNIST binomial distribution definitionfor the fixed-probability trial boundary.
Guarantees and progressive pity
A hard guarantee is handled as a boundary state, not converted into an invented per-attempt rate. A progressive curve is modeled only when its start, increment, cap, and eligibility rules are sourced or supplied explicitly as assumptions.
Expected value and hourly value
Expected value sums each outcome probability multiplied by its value. Costs are subtracted before converting to an hourly result. Run time, prices, travel, and reset delays should be editable when they are player- or market-dependent. Penn State'smathematical expectation lessonprovides the underlying weighted-average definition.
Evidence we do not upgrade into fact
- An anecdote, screenshot, stream, or small personal run log without a documented collection method.
- An unnamed “community dataset,” unverifiable sample count, or anonymous expert credential.
- A stale patch value presented without its version or as a current live-service value.
- A hidden account mechanic inferred from a lifetime total, platform merge, or desired outcome.
- A mathematical example described as observed player data.
Claim record
A quantitative or mechanic claim that affects a calculator should have one record containing the exact claim, source URL, source tier, verification date, pages that use it, and whether it enters a formula. If the record cannot be completed, the value is changed to an input, labeled as an assumption, or removed.
Mathematical references
These references support the general mathematics only. They do not supply a game's rate, price, eligibility rule, or guarantee; those facts require a separate versioned source on the affected page.
Changes and corrections
Live-service pages are not assumed to be current forever. Dates describe when a source was checked, not a promise of continuous monitoring. When a rule changes, the model, page copy, structured data, listing summary, and tests should be updated together.
Report a discrepancy through the contact page with the affected URL and a public source. See editorial standards for the correction workflow.