A Daily F1 Race-Winner Prediction Engine with Confidence-Gated Alerts

A 38-node n8n pipeline that predicts F1 race winners daily — fusing live data, eight driver metrics, RAG over race history, and GPT-4o — with confidence-gated Slack alerts.

38

workflow nodes
Deployment:

Self-Hosted

THE BRIEF

What the system needed to do.

This project is a 38-node n8n workflow that predicts the winner of each upcoming Formula 1 race, refreshed daily. It pulls live standings, qualifying, historical results, and circuit data from the Ergast F1 API, then computes eight advanced driver-performance metrics. Three years of history are vectorized with OpenAI embeddings so a GPT-4o LangChain agent can semantically retrieve similar past races, alongside live news, weather, and statistical-analysis tools. The agent outputs a winner, confidence score, top three, and key risk factors. Only predictions above a configurable confidence threshold trigger a Slack alert and are stored in PostgreSQL and Google Sheets.

The scope

Automatically predict each upcoming F1 race winner daily, blending live standings, historical patterns, and AI, with confidence-gated Slack alerts.

DESIGN CHOICES

What makes the build interesting.

F1 fans & sports analysts

Eight engineered driver-performance metrics

RAG over three years of race history

Confidence-gated alerting

THE ARCHITECTURE

Follow the flow.

  1. Scheduled trigger & configuration — a daily 8 AM trigger fires; a config node centralises the API base URL, season, news/weather endpoints, history depth, and confidence threshold.
  2. Multi-source data collection — fetch current season, driver and constructor standings, historical results, qualifying, and circuit info from the Ergast F1 API.
  3. Merge & feature engineering — unify the data and compute eight advanced driver-performance metrics.
  4. Historical vectorization — load, chunk, and embed three years of history into an in-memory vector store for semantic retrieval.
  5. AI prediction — a GPT-4o LangChain agent uses RAG retrieval, news, weather, and statistical tools to output a winner, confidence, top three, key and risk factors, and weather impact.
  6. Confidence validation — an IF node passes only predictions at or above the threshold (default 0.75).
  7. Alert & store — high-confidence predictions trigger a Slack alert and are saved to PostgreSQL and a Google Sheets tracker.

Tools and platforms

  • n8n — workflow orchestration (38 nodes, self-hosted)
  • Ergast F1 API — live and historical F1 data (standings, qualifying, results, circuits)
  • OpenAI GPT-4o (via LangChain agent) — race analysis and prediction
  • OpenAI Embeddings — vectorizing historical data for semantic search
  • In-memory vector store — RAG knowledge base of past races
  • Real-time news API — current F1 team and driver developments (configurable endpoint)
  • Weather API — race-day forecast input (configurable endpoint)
  • Statistical-analysis code tool — in-agent quantitative calculations
  • PostgreSQL — structured prediction storage
  • Google Sheets — human-readable prediction tracker
  • Slack — high-confidence alerts (swappable for Discord/Teams)
  • Schedule Trigger — daily automated runs

What the design enables.

  • Eliminates manual data wrangling — automatically collects and merges live standings, qualifying, historical results, circuit info, news, and weather from multiple sources every day with zero human effort.
  • More accurate, evidence-backed forecasts — combining engineered metrics, historical precedent via RAG, and multi-tool AI reasoning produces predictions grounded in specific statistics rather than intuition.
  • Portable and extensible by design — a single configuration node controls season, data sources, history depth, and threshold, and the system extends easily to constructor predictions or Discord/Teams alerts.

The difficult parts.

  • Raw standings don't predict winners. Championship position alone misses the real signal. We engineered eight derived metrics — including consistency, recent form, and DNF rate — so the model reasons over true performance patterns rather than a static table.
  • Giving the AI real historical context. Surface-level lookups can't find analogous races. We built a vectorization pipeline (chunk, embed, index three years of data) so the agent semantically retrieves genuinely similar past scenarios to ground each prediction.
  • Avoiding a flood of unreliable alerts. Treating every forecast as equal creates noise and erodes trust. We added a configurable confidence gate so only predictions clearing the threshold reach Slack and storage, keeping the signal clean.

