404
This route is not part of the ApexSignal pit-wall replay. Head back to the incident inspector.
Back to pit wall404
This route is not part of the ApexSignal pit-wall replay. Head back to the incident inspector.
Back to pit wall404
This route is not part of the ApexSignal pit-wall replay. Head back to the incident inspector.
Back to pit wall404
This route is not part of the ApexSignal pit-wall replay. Head back to the incident inspector.
Back to pit wallProblem Statement 1 · The Silent Co-Driver
ApexSignal transcribes team radio, scores acoustic tone, and checks every driver complaint against the driver’s own telemetry baseline — turning a subjective “rear’s moving” into measured evidence, connected lap-by-lap to what the car actually did.
Session
—
Driver
—
Incidents
—
Mode
connecting
Architecture
Three stages, each independently testable, connected only by the frozen JSON contracts in contracts/.
01
Team radio is transcribed with Whisper ASR and scored for acoustic tone/arousal independently of the words used. Every call becomes a structured record, not a raw clip.
POST /v1/radio/analyze
02
The reported complaint is checked against the driver's own recent laps at that segment, and against prior incidents in memory — never against a population average or a fabricated risk score.
POST /v1/incidents/evaluate
03
One screen: transcript, tone, complaint category, baseline evidence, historical match, and lead time — worded in interpretation-safe language, with an honest null state whenever the evidence isn't there.
GET /v1/incidents/{id}
Fixed complaint taxonomy · five categories, frozen
Circuit context · source geometry
Twenty-five circuit centerlines sampled from an open motorsport geometry database—not invented SVG loops. Twenty-one maps also rotate through complete, source-backed Formula 1 race recaps; map-only venues remain in the atlas when comparable F1 lap-order data does not exist.
25
source centerlines
21 race replays · 1,284 laps
Selected map · AUS
Melbourne, Australia · 5.299 km centerline
Lakeside semi-street loop with fast direction changes.
Geometry derived from TUMFTM/racetrack-database (LGPL-3.0). Historical grid, classification and per-lap order are bundled from the Jolpica/Ergast archive. Between-lap map motion is interpolated for the recap and is not presented as GPS telemetry. Centerline lengths are computed from source coordinates and may differ slightly from official homologated lap distances.
Interactive Replay
The validated replay is connected to the public ApexSignal API — click a pin, read the evidence, toggle Pit Wall View to see what changes.
Incident Inspector
Scope, Stated Honestly
A smaller, honest system beats a larger one that overclaims. Both lists below are enforced in code, not just in copy —test_contract_conformance.py checks the risk-score rule directly.
No lie detection
Tone/arousal is an acoustic model score, labeled as such. Never framed as detecting deception.
No diagnosis
"Reported phenomenon," never "diagnosed fault." ApexSignal never claims a confirmed mechanical cause.
No composite risk score
Every component — semantic similarity, telemetry similarity, tone confidence — stays visible and separate. Nothing gets collapsed into one number.
No recurrence prediction
ApexSignal flags a recurrence only after the driver reports it again by radio. It does not proactively watch telemetry in the background for a repeat before that happens.
Deferred to the roadmap, not this build
Recurrence monitor
A standing background process that watches telemetry independent of radio events was in the original concept. Cut for the MVP — recurrence is only assessed reactively, when a new radio report arrives.
ECHO LAP at scale
The presentation replay uses three contract-validated reference incidents. The same interface (semantic + telemetry similarity, category gate) can scale to a FAISS index over a full-season corpus.
The Mask
text_tone_disagreement (text vs. acoustic tone mismatch) is schema-supported but disabled by default pending real-clip validation gates — see services/radio_ai/VALIDATION_GATES.md.
Field Context
Cross-driver / cross-team context correlation is a roadmap idea from the project charter, intentionally out of scope for a one-driver, one-session MVP.
Materials
Team
AI Race Month · GrandPrix Hackathon @ Paytm · Problem Statement 1: The Silent Co-Driver
Workstream A
Jagrav
Data, telemetry, deterministic replay
Workstream B
Shashwat
Radio & language intelligence — ASR, tone, complaint classification
Workstream C
Tanish
Incident memory, evidence engine, core API
Workstream D
Mohit
Product UI, visualization, deployment
▌ApexSignal by Podium Finish · MIT License · GitHub
Problem Statement 1 · The Silent Co-Driver
ApexSignal transcribes team radio, scores acoustic tone, and checks every driver complaint against the driver’s own telemetry baseline — turning a subjective “rear’s moving” into measured evidence, connected lap-by-lap to what the car actually did.
Session
—
Driver
—
Incidents
—
Mode
connecting
Architecture
Three stages, each independently testable, connected only by the frozen JSON contracts in contracts/.
01
Team radio is transcribed with Whisper ASR and scored for acoustic tone/arousal independently of the words used. Every call becomes a structured record, not a raw clip.
POST /v1/radio/analyze
02
The reported complaint is checked against the driver's own recent laps at that segment, and against prior incidents in memory — never against a population average or a fabricated risk score.
POST /v1/incidents/evaluate
03
One screen: transcript, tone, complaint category, baseline evidence, historical match, and lead time — worded in interpretation-safe language, with an honest null state whenever the evidence isn't there.
GET /v1/incidents/{id}
Fixed complaint taxonomy · five categories, frozen
Tone model · real broadcast audio, real output, not a fixture
Real VoiceCLAP output
Most confidently CALM in the corpus
2024 São Paulo Grand Prix — Lando Norris, real broadcast
“If the weather stays as it does, we think it will be these tyres to the end.”
Most confidently ELEVATED_AROUSAL in the corpus
2018 Abu Dhabi Grand Prix, real broadcast
“These tires are not doing well! Copy”
Two real drivers, two real broadcasts, six years apart — the model wasn’t tuned on either. Same threshold used in production (AROUSAL_ELEVATED_THRESHOLD = 2.565, calibrated on 20 real human-labeled F1 radio clips) decides both. Run it yourself: services/radio_ai/tone_test/run_live_pipeline_demo.py.
Live Pipeline Walkthrough
Five real broadcast clips, fetched live from the API — same data the Pit Wall Console runs. Nothing here is a mockup.
Loading from API…
Circuit context · source geometry
Twenty-five circuit centerlines sampled from an open motorsport geometry database—not invented SVG loops. Twenty-one maps also rotate through complete, source-backed Formula 1 race recaps; map-only venues remain in the atlas when comparable F1 lap-order data does not exist.
25
source centerlines
21 race replays · 1,284 laps
Selected map · AUS
Melbourne, Australia · 5.299 km centerline
Lakeside semi-street loop with fast direction changes.
Geometry derived from TUMFTM/racetrack-database (LGPL-3.0). Historical grid, classification and per-lap order are bundled from the Jolpica/Ergast archive. Between-lap map motion is interpolated for the recap and is not presented as GPS telemetry. Centerline lengths are computed from source coordinates and may differ slightly from official homologated lap distances.
Validated Reference Replay
Loading replay data…
Interactive Replay
The validated replay is connected to the public ApexSignal API — click a pin, read the evidence, toggle Pit Wall View to see what changes.
Incident Inspector
Evidence
Loading evidence…
Human-in-the-Loop
Play a real clip. See the AI’s real call. Confirm it or correct it — the same workflow that grows the classifier’s training data internally.
“A lot of understeer creeping in. All speeds but also traction getting very poor.”
Your call
“Max, so specifically the issue is breaking turn 10 whilst on the curb, just for information.”
Your call
“Okay, copy, just keep the information coming.”
Your call
“Oscar confirming that tyre degradation is all thermal. Not worried about wear, not worried about graining on this tyre.”
Your call
Scope, Stated Honestly
A smaller, honest system beats a larger one that overclaims. Both lists below are enforced in code, not just in copy —test_contract_conformance.py checks the risk-score rule directly.
No lie detection
Tone/arousal is an acoustic model score, labeled as such. Never framed as detecting deception.
No diagnosis
"Reported phenomenon," never "diagnosed fault." ApexSignal never claims a confirmed mechanical cause.
No composite risk score
Every component — semantic similarity, telemetry similarity, tone confidence — stays visible and separate. Nothing gets collapsed into one number.
No recurrence prediction
ApexSignal flags a recurrence only after the driver reports it again by radio. It does not proactively watch telemetry in the background for a repeat before that happens.
Deferred to the roadmap, not this build
Recurrence monitor
A standing background process that watches telemetry independent of radio events was in the original concept. Cut for the MVP — recurrence is only assessed reactively, when a new radio report arrives.
ECHO LAP at scale
The presentation replay uses three contract-validated reference incidents. The same interface (semantic + telemetry similarity, category gate) can scale to a FAISS index over a full-season corpus.
The Mask
text_tone_disagreement (text vs. acoustic tone mismatch) is schema-supported but disabled by default pending real-clip validation gates — see services/radio_ai/VALIDATION_GATES.md.
Field Context
Cross-driver / cross-team context correlation is a roadmap idea from the project charter, intentionally out of scope for a one-driver, one-session MVP.
Materials
Team
AI Race Month · GrandPrix Hackathon @ Paytm · Problem Statement 1: The Silent Co-Driver
Workstream A
Jagrav
Data, telemetry, deterministic replay
Workstream B
Shashwat
Radio & language intelligence — ASR, tone, complaint classification
Workstream C
Tanish
Incident memory, evidence engine, core API
Workstream D
Mohit
Product UI, visualization, deployment
▌ApexSignal by Podium Finish · MIT License · GitHub
▌ApexSignal
Race Engineer Console · REFERENCE_REPLAY_2026
Demo console — any credentials proceed. No backend authentication runs here; this gate exists for the presentation flow, not as a security claim.
For judges & reviewers
No login required. This is the same technical breakdown the team uses to answer engineering questions — what happens at each stage, which model or piece of code does it, and which numbers are measured rather than guessed.
Full Architecture
Not just STT. Four separate hackathon-brainstorm concepts — memory, meaning, evidence, and restraint — merged into one pipeline instead of shipping as four disconnected demos.
A radio call comes in
“Rear is moving again when I get back on throttle.” Raw audio, nothing structured yet.
Speech becomes text
faster-whisper ASR transcribes the call. This alone is what most teams building this brief will ship.
The voice is scored for tone
Calm, elevated/stressed, or fatigued, with a confidence number.
This is the bare-minimum output the hackathon brief actually required. Everything below is where the real product starts.
The complaint is sorted, not diagnosed
One of 5 fixed categories — rear grip, front/braking, tyre wear, visibility/track, other mechanical. Never a fabricated diagnosis, just “this is the kind of thing being reported.”
FEEL2PHYSICS concept: free-form driver language mapped to a frozen, defensible taxonomy — not reduced to a sentiment score, not invented on the fly.
Checked against the driver's own baseline
Not “how a car should behave” in the abstract — this specific driver, this specific session, this specific corner, against their own last 5 laps.
The single biggest differentiator from a generic anomaly detector: no population average, no invented “correct” driving model. A scrappy driver isn't flagged for being themselves.
Memory kicks in
Past incidents are searched for anything that sounds similar and looks similar in telemetry. Two separate scores — sounds alike, looks alike — never mashed into one fake number.
ECHO LAP concept: nothing is judged in isolation. Every new report is checked against everything reported before — real semantic retrieval + real telemetry fingerprinting, gated together, not blended.
Lead time gets measured
Literally: how many seconds passed between the driver's warning and the moment the car's data actually got worse. Reported as null, honestly, when the data doesn't support a number — never forced.
The actual product thesis: the driver is a sensor arriving before the graph does. This number is what proves that, per incident, with real seconds — not a claim, a measurement.
One incident card, not four tabs
Transcript, tone, category, evidence, historical match, lead time, plain-English summary — one screen, one narrative.
RacePulse concept: every claim decomposed into inspectable, separately-labeled components — built to survive a skeptical engineer, or judge, asking “why?”
What actually makes this different
Most teams tackling this brief ship steps 02–03 and call it done — a transcript and a mood badge next to a lap chart. The thesis here is that a single opaque “risk score” is a demo crowd-pleaser and a production liability: a confident number nobody can decompose is what gets a real incident-review committee to switch a system off. Every number in this pipeline traces back to a named piece of evidence, and it says “I don’t know” out loud (INSUFFICIENT_DATA, a null lead time, no match) rather than manufacturing a positive to look impressive. We’re not shipping a smarter transcript — we’re shipping a plug-in layer that sits on top of the telemetry and radio systems a team already runs, and turns them into evidence an engineer would actually trust enough to act on mid-session.
System Design
Every box below is a real, running piece of this system — not a planned architecture. Reproduce any layer directly: model IDs and pinned revisions are in services/radio_ai/app/config.py.
Audio ingest
Speech-to-text
Acoustic tone model
Complaint classifier
Evidence engine (classical, not ML)
Storage
API layer
Frontend
Direct answer: do we use a generative LLM? Tool-calling? MCP?
No, deliberately, on all three. No GPT/Claude/Gemini-style generative model is in this pipeline, no agent framework, no tool-calling loop, no MCP server. Every model above is a small, pinned, task-specific pretrained model (an ASR transcriber, a speech-emotion encoder, a sentence-embedding model) — not a chat model reasoning in free text. That’s a product decision, not a limitation: a generative model summarizing “what happened” can hallucinate a plausible-sounding but wrong diagnosis, and there is no way to audit that after the fact. Every number this system produces instead traces to a named, deterministic computation — a threshold, a cosine similarity, a median — specifically so an engineer (or a judge) can ask “why did it say that” and get a real answer, not a plausible-sounding one.
System design
The diagram is the fast reference for explaining the product out loud or to a driver-facing engineer. The breakdown underneath it is the same workflow with the exact file, function, and parameter behind every box, for anyone who wants to check the code directly.
Visual reference
One audio clip splits into two model paths, merges into a single structured record, runs through four independent evidence checks in parallel, and converges into one verdict. Nothing here is a single black-box score — every arrow is a real function call, mapped out in detail underneath the diagram.
For technical Q&A
What happens, in order, when a radio call comes in — and exactly which file and function does it. Every parameter below is a real, measured value, not a placeholder.
Audio in → Transcription
The driver's radio call (raw audio) is converted into text. This is the “translation” step — speech to words.
model distil-whisper/distil-large-v3.5-ct2 (via faster-whisper)
where in code services/radio_ai/app/asr.py → transcribe()
parameters live in Model ID + pinned version: services/radio_ai/app/config.py → ModelConfig
Tone / Voice Analysis
The raw audio itself (not the words) is scored for how the driver sounds — calm, stressed, or tired.
Fatigue ≥ 1.1 → FATIGUED. Else if Arousal ≥ 2.565 → ELEVATED_AROUSAL. Else → CALM. Low quality/high noise doesn't change the label — it lowers the confidence score instead.
model laion/voiceclap-commercial (encoder + attribute heads)
where in code services/radio_ai/app/tone.py → score_waveform(), map_to_label()
parameters live in services/radio_ai/app/config.py → ToneThresholds class — Arousal threshold 2.565, Fatigue threshold 1.1
Complaint Category
The transcribed words are matched against 5 fixed problem categories — sorted, not diagnosed.
model sentence-transformers/all-MiniLM-L6-v2 (embedding + prototype similarity)
where in code services/radio_ai/app/complaint_classifier.py → classify()
parameters live in services/radio_ai/app/config.py → ClassifierConfig class — 5 category descriptions + similarity margin 0.16
Evidence Engine — the solution being generated
This is where the actual answer gets built: is the car really behaving differently, has this happened before, and how much warning did the call give. Plain statistics, not a model.
where in code services/evidence_memory/
Final Output → Incident Assessment
Everything above is combined into one verdict — sent to the dashboard as a single JSON record, never a raw score.
where in code services/core_api/app/pipeline.py → evaluate_incident()
parameters live in Served over HTTP by services/core_api/app/main.py → /v1/incidents/{id}