The post-race recap — full reference

What it is

After a race is logged, the post-race recap surfaces every useful comparison the platform can make from the data on file: predicted vs actual splits, calorie burn, transitions, fueling plan vs what was actually consumed, per-leg power / HR / pace stats, pacing analysis with decoupling, matches-burn / W' depletion, and a CdA estimate from the bike FIT.

It's the single page a coach opens after a race to understand what happened. Athletes can use it for the same purpose, plus log their own fueling and download a PDF copy.

Three places to find it

1. Inline on /my-races/ — finished races on the athlete's race dashboard show a "Race recap" card under the race entry.
2. Standalone page at /race/<id>/recap/ — same content with simpler chrome, suitable for sharing a link or printing.
3. PDF download — [⬇ Download PDF] button at the bottom of the recap card. One-page A4, Yousuli-branded, mirrors the web layout for offline review.

Permissions: athletes see their own races; coaches see races for athletes they coach; superusers see all.

The headline finish — Actual / Model / Coach

Three big tiles at the top of the recap:

• Actual — what you actually did (from actual_finish_time on the race row).
• Model — the model's pre-race prediction. Populated from a saved triathlon_finish_time calculator result linked to the race. If no calc was saved before the race, this column is hidden gracefully.
• Coach goal — what the coach (or athlete) set as the goal pre-race (goal_finish_time).

Each tile is colour-accented (orange / amber / navy) so they're distinguishable at a glance. The two headline deltas immediately below ("vs Model: -1.9% faster", "vs Coach: -1.2% faster") are colour-coded green for faster, red for slower, neutral within ±1%.

Per-split table

The next block breaks the comparison down by leg (swim / bike / run + a bold finish row). Each row has Actual / Model / Coach times + percentage delta pills against each. Green pills = faster than the prediction; red = slower; neutral = within ±1%.

Energy

Estimated calorie burn for the race, computed server-side using the MET model × athlete weight × actual durations:

• Swim race effort: 9.8 METs
• Bike race effort: 11.5 METs
• Run race effort: 13.5 METs
• T1/T2: 5.0 METs

Within ±10% of more sophisticated estimates for healthy adults at race intensity. Shows total burn, per-leg breakdown, the bike power target (if set), and the run pace per km.