Build notes and context.

The brief: a self-updating F1 analyst that only speaks up when it's confident.

The goal was a fully automated system that predicts the winner of each upcoming Formula 1 race — not with a gut feeling, but with a data-driven, statistically grounded forecast refreshed every single day. Crucially, it had to know when not to shout: only high-confidence predictions should trigger alerts, so the signal never drowns in noise. We delivered this as a 38-node n8n workflow combining live data ingestion, statistical feature engineering, retrieval-augmented AI reasoning, and a confidence gate.

Stage 1 — Multi-source data collection. A schedule trigger fires daily at 8 AM and a configuration node centralises every tunable parameter — the F1 API base URL, current season, news and weather endpoints, how many years of history to use, and the confidence threshold. The workflow then pulls a rich, multi-source dataset from the Ergast F1 API (no auth required): current season schedule, driver standings, constructor standings, historical race results, qualifying results, and circuit information. Fresh, layered data matters here — standings reveal momentum while historical circuit results expose recurring performance patterns.

Stage 2 — Feature engineering. Raw standings are merged into a unified dataset, and a code node computes eight advanced driver-performance metrics — including podium rate, win rate, consistency score, recent form, DNF (reliability) rate, points per race, and average qualifying and finishing positions. This is the heart of the analytical edge: these derived metrics surface the patterns that a championship table alone simply cannot show.

Stage 3 — Historical vectorization (RAG). Three years of F1 historical data are transformed into a searchable knowledge base. A document loader ingests the raw history, a recursive text splitter chunks it into contextual units, OpenAI embeddings vectorize those chunks, and they're stored in an in-memory vector store. This lets the AI perform semantic search over the past — finding genuinely similar race scenarios (comparable circuits, conditions, or standings situations) rather than relying on surface-level lookups.

Stage 4 — AI prediction. A LangChain agent powered by GPT-4o acts as an expert race analyst. It's equipped with four tools: the historical-data retrieval tool (RAG over the vector store), a real-time F1 news tool, a weather-forecast tool, and a statistical-analysis code tool. The agent analyses the current-season data and actively uses all four tools to gather context, then outputs a structured prediction: the predicted winner, a confidence score from 0 to 1, the top-three predicted finishers, a minimum of five key factors, risk factors, and a weather-impact assessment — with instructions to cite specific historical statistics rather than guess.

Stage 5 — Confidence gating. Every prediction passes through an IF node that compares its confidence score against a configurable threshold (0.75 by default). Only predictions at or above the bar proceed to alerting and storage. This single gate is what keeps the system trustworthy — it deliberately suppresses weak forecasts to reduce alert fatigue and ensure only reliable insights are ever acted upon.

Stage 6 — Alerting and record-keeping. When a prediction clears the threshold, the system pushes a high-confidence alert to Slack and persists the full analysis in two places: a PostgreSQL table (with a defined schema covering prediction date, predicted winner, confidence score, source, data version, and the complete analysis) and a Google Sheets prediction tracker. The dual store gives both a robust queryable database and a human-friendly log for reviewing accuracy over time.

Why this design works. It mirrors how a serious analyst actually works — gather everything, engineer the metrics that matter, compare against history, reason over it, and only commit to a call when the evidence supports it. The configuration node makes the whole pipeline portable (swap the season, sources, history depth, or threshold without touching logic), the RAG layer grounds predictions in real precedent, and the confidence gate enforces discipline. It's also easily extensible: constructor predictions can be added by adjusting the agent prompt, and Slack can be swapped for Discord or Teams. The result is a hands-off engine well-suited to sports-analytics dashboards, fantasy F1 leagues, and F1 news or prediction sites — delivering a fresh, statistically grounded race forecast every day, but only raising its hand when it's genuinely confident.

Have a related process in mind?

Tell me what goes in, what should come out and where the current process gets stuck.