F1 RaceGuard AI

An AI safety agent that detects corrupted race telemetry, switches to a trusted backup, and uses DataHub lineage to trace downstream impact.

Comment

F1 RaceGuard AI

Inspiration

Modern race strategy systems depend on a continuous stream of telemetry. A single missing, corrupted, stale, or invalid sensor value can propagate through data pipelines and affect feature calculations, predictive models, and strategic decisions.

We were inspired by a simple question:

What should happen when a race strategy system can no longer trust its telemetry?

Instead of allowing questionable data to reach downstream components, we built F1 RaceGuard AI as a safety layer between telemetry sources and the strategy system. It validates incoming data, selects a reliable source, blocks unsafe inputs when necessary, and uses DataHub metadata to explain which downstream components may be affected.

What it does

RaceGuard receives telemetry from primary and backup sources and produces one of three safety decisions:

  • PRIMARY — the primary telemetry is valid and can be used;
  • BACKUP — the primary source is invalid, but the backup source is valid;
  • BLOCKED — neither source is reliable, so the strategy input is blocked.

When RaceGuard selects BACKUP or BLOCKED, it automatically:

  1. starts an impact analysis;
  2. queries downstream lineage through the official DataHub MCP Server;
  3. identifies affected data components;
  4. creates an active Incident in DataHub;
  5. records an explanation of the telemetry failure and its downstream impact.

For example:

Invalid primary telemetry
        ↓
BACKUP selected
        ↓
DataHub MCP lineage analysis
        ↓
Affected component identified
        ↓
DataHub Incident created automatically

This turns an isolated sensor error into a visible, traceable, and actionable metadata event.

How we built it

We built RaceGuard as a modular Python application.

The telemetry validator checks:

  • required fields;
  • missing values;
  • invalid data types;
  • NaN and infinite values;
  • stale timestamps;
  • configurable numeric limits.

The fallback manager combines the validation results from both telemetry sources and selects PRIMARY, BACKUP, or BLOCKED. It also produces structured reasons explaining the decision.

A FastAPI service exposes the system through:

POST /telemetry/evaluate

DataHub represents the project’s metadata graph:

primary_tyre_sensor ──┐
                      ├──> raw_telemetry
backup_tyre_sensor ───┘
                             ↓
                    validated_telemetry
                             ↓
                    strategy_features
                             ↓
                      pit_stop_model
                             ↓
                  race_strategy_output

For metadata-aware impact analysis, RaceGuard launches the official DataHub MCP Server and calls its lineage tools. If the MCP Server is unavailable, the project can fall back to a direct DataHub GraphQL query.

After resolving the affected components, RaceGuard uses DataHub’s GraphQL API to create a real Incident linked to the failed telemetry source.

We also created automated tests for the three principal scenarios:

  • valid primary telemetry;
  • invalid primary telemetry with a valid backup;
  • invalid primary and backup telemetry.

Challenges we faced

One of the main challenges was integrating several independently working components into a single reliable flow.

Telemetry validation and source selection were straightforward in isolation, but the complete system also had to query lineage, interpret the returned entity URNs, create an Incident, and still return a valid API response.

Another challenge was working with MCP. We needed to launch the DataHub MCP Server over stdio, discover its available tools, call the correct lineage operation, process its response, and handle situations in which the server could not be reached.

We also discovered that lineage depth matters. An initial MCP request returned the immediate downstream component, such as raw_telemetry, rather than automatically expanding the entire dependency graph. This taught us to distinguish direct impact from transitive impact and to describe the demonstrated result accurately.

Finally, we had to make the failure workflow observable. A fallback decision alone was not enough: judges and engineers needed evidence showing why the decision occurred, which metadata entities were affected, and whether an Incident was successfully created.

What we learned

We learned that reliable AI and ML systems depend on more than model accuracy. They also need:

  • trustworthy input data;
  • explicit safety rules;
  • metadata and lineage awareness;
  • explainable fallback decisions;
  • observable incident handling;
  • graceful behavior when external services are unavailable.

We also learned how DataHub can serve as an operational part of an application rather than only as a passive metadata catalog. Through MCP and GraphQL, RaceGuard uses metadata during runtime to understand the context and potential impact of a failure.

Most importantly, we learned that safe automation should know when to continue, when to switch to a backup, and when to stop.

Accomplishments that we are proud of

We are proud that the final prototype demonstrates a complete working cycle:

Telemetry failure
→ validation
→ safe fallback decision
→ DataHub MCP lineage analysis
→ downstream impact identification
→ automatic DataHub Incident

The DataHub Incident is created automatically, linked to the relevant telemetry source, and contains the affected downstream component in its description.

The project therefore goes beyond detecting invalid values: it connects runtime safety decisions with metadata-aware impact analysis and incident management.

What’s next

The next version of RaceGuard could include:

  • full transitive lineage analysis across all downstream levels;
  • real-time telemetry ingestion through Kafka or another streaming platform;
  • configurable validation profiles for different vehicles and sensors;
  • anomaly detection based on historical telemetry;
  • confidence scores for primary and backup sources;
  • duplicate-incident suppression and automatic resolution;
  • a visual race-control dashboard;
  • notifications through Slack, email, or operational alerting systems.

Our long-term goal is to make RaceGuard a reusable safety and observability layer for any system that depends on high-frequency sensor data—not only motorsport, but also robotics, manufacturing, autonomous systems, and aerospace.

Built With

Share this project:

Updates