How we calculate everything

Why raw elevation numbers can’t be compared

The same course returns wildly different elevation totals depending on the device, the trackpoint density, and the smoothing the source applied — we have seen one course reported as roughly 932 ft of climb by one source and 748 ft by another. Publishing either as fact would be misleading.

So we never ingest a source’s elevation total. We ingest the course geometry (coordinates) and run every course through one identical pipeline. The output is comparable across every course because it was produced by the same code with the same fixed, published parameters.

How we normalise a course profile

Given the geometry (latitude/longitude, plus raw elevation where present), we apply the following deterministic steps. Where raw elevation is sparse or noisy, we derive it from a public, keyless elevation dataset by coordinate and record which source was used per course.

1. Resample to a fixed step of Δ = 10 m by linear interpolation, removing trackpoint-density bias.
2. Smooth with a rolling median over W = 50 m, then a light Gaussian with σ = 20 m.
3. Accumulate gain and loss with a hysteresis of τ = 1 m, which kills GPS-noise inflation.
4. Classify every resampled segment into grade buckets and record the percentage of distance spent in each.
5. Integrate the published grade-to-energy-cost function over the course to produce the GAP factor.
6. Stamp the output with the methodology version and a recompute hash = sha256(geometry snapshot + methodology version) so any number can be reproduced.

What is the GAP factor, and how is it computed?

RaceIndex uses GAP factor as a legacy field name for percentage change in modelled running energy cost versus flat. It is not a measured pace penalty or a validated personal finish-time forecast. The model uses the Minetti et al. (2002) cost-of-running polynomial in gradient (rise over run).

At each resampled segment we calculate Cr(i), divide by flat cost Cr(0) = 3.6, then take the distance-weighted mean. The reported percentage is 100 times (mean ratio minus 1). Negative values represent lower modelled energy cost, not a promised time saving.

The source study measured ten runners on treadmill gradients from -45% to +45%. We withhold energy output if any positive-length segment is outside that domain or has invalid inputs. Empty geometry is unknown, not flat. Independent terrain measurements may still be available. Lower energy cost does not establish which course a particular runner will finish faster.

Source: Minetti et al., Energy cost of walking and running at extreme uphill and downhill slopes (2002).

Finisher distributions and the Field-Quality Index

For each race edition we compute an aggregate-only distribution — the count, median, the 10th/25th/75th/90th percentiles, the fraction of finishers below each distance-appropriate threshold band, and the DNF rate. We never store, index, or republish individual finisher rows; aggregation happens in memory and the rows are discarded.

Fast events attract fast fields, which would make a fast course look even faster for the wrong reason. The Field-Quality Index (FQI) corrects for this: we benchmark the edition’s fast tail (its 10th percentile) against the all-UK baseline for that same distance, producing a field-strength multiplier. The empirical-speed signal is de-confounded by FQI before it feeds the score, so we measure how fast people run once we control for who showed up.

How is PB-potential calculated?

PB-potential is the headline score and the hard-to-copy one, because it fuses two independent signals: the course should be fast (physics), and runners actually do run fast there once you control for the field (empirical). It is a weighted sum of three terms:

pb_potential = w₁·gap_term + w₂·empirical_term + w₃·conditions_term

The gap_term comes from the GAP factor (lower GAP scores higher); the empirical_term is the field-normalised real finish speed from the distribution (de-confounded by FQI); the conditions_term is the typical race-date temperature favourability. The default weights are published below, and we publish a sensitivity table alongside them.

Why the weights are trustworthy (the sensitivity table)

A score is only honest if its ranking does not lurch when a weight is nudged. We publish a sensitivity table that perturbs each PB-potential weight by a fixed amount and reports how much the resulting ranking moves (rank-correlation against the baseline ordering). A stable, high rank-correlation under perturbation means the headline ordering is driven by the data, not by a fragile choice of weight.

