> ## Documentation Index
> Fetch the complete documentation index at: https://playbook.smedleygroup.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Predicted Podium

> The strategy engine's predicted top three at the chequered flag, in team colours.

## Overview

Predicted Podium shows the top three of the Race Strategy Tool's predicted finishing order: position, three-letter code and team colour, and nothing else.

It is the thinnest widget in the Strategy suite on purpose. It shares one ordering with [Predicted Pylon](/software/internal/watchparty/strategy/predicted-pylon) rather than deriving its own, so the two can never disagree about who wins.

> [!NOTE]
>
> This is the engine's prediction for the **end of the race**, not the current order. For who is where right now, use the [Timing Tower](/software/internal/watchparty/widgets/timing-tower).

***

## What It Shows

![The predicted podium as of lap 43 of 57 (Madrid 2026)](https://mintcdn.com/smedley_group/4HA54IXVT1XyKj8C/images/watchparty/predicted-podium.png?fit=max\&auto=format\&n=4HA54IXVT1XyKj8C\&q=85\&s=31ea6d7898a658d4d598b3f996cbc256)

A header caption reads the finish lap and the lap the prediction is as of, for example "Predicted podium (lap 57), as of lap 43". Beneath it, three rows: a team-coloured bar, the position 1 to 3, and the driver's code.

Positions are renumbered 1 to 3 off the filtered order rather than reusing the pylon's own position numbers. That way a retired driver above the podium cannot leave a gap in the places shown. Drivers marked out of the race are excluded before the top three are taken.

A driver whose roster colour is missing or malformed gets a neutral bar rather than an invented colour.

There are no interactions: it is a read-only view, like the other Strategy data widgets.

***

## Data Behind It

`screens/strategyDerive.ts`'s `buildPredictedPodium` takes the already-derived Predicted Pylon ordering, drops anyone flagged out, and keeps the first three. It reads the `strategy_snapshot` at or before the playhead lap, the same as-of rule the rest of the suite follows.

Sharing the pylon's ordering is the design, not an implementation shortcut. A podium computed separately could disagree with the pylon on the same screen, which would be worse than showing no podium at all.

***

## States

| State | Behaviour |
| - | - |
| No strategy snapshot at or before this lap | The suite's shared empty text |
| A snapshot with no predicted laps | "No predicted laps in this snapshot" |
| Fewer than three drivers predicted to finish | Only the rows that exist; never padded |
| Session is not a race | "Session is not a race." notice |
| Live vs replay | Identical rendering |

***

## FAQ

> **Why does this show a different top three from the timing tower?**
>
> The tower is the order right now. This is where the engine thinks the race finishes, after the stops still to come.

> **Could it disagree with Predicted Pylon?**
>
> No. It is the first three of that same ordering, so if they ever differed it would be a defect rather than a difference of method.

> **Why is a driver missing from the podium who is currently in the top three?**
>
> They are flagged out of the race in the snapshot, so they are dropped before the top three are taken and the remaining places are renumbered.

***

## Next Steps

> **[Predicted Pylon](/software/internal/watchparty/strategy/predicted-pylon)**
>
> The full predicted order this podium is the top of.

> **[Strategy Status](/software/internal/watchparty/strategy/status)**
>
> Whether the snapshot behind it is healthy at this lap.

> **[Predicted Race History](/software/internal/watchparty/strategy/predicted-race-history)**
>
> How the engine expects the gaps to develop.

> **[Strategy Table](/software/internal/watchparty/strategy/table)**
>
> The stop plans behind the prediction.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.