Andretti Racing
RaceOS real-time car performance application
Palantir
Motorsport
Typical Forward Deployed model
Standard case | Useful reference with remaining gaps
Evidence level A
In production
A
Evidence level
Andretti Racing: RaceOS real-time car performance application
Evidence level measures whether a source can be located and reviewed; it does not mean vendor-reported claims were independently audited.
Standard case | Useful reference with remaining gaps
8 / 12
Business context1 / 2
Transformation workflow1 / 2
Technical workflow2 / 2
Human roles & governance1 / 2
Measured outcomes1 / 2
Source traceability2 / 2
Remaining gaps: Business context, Transformation workflow, Human roles & governance, Measured outcomes
Business problem
Track decision-making relies on telemetry, tactics and historical energy data for real-time racing vehicles and requires the rapid transformation of multiple analyses into operational applications.
Solution
Andretti constructed RaceOS on the Palantir structure, connecting real-time vehicle performance to a series of AI-driven applications.
Technical architecture & production workflow
Step 01
Equipment/quality/process/maintenance/supply chain/historical events
→
Step 02
Foundry integrates real-time and historical industry data
→
Step 03
Establishment of equipment, spare parts, orders, processes and constraints
→
Step 04
AIP/project/optimal identification of risks and recommended actions
→
Step 05
Engineer/field personnel confirm and operate
→
Step 06
Implementation results and failure feedback deposition as follow-up model and rule context
Key technology & infrastructure components
FoundryAIPOntologyReal-time telemetryRaceOS application
Human roles & accountability
Game engineering and strategy teams are responsible for final track action.
FDE delivery actions
- Run a full process with the first-line team to identify nodes that really require decision-making rather than displaying data
- Collapse decentralized data sources, competencies and business terms into a single, operational Ontology
- Combine business rules, optimization models, LLM and traditional software according to a reliable boundary, instead of letting the LLM operate
- Insert recommendations directly into existing operating workstations and design approvals, rejections, upgrades and write back to Action
- Continue to modify Ontology, rules and automation with operational KPI acceptance and feedback
Reusable delivery patterns
- Let's be clear about the client, the relationship, the state and the action, and then talk about Agent.
- The recommendation must enter the executable stream, otherwise it's just another dashboard.
- High-value deployment is often a combination of data integration + rules/ optimization + AI + Human-in-the-lop
- Continuous rewriting of the results of implementation to build cumulative operational memory
Business outcomes & delivery results
The Palantir structure document lists RaceOS as a representative case of the extended client standard AIP/Foundry architecture; no unified ROI is disclosed.
Evidence boundaries & verification notes
- The Palantir official structure document clearly named Andretti RaceOS and its connection to real-time racing performance with AI applications; limited disclosure of technical details.
- The source can be directly located in the case; the value remains disclosed by the source and does not represent an independent audit.