If a methodology change ever made the ranking sensitive to small weight changes, that is a signal to revisit the weights — and any such change would itself be a version bump, recompute, and log entry.

Value, conditions, beginner-friendliness and organisation

Value is the total cost to the start line — entry fee plus modelled travel and modelled accommodation by origin region — per finisher, benchmarked across the distance. Travel and lodging are labelled modelled estimates, not live prices, which is deliberate: it lets us avoid booking APIs while still surfacing the real ~£500+ outlay of which entry fee is only about a tenth.

Conditions favourability scores the typical race-date weather: no penalty inside the optimal temperature window, with published penalties per degree outside it and per unit of typical precipitation and wind above a floor.

Beginner-friendliness rewards a generous cutoff, a supportive field size, high support density, low gradient and a high flat-bucket percentage — especially meaningful at the half and 10k, the beginner-heavy distances.

Organisation is a counts-weighted aggregate of review sentiment (ratings and counts only — never verbatim review text).

The overall score (no black box)

The overall score is a published weighted composite of the five sub-scores, with the weights shown below. Race pages show the score module only when the composite passes the source gates; otherwise the page stays focused on route, logistics, cost, conditions and other verified facts.

A composite score has two public states on race pages. Published means every required source-backed input is present and the 0-100 score can be shown. Not published means no score block is shown; the page can still be useful through route evidence, verified facts, grounded copy or race-character data, but not through a score claim.

The overall source gates are: verified route/elevation profile, aggregate finisher distribution, typical race-day conditions, published entry-fee evidence and aggregate organisation/reputation evidence. Modelled travel or accommodation costs can support value context, but they do not by themselves satisfy the entry-fee publication gate.

Facts are collectable; expression is not

That a course is two laps, passes the cathedral, has eight aid stations and a six-hour cutoff are facts — not protected expression — and collecting them is legitimate. The wording on an organiser’s site is theirs, and we never store or reuse it.

So the architecture splits fact extraction from copy generation. We harvest atomic facts, throw away the source’s sentences, and write our own. This yields two guarantees: originality by construction (the writer is fed the structured fact set and our own data, never source prose, so the output cannot be a paraphrase) and truth by construction (copy may only assert what a verified, sourced fact supports — no invented atmosphere, no hallucinated landmarks).

What facts we collect (the key-fact taxonomy)

We harvest a defined set of visitor-relevant, factual predicates at three subject levels. Event-level facts are collected once and inherited by every distance, so a venue fact can never disagree between sibling pages. The full taxonomy is shown below.

The derived facts — gradient, finisher percentages, typical conditions — are the differentiator: copy grounded in data no competitor and no general-purpose model holds is exactly what earns ranking and citation.

Only verified facts reach the page

A harvested fact becomes verified only above a confidence of 0.80 and, where applicable, with cross-source agreement; every conflict is logged. Derived facts inherit the methodology version stamp.

Only verified facts are eligible to ground copy (C-COPY-1). An unverified fact never reaches a published sentence.

How the copy is written

The writer’s input is the verified fact set for the subject plus our computed scores and data — never source prose. It emits one block per page slot, and every factual claim in a block carries the identifier of the fact that grounds it. The standard slots per page type are listed below.

Data integration is mandatory: the prose must weave the proprietary numbers (gradient, finisher %, true cost, conditions) into natural sentences — “two flat laps along the seafront, among the ten fastest halves on our model, with a realistic sub-2 rate of X%” — because that is what makes the page the most useful one on the topic and what AI answers quote.

Voice and tone

Knowledgeable runner-to-runner: specific, useful, honest. No filler, no hype, no keyword-stuffing. Numbers are integrated naturally rather than bolted on, and every factual claim maps to a fact identifier so the prose is as auditable as the data.

How we quality-check copy

Five controls gate every block before it can be published. Grounding, originality, contradiction and helpfulness are automated; a human tier reviews all flagship pages and a sample of the rest. The gates are listed below.