What the Bronze layer is
The Bronze layer stores data exactly as returned by the upstream APIs, with no transformations applied. No type coercions, no deduplication, no nullability enforcement beyond what FastF1 itself provides. This makes Bronze the source of truth for auditing pipeline results if a Silver model produces an unexpected value, you trace it back to the Bronze row. All four datasets are stored under a common partition grammar:
Always include
season in your query predicate. The partition pruner uses it to skip entire years; omitting it triggers a full scan across all 168 races.
Coverage
The pipeline covers 168 races across 2018–2024, with one known gap:Telemetry data for 2018 Rd1 and Rd2 is missing. FastF1’s livetiming feed started mid-season in 2018, so no position or channel data was recorded for the Australian and Bahraini rounds. Laps, weather, and race control for those rounds are present. Telemetry coverage is complete from 2018 Rd3 onward.
Laps
The laps dataset is the backbone of every decomposition. Each row represents one lap completed by one driver. A typical race produces 1,000–1,400 rows; a full-grid 70-lap race reaches ~1,400 rows at 20 drivers. File pattern:bronze/laps/season=YYYY/race=<slug>/YYYY_<slug>_laps.parquet
Example: 2024 Bahrain Grand Prix 23 drivers × 57 laps = ~1,311 rows
LapTime, Sector1Time, Sector2Time, and Sector3Time are stored as nanoseconds (int64) in Parquet. Convert to seconds with / 1000000000.0.Key fields
Full column list
The table above covers the fields most commonly used in decomposition queries. The full schema also includes speed trap columns (SpeedI1, SpeedI2, SpeedFL, SpeedST), sector session-time columns used for air-gap joins (Sector1SessionTime, Sector2SessionTime, Sector3SessionTime), and housekeeping flags (FastF1Generated, IsPersonalBest, LapStartTime, PitInTime, PitOutTime). These are documented in their complete form in the JSON schema at ingestion/schemas/laps.schema.json.
Weather
The weather dataset provides session-level atmospheric observations sampled approximately once per minute. You use it to identify rain laps (excluded from the clean lap filter), to compute the track temperature deviation that feeds the ambient component, and to flag high-humidity sessions where tyre behaviour deviates from dry-weather models. File pattern:bronze/weather/season=YYYY/race=<slug>/weather.parquet
Example: 2024 Bahrain Grand Prix race day ~300 samples
Key fields
Telemetry
The telemetry dataset is the largest by volume. Each row is one ~10 Hz sample from one car speed, throttle, brake, gear, DRS state, and 3D position. A single race produces 2–5 million rows, so you should always predicate on bothseason and race_id before querying.
File pattern: bronze/telemetry/season=YYYY/race=<slug>/session=<Q|R>/telemetry.parquet
Example: 2024 Bahrain Grand Prix 23 drivers × 57 laps × ~300 samples/lap ≈ 3.9M rows
Key fields
The 3D position channels (
x_m, y_m, z_m) are available in the raw FastF1 output for circuit mapping and overtake detection, but are not stored in the Bronze Parquet files by default they are derived on demand during pipeline processing.
Race Control
The race control dataset captures every message broadcast by race control during a session flag states, safety car deployments, incidents, penalties, and procedural messages. The pipeline uses it to identify laps that must be excluded from the clean lap filter and to mark safety car and VSC windows for downstream models. File pattern:bronze/race_control/season=YYYY/race=<slug>/race_control.parquet
Example: 2024 Bahrain Grand Prix ~120 messages
session_time_s is null for all 2024 races due to the same FastF1 v3.8.3 regression that affects the telemetry schema. For 2024 data, use the time column (HH:MM:SS format) or join to laps via lap number. The message field is free-form text use regex or fuzzy matching to classify message types rather than exact-string comparison.