The energy section is hidden when the athlete has no weight on file (we can't compute the gravity term without it). Set Athlete.weight_kg on the profile to make it appear.

Transitions

Two small cards labelled "T1 · Swim → Bike" and "T2 · Bike → Run" showing the transition times from Race.actual_t1 / Race.actual_t2. When a dedicated transition FIT child exists (rare — most uploads are single-discipline files), the card also surfaces transition distance + HR; a follow-up adds this for multi-leg multisport FITs that Garmin records as one file.

Fueling — planned vs actual

Per-product log of what the athlete planned to consume vs what they actually consumed. Each entry has product name, leg (pre / swim / T1 / bike / T2 / run), carbs (g), fluid (mL), sodium (mg), caffeine (mg), and optionally the minute it was taken.

The recap shows a 4-row comparison table (CHO / fluid / sodium / caffeine) with planned, actual, and delta. When the athlete has logged actuals, it also lists the products consumed per leg.

Adding entries

Open /race/<id>/fueling/ from the "Add your fueling log →" link on the recap. Two ways to populate the planned side:

1. Seed from the saved fueling plan — if the athlete (or coach) ran the Race-day fueling calculator for this race and saved the result, click "Seed planned from saved fueling plan" and the calculator's carry-plan items load as planned entries.
2. Add manually — fill in the form per product (name + leg + any of carbs/fluid/sodium/caffeine that you know).

Athletes log actuals post-race the same way (select "Actual" as the Kind). Both planned and actual entries can be edited or deleted from the fueling-log page; the recap updates immediately.

Leg-by-leg from the FIT

When a bike, swim, or run Activity is matched to the race date, the recap shows a per-leg detail card with all the data the FIT contains. Matching rule:

• Athlete = race athlete
• Date within ±1 day of race date (timezone slop)
• Sport matches (swim / bike / run)
• If multiple of the same sport exist on the day (warm-up + race effort), the longest by distance wins
• Multisport files (one Garmin FIT with swim → T1 → bike → T2 → run) — the per-leg child rows match cleanly to each leg

Per-leg card shows:

Common to all legs

• Distance, time, pace or avg speed
• Avg HR (max in parentheses)
• Avg cadence (bike rpm / run spm / swim stroke rate full)
• Elevation gain
• Total calories (from the FIT, if recorded)

Bike-specific

• Avg + normalized power, max power
• IF (Intensity Factor) = NP / FTP. FTP pulled from MetricHistory (critical_power or ftp).
• TSS (Training Stress Score) computed from IF.
• CdA estimate — see its own section below.

Run-specific

• Same as bike when Stryd power data is recorded
• IF + TSS use run_power_threshold from MetricHistory

Swim-specific

• Pace per 100m
• Stroke rate (in strokes/min full — FIT records per-arm, we double for full)

Pacing analysis

For bike + run legs the recap re-parses the FIT stream and splits it in half by time, then shows:

• 1st half vs 2nd half comparison: power, pace, speed, HR
• Pacing verdict pill:
  • 🟢 negative split — built into it (2nd half ≥ 3% stronger)
  • 🔵 even — held pace
  • 🔴 positive split — faded (2nd half ≥ 3% weaker)
• Pa:HR decoupling — Skiba-style power-to-HR drift between halves. < 5% well-coupled (good pacing + fueling), 5-10% mild drift, > 10% significant drift suggesting under-fueling or pacing failure.

Matches burned — W' depletion

For bike + run legs (when the athlete has CP + W' in MetricHistory), the recap runs the Skiba CP/W' model per-second on the power stream to surface:

• W' burned — total kJ of anaerobic work spent across the leg
• W' lowest — % of full at the closest-to-popping moment
• W' end — % of full at the finish (recovery quality)
• Time over CP — % of samples where power exceeded CP
• Peak power — max instantaneous power in the leg
• Matches — discrete above-CP bursts (≥ 5s, ≥ 3% of full W'), sorted by cost: timestamp, duration, avg power, kJ cost, peak drop in balance

How to read the matches table

The matches table is the most diagnostic piece of the recap. Use it to ask "what happened at that moment?":

• Match at 1:59 in a 2h ride, 332W for 10s, 0.9 kJ — probably a pack surge, a short climb, or a position move.
• Match at the end of a leg, 30s at 380W, 1.8 kJ — the finishing kick. Battery should be near empty.
• Multiple early matches — athlete went out too hot or had to cover early attacks. Pacing decisions to review.

For shorter races (sprint, Olympic) where the anaerobic budget is the main pacing constraint, this block is essential. For long events with a steady tempo strategy, it confirms the strategy was followed ("no significant matches burned — clean pacing").

What's needed

• Athlete.MetricHistory for critical_power + w_prime (bike) or run_power_threshold + run_w_prime (run). The platform auto-estimates these from your historical files — see the Critical Power calculator if you want to override.
• The activity's FIT must have a per-second power stream. Bike head units and Stryd run pods record this. Apple Watch outdoor runs typically don't.

CdA estimate (bike only)

The recap auto-computes a CdA estimate for the bike leg by back-solving the cycling power equation per-second on the FIT stream:

P = ½·ρ·CdA·v³  +  Crr·m·g·v  +  m·g·v·grade

Filters out swim and run portions of multisport files via a minimum-speed cutoff (5.5 m/s ≈ 20 km/h). Trimmed mean across all valid samples (drops top/bottom 5% to suppress gust / draft outliers).

Density (ρ) handling

This matters a lot for aero calcs (4% density change = 4% CdA change). The recap uses the most accurate density it can:

• If the FIT records barometric pressure per-sample (Garmin Edge models) → use that directly. Source label: "FIT pressure".
• If the FIT records temperature + altitude → derive density via the barometric formula + ideal gas. Source label: "FIT derived".
• If neither → use 1.225 kg/m³ standard atmosphere. Source label: "default".

The card surfaces which source was used + the computed value, so the coach can see whether the estimate is high-confidence or back-of-envelope.

Assumptions

• Rider weight from Athlete.weight_kg (required — hidden if missing)
• Bike weight default 8.5 kg
• Crr default 0.0042 (typical road tubeless at race pressure)
• Drivetrain efficiency 97.5%

For a more rigorous estimate with tunable filters, open the CdA calculator via the activity picker — same physics, more knobs.

When sections are hidden

Each section degrades gracefully when data is missing:

Section	Hidden when…
Headline tiles	No actual_finish_time
Model column	No saved finish-time CalculatorResult
Coach column	No goal_finish_time
Per-split table	No actuals at all
Energy	Athlete weight missing
Transitions	actual_t1 / actual_t2 empty
Fueling	No fueling-log entries AND no saved plan
FIT leg detail	No Activity matched to that leg
Pacing analysis	< 20 stream samples
Matches burn	No CP/W' in MetricHistory OR no power stream
CdA estimate	Athlete weight missing OR < 60 valid bike samples

The empty state never confuses the user — only sections with real data render.

Sharing the recap

• Share by link — the standalone URL /race/<id>/recap/ is permissioned the same way as the inline view (athlete owns, coach has relationship, superuser). Send the link to your coach or share in a private context.
• PDF download — the [⬇ Download PDF] button generates a printable A4 mirroring the web layout, with a Yousuli header and the race ID footer. Filename auto-generated from race name
• date (e.g. recap-Cairns-70-3-2026-05-28.pdf).

What's still on the roadmap

• Transition HR + distance enrichment for back-to-back single-discipline FITs (requires transition-window detection)
• Season comparison — multiple finishes of the same race side-by-side
• AI-generated commentary ("you negative-split the bike, that's why your run held up") interpreting the numbers in plain English

See also

• CdA from FIT explainer
• CdA calculator deep-dive
• Race-day fueling calculator
• Critical Power calculator
• CSS calculator

Transitions — HR enrichment (May 2026)

The transition cards now show HR avg / range when a matched FIT exists. Two sourcing strategies:

• Multisport file — single FIT with parent + per-leg children. T1 HR is sliced directly from the parent stream between the swim and bike sessions (real transition HR).
• Separate single-discipline FITs — three watches recorded independently. There's no recording during the actual transition, so we use the first 90 seconds of the next leg as a proxy. Labelled accordingly on the card and PDF.

Distance check & trim (May 2026)

For race-day FITs with a known race format, the leg card now shows a distance-discrepancy flag when the FIT distance differs from the race spec:

• ≥15% (amber) — GPS noise + open-water sighting, or a tight tangent. Usually fine.
• ≥30% (red) — Likely GPS overcount (swim) or watch left running past the line. Action needed.

The flag includes an Edit → link that opens the activity's trim & adjust panel, where you can either trim the over-recorded section or override the distance directly.

When you trim or override on the source activity, the precomputed recap-stat columns are wiped automatically. Reload the recap and every stat (pace, IF, TSS, decoupling, W' burn, CdA) recomputes against the cleaned-up window — same data on the PDF and the race-comparison page since they share the precompute.