How the predictor calculates — and where it is wrong
This page lists everything the predictor assumes. It is deliberately dry. The home page shows you a window and a pacing rule; this page shows you why, so that you can disagree with a specific number rather than with a black box.
The code that does all of this runs in your browser and is readable: /js/engine.js and /js/parsers.js. Nothing you upload is sent anywhere.
The three legs, in one sentence each
Swim: your measured pace per 100 m, converted from pool to open water if it came from a pool, times the course distance, with a small fade on long swims. Bike: your target power (a fraction of FTP that depends on the distance) pushed through a physics model — aerodynamic drag, rolling resistance and gravity — segment by segment along the course profile. Run: a recent standalone run scaled to the race distance, slowed by a distance-dependent "off the bike" penalty, then adjusted segment by segment for gradient using the metabolic cost of running on slopes.
Transitions are added as the medians of a real field of 665,769 full-distance finishers (scaled for shorter distances), unless you enter your own.
What your files are used for
| You upload | The predictor reads | And derives |
|---|---|---|
| Swim files | distance, time, pool length, GPS presence | pace per 100 m, and whether it was a pool or an open-water swim |
| Rides with power | 1 Hz power stream | best 20-minute power → FTP estimate (× 0.95) |
| Rides without power | distance, time, climbing | sustained speed over flat-ish rides (< 8 m/km of climbing) |
| Runs | distance, time | your best run by Riegel-equivalent, as the reference performance |
Pool or open water is decided by the file, not by you. A FIT file that carries a pool length, length records or the lap swimming flag is a pool swim. One with GPS positions or the open water flag is open water. A swim with neither is assumed to be a pool swim, and the predictor says so. GPX swims are open water by construction (they have a track). If both kinds are present, the open-water files win and the pool ones are ignored — a measured open-water pace beats a converted one.
Training runs are not races, so a run-derived prediction is conservative. If you have a recent race, enter it under "Enter numbers".
Swim: pool → open water
Fifteen years of forum threads ask the same question — my pool 100 m pace gives what on race day? — and the honest answer is a product of factors, each of them an estimate:
| Factor | Value | Why |
|---|---|---|
| No walls | +4.0 % (25 m pool) / +2.5 % (50 m) | push-offs and turns make pool pace faster than the swimming in it |
| Sighting and extra distance | +4.0 % | you do not swim the straight line, and lifting the head costs |
| Wetsuit | −5.0 % | when legal and worn; the range in the literature is roughly 3–7 % |
| Sea chop | +3.0 % | sea courses only |
| Salt buoyancy | −1.0 % | sea courses only |
| Drafting | −2.0 % | a mass start gives feet to follow |
| Distance fade | +0.6 % per 1,000 m beyond the first | pace drifts on long swims |
Applied to a 1:50 /100 m pool swimmer on a lake course with a wetsuit: about 1:51 /100 m in open water. On a sea course: about 1:53. These factors are not measured on our users yet; when real race results come in, they will be calibrated against them, publicly. Open-water files skip the first two and the chop factors entirely.
Bike: physics, not a table
For each segment of the course the engine solves
P × η = ½ ρ CdA v³ + Crr m g cos θ v + m g sin θ v
for speed v, with drivetrain efficiency η = 0.975, air density ρ = 1.20 kg/m³, rolling resistance Crr = 0.0045, and a drag area CdA of 0.28 m² for a tri bike in the aero position or 0.34 m² on a road bike. Mass m is your body weight plus 9 kg of bike and kit. There is no wind: the data for it does not exist at prediction time, and adding a guess would only hide the real uncertainty.
Pacing follows what athletes actually do: 105 % of target power on climbs steeper than 2 %, 55 % on descents steeper than −2 %, and descents are capped at 70 km/h.
Target power is FTP × intensity, with intensity by distance: 0.90 (sprint), 0.85 (Olympic), 0.78 (middle), 0.70 (full). You can override it; if you ride harder than the default, the run slows down (below).
If you have no power meter, your sustained flat speed is converted to an implied power with the same equation, treated as a middle-distance effort, and rescaled to the target distance.
Course profiles. Where a course has a hand-built segment profile, the engine uses it. Where only the total climbing is known, it spreads it over a rolling profile — half the segments climb, half descend — which is the least-wrong assumption without the real profile, and the result page says when this is the case. Course figures marked * are approximate and not yet verified against the organiser's pages. The course layer is being built by hand, race by race, from open data (OpenStreetMap, Copernicus DEM, the 1 m Walloon LiDAR model); it is slow work and it is the part of this site that will take longest to be good.
Run: fresh pace, then the bike, then the hills
- Your reference run is scaled to the race distance with Riegel's exponent 1.06.
- The result is multiplied by an off-the-bike penalty: 1.03 (sprint), 1.05 (Olympic), 1.10 (middle), 1.18 (full). These are the assumptions I am least sure of; they sit inside what age-group fields typically show, and they will be the first thing calibrated on real results.
- Each +0.01 of bike intensity above the distance default costs +0.6 % of run pace.
- On each segment the pace is scaled by the ratio of the metabolic cost of running at that gradient to the cost on the flat, from Minetti et al. (2002), capped at 15 % faster than flat pace downhill.
Transitions
The only large open dataset with transition times is the full-distance one: median T1 7.6 min, T2 6.2 min, both together 14.1 min, with 10.0 min at the 25th percentile and 28.0 at the 95th. Those medians are the default for a full-distance prediction. For shorter distances the defaults are scaled assumptions (sprint 2:30 / 1:30, Olympic 3:00 / 2:00, middle 4:30 / 3:30) because no open dataset carries them. Enter your own if you know them.
The window
Each leg carries a relative uncertainty — swim 6 %, bike 4 %, run 8 %, transitions 30 % — combined as if independent. The window shown is ± one combined standard deviation around the estimate: on a full-distance day of 12 hours that is roughly ± 25 minutes.
These are prior values, not measured errors. They are almost certainly too narrow for a first race and too wide for someone who has raced the exact course before. The predictor will start publishing its measured error — predicted versus actual, by leg — as soon as users report real results. Until then, read the window as a pacing instruction, not a guarantee: start at the slow end.
Two things the window does not include: the weather, and you having a bad day. Neither is predictable from training files.
The field comparison
The percentiles on the result page place your predicted splits in a real field: 665,769 finishers across 394 full-distance races between 2002 and 2022, published by Knechtle and colleagues alongside their 2024 paper in PLOS ONE under a CC BY 4.0 licence. Nine races out of 403 were excluded because their median splits are impossible for the distance (shortened swims or bike courses recorded as normal); the filter and its effect are described in this analysis.
The deposited file carries split times and a race identifier, nothing else — no sex, no age group, no country, no year. So the main comparison has no breakdown by category, and it exists only for the full distance. I would rather say that than imply a breakdown the data cannot support.
By sex. A second file from the same authors (Sex difference in IRONMAN age group triathletes, PLOS ONE 2024, CC BY 4.0) was opened column by column on 22 September 2026: 99,719 finishers at eight named North-American full-distance races between 2003 and 2014, with sex — and nothing else: no age group, no transition splits, no course characteristics, although the paper used some of them. When you give your sex, a second row of percentiles is drawn from this file for swim, bike, run and total. Its transitions are only implied (total minus the three legs) so T1 and T2 stay on the first dataset. One of its eight races is Hawaii, a qualifier-only field, kept as published. Median finish in this file: 12.46 h for men, 13.36 h for women.
Calibration. The report form collects predicted-versus-actual pairs, by leg. As soon as there are enough of them, the measured error replaces the prior uncertainties above, and the log is published — including the misses.
What would change these numbers
Real race results from users, compared to their prediction. That is the whole plan: publish the error, by leg, including when it is bad, and let the constants above move toward what the data says. A predictor that never tells you how wrong it was is a predictor you cannot trust.
Sources: Martin J.C. et al. (1998), Validation of a mathematical model for road cycling power, J Appl Biomech 14(3). Minetti A.E. et al. (2002), Energy cost of walking and running at extreme uphill and downhill slopes, J Appl Physiol 93(3). Riegel P.S. (1981), Athletic records and human endurance, American Scientist 69(3). Knechtle B. et al. (2024), PLOS ONE, DOI 10.1371/journal.pone.0315064, S1 Data, CC BY 4.0.