id: 6d1dc9a77b874fe2b8c14fc0ed3296b6 parent_id: e30b38725fe8497696cf42e01e584b4b item_type: 1 item_id: 6c0dcb2a567348fd9796f50c790082e4 item_updated_time: 1780731024662 title_diff: "[]" body_diff: "[{\"diffs\":[[0,\"alysis (\"],[1,\"boundary extraction with \"],[0,\"spline-a\"]],\"start1\":7374,\"start2\":7374,\"length1\":16,\"length2\":41},{\"diffs\":[[0,\"r line)\\\n\"],[-1,\"\"],[0,\" - [x] \"]],\"start1\":7445,\"start2\":7445,\"length1\":16,\"length2\":16},{\"diffs\":[[0,\"D-based \"],[1,\"session \"],[0,\"director\"]],\"start1\":15069,\"start2\":15069,\"length1\":16,\"length2\":24},{\"diffs\":[[0,\"upshift \"],[-1,\"event \"],[0,\"detectio\"]],\"start1\":15658,\"start2\":15658,\"length1\":22,\"length2\":16},{\"diffs\":[[0,\"--\\\n\\\n\"],[-1,\"*Last updated: 2026-06-06 — racecraft v0.1.2: shifting analysis chart renames; planned §1.9: feed merging + run deletion*\\\n*Next: implement §1.9 (feed merging, run deletion, session reopen), add session/analysis/ring-buffer tests, verify with live AC session, verify PCARS with live game, workspace refactor\"],[1,\"## 16. Product Roadmap — From Tool to Product\\\n\\\n> **Analysis date: 2026-06-06**\\\n> **Context: What it would take to turn rusty-telemetry + racecraft into a sellable product or service, for sim racing and potentially real racing.**\\\n\\\n---\\\n\\\n### 16.1 Current State Assessment\\\n\\\n**What we have (v0.5.0):**\\\n- A robust Rust backend that captures 60 Hz telemetry from Assetto Corsa (via Telemetry Tool on port 10101), with parsers for KSUDP and PCARS 1/2\\\n- A unified `TelemetryFrame` data model across all game protocols\\\n- A REST API with recording management, session management, and basic analysis (shift points, track maps)\\\n- A Vue 3 web frontend (racecraft) with dashboard, live feeds, session management, and shifting analysis charts\\\n- Ring buffer architecture with JSONL persistence\\\n- Remote operation support (game and analysis machine can be separate)\\\n- Multi-game protocol support (AC, PCARS 1/2), though only AC verified with live sessions\\\n\\\n**What we DON'T have yet:**\\\n- No user authentication or multi-user support\\\n- No cloud deployment — runs locally only\\\n- No real-time WebSocket streaming to the frontend (polling `/api/live` only)\\\n- No AI-driven coaching or automated insights\\\n- No reference lap comparison (the \\\"Track Titan killer\\\" feature)\\\n- No community features (leaderboards, lap sharing, setup sharing)\\\n- No rally game support despite rally being mentioned in the training roadmap\\\n- No mobile companion app\\\n- No real-world telemetry integration (CAN bus, OBD-II, GPS data)\\\n\\\n---\\\n\\\n### 16.2 Competitive Landscape Analysis\\\n\\\n#### Tier 1: Direct Sim Racing Telemetry Competitors\\\n\\\n| Product | Games | Pricing | Key Features | Users | Backing |\\\n|---|---|---|---|---|---|\\\n| **Track Titan** | AC, ACC, F1, iRacing, AMS2, LMU, Forza | Freemium (free + paid tiers) | AI Coaching Flows, auto-setup download, F1 real lap analysis, community news | 285K+ members, 100M+ laps | Porsche Ventures, Axel Springer, Antler, former F1/WRC execs |\\\n| **SimRacingSetup** | F1 25/26 only (more planned) | Free + £4.99/mo telemetry + £99.99/yr Pro | Pro lap comparison, ERS/tyre maps, career tracking, leaderboards, web-based (no app) | 15K+ customers | Bootstrapped |\\\n| **VRS (Virtual Racing School)** | iRacing | Subscription | Telemetry analysis, coaching, data packs, setup optimization | ~50K iRacing-focused | Bootstrapped, iRacing-ecosystem |\\\n\\\n#### Tier 2: General Data Analysis Tools Used in Sim Racing\\\n\\\n| Product | Type | Pricing | Notes |\\\n|---|---|---|---|\\\n| **MoTeC i2** | Professional data analysis software | License-based (expensive) | The industry standard for real motorsport. Sim racers use it via exported data. Extremely powerful but steep learning curve. |\\\n| **ATLAS (McLaren Applied)** | F1-grade telemetry system | Enterprise / F1-only | Multi-million dollar per season. Not available to consumers. |\\\n| **Cosworth Toolbox** | Real racing data analysis | License-based | Used in WEC, IndyCar, Touring Cars |\\\n| **Dell/AMD F1 partnership** | Real-time F1 telemetry | Not for sale | F1 teams use bespoke systems built on Dell servers + AMD GPUs |\\\n\\\n#### Tier 3: Community & Content Platforms\\\n\\\n| Product | Role | Rally Coverage | Notes |\\\n|---|---|---|---|\\\n| **OverTake.gg** (formerly RaceDepartment) | Sim racing community hub, news, forums, mods | Has WRC, AC Rally categories; partnered with Track Titan for coaching benefits | The Track Titan × OverTake collaboration is exactly what the user asked about — OverTake integrates Track Titan's coaching & setup tools as a \\\"Community Benefit\\\" |\\\n| **Race Sim Studio** | Car mods for AC/AMS2 | Limited | No telemetry |\\\n| **SimulatorController** | AI driving coach, race engineer, spotter | Supports AC, ACC, RRE, PCARS, AMS2, RF2, LMU | Open-source, runs locally. Has telemetry integration but focused on AI voice coaching, not data analysis. |\\\n\\\n---\\\n\\\n### 16.3 The Track Titan × OverTake Model\\\n\\\nTrack Titan's collaboration with OverTake.gg (formerly RaceDepartment, the largest sim racing community with 2M+ registered users) is the case study for how to build a product in this space:\\\n\\\n**The Model:**\\\n1. **Track Titan** builds the telemetry + coaching technology (SaaS product)\\\n2. **OverTake.gg** provides the community, content, and distribution channel\\\n3. OverTake integrates Track Titan as a \\\"Community Benefit\\\" — coaching & setups for OverTake members\\\n4. Track Titan gains user acquisition through OverTake's massive audience\\\n5. Both parties monetize: Track Titan through subscriptions, OverTake through premium memberships\\\n\\\n**Why it works:**\\\n- Track Titan doesn't need to build a community from scratch\\\n- OverTake doesn't need to build telemetry technology\\\n- The sim racing market is fragmented across many games — a platform approach works better than a single-game tool\\\n- Freemium model (free basic telemetry, paid AI coaching/setups) lowers barrier to entry\\\n\\\n**Key lesson for us:** Distribution and community matter as much as technology. Track Titan has Porsche Ventures and former WRC/F1 executives as investors — they understand that the go-to-market is about partnerships and network effects, not just having better algorithms.\\\n\\\n---\\\n\\\n### 16.4 Rally Telemetry — The Underserved Market\\\n\\\n**Does anything like Track Titan exist for rally games?**\\\n\\\n**No.** This is a significant gap in the market. Here's what currently exists:\\\n\\\n| Tool | Rally Support | Limitation |\\\n|---|---|---|\\\n| Track Titan | None | Circuit racing only — no rally stages, pacenotes, or stage-based analysis |\\\n| SimRacingSetup | None | F1-focused |\\\n| VRS | None | iRacing circuit only |\\\n| MoTeC i2 | Can import rally data if exported | Requires manual data export, no direct game integration, no rally-specific analysis |\\\n| Dirt Rally 2.0 built-in | Basic stage times | No telemetry overlays, no coaching, no lap comparison |\\\n| Richard Burns Rally community tools | NGP plugin, some data export | Fragmented, technical, not user-friendly |\\\n| EA Sports WRC | Basic stage recap | No telemetry export API, no third-party analysis |\\\n\\\n**Why rally is different from circuit racing:**\\\n\\\n| Aspect | Circuit Racing | Rally |\\\n|---|---|---|\\\n| Track | Static, memorizable | Dynamic, pacenote-dependent |\\\n| Surface | Uniform (asphalt/curbs) | Mixed (gravel, tarmac, snow, ice, mud) |\\\n| Analysis unit | Lap time | Stage time (no repeated laps on same surface) |\\\n| Key metric | Consistency across laps | Commitment to pacenotes, surface adaptation |\\\n| Coaching focus | Braking points, racing line, throttle application | Pacenote accuracy, weight transfer on loose surfaces, car setup for mixed conditions |\\\n| Comparison | Lap overlay against reference lap | Split-time comparison against other drivers on same stage |\\\n| Data richness | Very high (60 Hz all channels) | Variable — depends on game's UDP output |\\\n\\\n**Assetto Corsa Rally** (the new rally expansion for AC, covered on OverTake.gg) changes the game because:\\\n- AC already has rich telemetry output (our 10101 port works)\\\n- AC Rally runs on the same engine → same parsers apply\\\n- The rally modding community is massive\\\n- Combined circuit + rally telemetry analysis from the SAME platform is novel\\\n\\\n**This is a genuine differentiator.** No other telemetry platform offers both circuit AND rally coaching in one tool.\\\n\\\n---\\\n\\\n### 16.5 Real-World Racing Telemetry — Do Real Teams Use This?\\\n\\\n**Yes, extensively.** Telemetry is fundamental to professional motorsport at every level:\\\n\\\n#### Track Racing (Circuit)\\\n\\\n| Category | Telemetry System | What They Analyze | Cost Level |\\\n|---|---|---|---|\\\n| **Formula 1** | McLaren ATLAS, bespoke systems | Everything: tyre temps, brake bias, engine maps, aero balance, driver inputs, fuel flow, ERS deployment | $1M+/season |\\\n| **WEC / Le Mans** | MoTeC, Cosworth, Magnetti Marelli | Tyre degradation over stints, fuel strategy, driver consistency, traffic management | $50K–500K/season |\\\n| **GT3 / IMSA** | MoTeC, AIM, Bosch | Suspension loads, brake temperatures, tyre pressures, driver inputs | $10K–100K/season |\\\n| **Touring Cars** | MoTeC, Stack, Race Technology | Engine mapping, chassis setup, driver technique | $5K–50K/season |\\\n| **Club / Amateur** | Garmin Catalyst, RaceLogic VBOX, TrackAddict | GPS lines, lap times, basic G-forces, video overlay | $500–5,000 |\\\n\\\n#### Rally (WRC and National Level)\\\n\\\n| Category | Telemetry System | What They Analyze | Notes |\\\n|---|---|---|---|\\\n| **WRC (factory teams)** | Bespoke systems (Hyundai, Toyota, M-Sport each have proprietary setups) | Damper data, suspension travel, split times, surface grip estimation, pacenote timing correlation, turbo boost, differential mapping | WRC cars have ~200 sensor channels. Data is transmitted in real-time back to service park via satellite/4G. |\\\n| **WRC2 / WRC3** | MoTeC, SRA (Stage Rally Analysis) | Stage times, suspension, driver inputs | More budget-constrained, still sophisticated |\\\n| **National Rally** | Various (RaceLogic VBOX, basic data loggers) | GPS tracks, stage times, basic G-forces | Growing adoption as costs decrease |\\\n| **Rallycross** | MoTeC, AIM | Launch data, suspension, tyre management for multi-lap format | Hybrid/EV rallycross adds energy management |\\\n\\\n**Key insight for product strategy:** Real racing teams already have expensive, purpose-built telemetry systems. The market gap is NOT in selling to F1 teams — it's in democratizing professional-grade analysis for:\\\n1. **Sim racers** who want to improve (Track Titan's 285K users prove this market exists)\\\n2. **Club/amateur real racers** who can't afford MoTeC-level systems ($500–5K budget)\\\n3. **Rally drivers at national level** who have NO accessible telemetry platform\\\n4. **Sim-to-real pipeline** — drivers who train in sims and want consistent analysis across both\\\n\\\n---\\\n\\\n### 16.6 Product Roadmap — From v0.5.0 to Sellable Product\\\n\\\n#### Phase A: Complete the Core (Months 1–3)\\\n\\\n**Goal:** Make the existing tool genuinely useful for personal use, then shareable.\\\n\\\n| Milestone | Tasks | Success Metric |\\\n|---|---|---|\\\n| **A1: Verify with live sessions** | Test KSUDP + PCARS with real game sessions; fix any issues | All 3 feeds working reliably with live gameplay |\\\n| **A2: §1.9 implementation** | Feed merging, run deletion, session reopen | Multi-feed analysis working end-to-end |\\\n| **A3: WebSocket streaming** | Replace REST polling with real-time WS for live telemetry | <50ms latency from game → browser |\\\n| **A4: Lap detection** | Auto-detect laps from spline position crossing start/finish | Automatic lap segmentation without manual marking |\\\n| **A5: Reference lap overlay** | Allow loading a \\\"reference\\\" lap and overlaying current lap against it | Visual overlay of two laps with delta trace |\\\n| **A6: Tyre analysis** | Tyre temperature heat maps, tyre wear projection over stint | Graphs showing tyre degradation curves |\\\n| **A7: Brake analysis** | Brake pressure traces, braking point consistency scoring | Per-corner braking analysis with consistency rating |\\\n\\\n#### Phase B: Multi-Game & Rally Support (Months 4–6)\\\n\\\n**Goal:** Expand beyond AC to cover the sim racing ecosystem.\\\n\\\n| Milestone | Tasks | Success Metric |\\\n|---|---|---|\\\n| **B1: ACC support** | ACC UDP telemetry parser (port unchanged from AC, but different data structure) | ACC sessions captured and analyzed |\\\n| **B2: iRacing support** | iRacing telemetry via YAML file or memory-mapped file | iRacing sessions captured |\\\n| **B3: Rally game support** | Add support for AC Rally, Dirt Rally 2.0, EA WRC UDP output | Rally stages captured and analyzed |\\\n| **B4: Rally-specific analysis** | Stage-based analysis (not laps), surface type detection, pacenote timing, split time comparison | Rally coaching insights unique to rally discipline |\\\n| **B5: F1 game support** | F1 2025/26 UDP telemetry (widely documented, standard format) | F1 sessions captured — access to largest casual sim racing audience |\\\n\\\n#### Phase C: AI Coaching & Automation (Months 7–10)\\\n\\\n**Goal:** This is the moat. Raw telemetry is a commodity; AI-driven coaching is the product.\\\n\\\n| Milestone | Tasks | Success Metric |\\\n|---|---|---|\\\n| **C1: Automated anomaly detection** | ML model to detect \\\"unusual\\\" inputs (late braking, early throttle, inconsistent steering) | System highlights top 3 mistakes per lap without user input |\\\n| **C2: Coaching Flows (Track Titan's killer feature)** | Step-by-step guided analysis: \\\"Here's your biggest time loss, here's how to fix it\\\" | Users get actionable advice, not just raw data |\\\n| **C3: Setup recommendations** | Correlate telemetry patterns with setup changes; suggest adjustments | \\\"Your rear tyre temps are 15°C too high — try reducing rear anti-roll bar\\\" |\\\n| **C4: LLM-powered coaching chat** | Integrate LLM (local or API) to answer questions about telemetry in natural language | \\\"Why am I losing time in Turn 3?\\\" → detailed explanation with data references |\\\n| **C5: Rally pacenote analysis** | Correlate pacenote calls (if game provides them) with driver inputs to find commitment issues | \\\"You're lifting 30m early on every '4 left' — here's where you're losing 2.3s per stage\\\" |\\\n\\\n#### Phase D: Platform & Monetization (Months 11–18)\\\n\\\n**Goal:** Turn it into a business.\\\n\\\n| Milestone | Tasks | Success Metric |\\\n|---|---|---|\\\n| **D1: User accounts & cloud sync** | Authentication, cloud storage for recordings, cross-device access | Users can access their data from any device |\\\n| **D2: Community features** | Leaderboards, lap sharing, setup sharing, driver profiles | Users share and compare laps with others |\\\n| **D3: Freemium model** | Free tier (basic telemetry) + Pro tier (AI coaching, reference laps, advanced analysis) | Revenue model validated |\\\n| **D4: Partnership with community platform** | OverTake.gg-style partnership with a rally or sim racing community | Distribution channel established |\\\n| **D5: Mobile companion app** | iOS/Android app for post-session review, notifications, coaching alerts | Users review sessions on mobile |\\\n| **D6: Real-world telemetry bridge** | Support OBD-II / CAN bus data from real cars; combine sim data with real data for sim-to-real coaching | Product works for both sim and real racing |\\\n\\\n---\\\n\\\n### 16.7 Revenue Model Options\\\n\\\n| Model | Pricing | Target Audience | Revenue Potential | Feasibility |\\\n|---|---|---|---|---|\\\n| **SaaS Subscription** (Track Titan model) | Free basic + £5–10/mo Pro + £15/mo Teams | Sim racers, esports teams | Medium-High | High — proven model |\\\n| **One-time License** (MoTeC model) | $99–299 perpetual license | Serious sim racers, small teams | Medium | Medium — less predictable revenue |\\\n| **API / SDK Platform** | Per-call or per-seat licensing | Sim racing app developers, esports leagues | High if adopted | Low — requires ecosystem |\\\n| **Coaching Marketplace** | Commission on 1:1 coaching sessions | Sim racers wanting personalized coaching | Medium | Medium — needs coach supply |\\\n| **Enterprise / Team** | $50–200/mo per team seat | Esports organizations, racing academies | High | Medium — needs team features |\\\n| **Real Racing Telemetry** | $20–50/mo + hardware bundle | Club racers, rally drivers, track day enthusiasts | Very High | Low — requires hardware R&D |\\\n\\\n**Recommended: Start with SaaS Freemium** (Track Titan model), evolve toward real racing telemetry as a premium tier.\\\n\\\n---\\\n\\\n### 16.8 Unique Differentiators — What Would Make This Stand Out\\\n\\\n1. **Circuit + Rally in one platform** — Nobody does this. Track Titan is circuit-only. SimRacingSetup is F1-only. A platform that handles both Vallelunga GP AND Monte Carlo Rally stage analysis is genuinely novel.\\\n\\\n2. **Open-source core** — MoTeC i2 costs thousands. An open-source telemetry platform (like how VS Code is open-source but monetized via services) builds trust and community. The rusty-telemetry backend could be open-source while the AI coaching SaaS is proprietary.\\\n\\\n3. **Rust performance** — 60 Hz telemetry with real-time analysis in <50ms. Most competitors use Python or Electron. Rust gives us a genuine edge in processing large datasets (long endurance races, multi-hour rally stages).\\\n\\\n4. **Self-hostable option** — Privacy-conscious users, teams, and racing academies who don't want their data on someone else's cloud. Premium feature: \\\"deploy on your own server.\\\"\\\n\\\n5. **Sim-to-real bridge** — Long-term vision: the same analysis tools work for your sim sessions AND your real track days (via OBD-II/CAN data). No competitor offers this unified experience today.\\\n\\\n6. **AI coaching built on local LLMs** — Privacy-preserving AI coaching that runs locally. No need to upload telemetry to a cloud for analysis. This matters to serious racers who consider their data competitive intelligence.\\\n\\\n---\\\n\\\n### 16.9 Key Risks & Mitigation\\\n\\\n| Risk | Probability | Impact | Mitigation |\\\n|---|---|---|---|\\\n| Track Titan expands to rally | Medium | High — eliminates our key differentiator | Move fast on rally support; build deeper rally-specific features (pacenote analysis, surface adaptation) |\\\n| Game devs restrict telemetry access | Low | Critical — kills the product | Support many games to avoid single-point dependency; engage game devs as partners |\\\n| AI coaching requires massive training data | High | Medium — limits coaching quality | Start with rule-based coaching (no ML needed for \\\"brake later here\\\"); crowdsource training data from community |\\\n| Real racing telemetry requires hardware | High | High — significant R&D cost | Defer real racing to Phase D+; validate with sim racing first; partner with existing hardware vendors (RaceLogic, Garmin) |\\\n| User acquisition cost too high | Medium | High — can't build sustainable business | Partner with community platforms (OverTake model); open-source core builds organic adoption; content marketing (YouTube coaching videos) |\\\n\\\n---\\\n\\\n### 16.10 Recommended First Steps (Next 30 Days)\\\n\\\n1. **Ship §1.9** (feed merging, run deletion) — makes the tool genuinely usable for multi-feed analysis\\\n2. **Verify with live AC session** — prove the whole stack works end-to-end with real gameplay\\\n3. **Add lap detection** — auto-segment laps from spline data (critical for any coaching feature)\\\n4. **Build reference lap overlay** — the single most requested feature in sim racing telemetry (this is what makes Track Titan sticky)\\\n5. **Research AC Rally telemetry output** — determine if our existing parsers work with the new rally expansion\\\n6. **Draft the rally coaching model** — what does \\\"coaching\\\" look like for a rally stage vs. a circuit lap?\\\n\\\n---\\\n\\\n## 17. Analysis Use Cases — Track Mapping, Corner Analysis & Ideal Lap\\\n\\\n> **Analysis date: 2026-06-06**\\\n> **Goal: Define the next analysis use cases beyond shift points, with track mapping as the foundation for everything that follows.**\\\n\\\n---\\\n\\\n### 17.1 Why Track Mapping Must Come First — The Deliberate Boundary Recording Method\\\n\\\n**The core insight:** Every subsequent analysis feature (corner detection, grip mapping, theoretical best lap, optimal racing line) depends on an accurate model of the track geometry. Without knowing the track's exact shape, width, and curvature, we cannot calculate optimal lines or detect where a driver deviates from the ideal.\\\n\\\n**Why automatic boundary estimation from normal laps is insufficient:**\\\n\\\nDrivers almost never use the absolute edge of the track. If we estimate boundaries from even 20 normal racing laps, the derived \\\"track\\\" will be 2–4 meters narrower than reality. For optimal line calculation, this is fatal — the optimal line EXPLOITS the full track width. A 2-meter error means the calculated optimal line will clip corners 1 meter early and leave 1 meter of unused exit road. That's the difference between a useful coaching tool and a novelty.\\\n\\\n**Deliberate boundary recording solves this:**\\\n\\\n| Aspect | Auto-Estimated Boundaries | Deliberate Boundary Recording |\\\n|---|---|---|\\\n| Track width accuracy | ±2–4m (too narrow) | ±0.5m (near-exact) |\\\n| Confidence in optimal line | Low — can't trust the line is actually possible | High — line stays within known boundaries |\\\n| Number of laps needed | 10–20+ normal laps | 2 dedicated slow laps |\\\n| Enables optimal line calc? | No — too narrow | Yes |\\\n| Effort | None (passive) | One 10-minute session per track |\\\n| Reusable? | No — re-estimate every time | Yes — persistent TrackModel keyed by (game, track) |\\\n\\\n**The track mapping ritual (user workflow):**\\\n\\\n1. Load track in the sim, select car\\\n2. Start a `track_mapping` session in racecraft\\\n3. **Run 1: Left boundary** — Drive a slow, careful lap hugging the left edge of the track. The system records `world_pos` at 60 Hz. Label: \\\"left_boundary\\\"\\\n4. **Run 2: Right boundary** — Same thing, hugging the right edge. Label: \\\"right_boundary\\\"\\\n5. Stop recording. System builds `TrackModel` automatically.\\\n6. TrackModel is persisted and keyed by `(game, track_name)`. All future sessions at this track automatically load this TrackModel.\\\n\\\n**Why this is a good first experience with the product:**\\\n- It's a deliberate, mindful exercise — the user is actively participating, not just passively recording\\\n- It builds investment (you mapped this track, now you want to use the analysis)\\\n- The resulting track map is immediately visual — satisfying feedback\\\n- It naturally introduces the concept of \\\"track width\\\" and \\\"racing line\\\" before we start coaching\\\n- Once mapped, the track model is a shareable asset (future community feature)\\\n\\\n---\\\n\\\n### 17.2 The Analysis Pipeline — From Raw Data to Coaching\\\n\\\nThe full pipeline from raw 60 Hz telemetry to coaching output:\\\n\\\n```\\\n ┌─────────────────────────┐\\\n │ 60 Hz Telemetry Feed │\\\n │ (world_pos, speed, Gs, │\\\n │ slip, inputs, spline) │\\\n └───────────┬─────────────┘\\\n │\\\n ┌───────────▼─────────────┐\\\n │ 1. LAP DETECTION │\\\n │ Detect lap boundaries │\\\n │ from spline_position │\\\n │ crossing 0.0 → 1.0 │\\\n └───────────┬─────────────┘\\\n │\\\n ┌───────────▼─────────────┐\\\n │ 2. TRACK MAPPING │\\\n │ (if not yet mapped) │\\\n │ Build TrackModel from │\\\n │ boundary laps: │\\\n │ - Left/right edges │\\\n │ - Center line │\\\n │ - Width profile │\\\n │ - Curvature κ(s) │\\\n │ - Auto-detected corners │\\\n └───────────┬─────────────┘\\\n │ (TrackModel persisted)\\\n │\\\n ┌────────────────┼────────────────┐\\\n │ │ │\\\n ┌───────────▼──────┐ ┌─────▼──────────┐ ┌──▼───────────────────┐\\\n │ 3. CORNER │ │ 4. GRIP │ │ 5. THEORETICAL │\\\n │ ANALYSIS │ │ ENVELOPE │ │ BEST LAP │\\\n │ Per-corner: │ │ From all laps: │ │ Stitch best sectors │\\\n │ - Entry/mid/exit │ │ - Max lat G │ │ across multiple laps │\\\n │ - Speed trace │ │ - Max accel G │ │ into one ideal lap │\\\n │ - G-forces │ │ - Max brake G │ │ │\\\n │ - Slip angles │ │ - Grip circle │ │ → Optimal speed │\\\n │ - Input profile │ │ boundary │ │ trace │\\\n └───────┬──────────┘ └───────┬────────┘ └──────────┬───────────┘\\\n │ │ │\\\n └─────────────┬───────┘───────────────────────┘\\\n │\\\n ┌───────────▼─────────────────┐\\\n │ 6. TIME LOSS ATTRIBUTION │\\\n │ Per corner per lap: │\\\n │ - Delta vs. theoretical best│\\\n │ - Root cause analysis │\\\n │ - Where in corner (entry/ │\\\n │ mid/exit) time was lost │\\\n │ - Why (slip, inputs, speed) │\\\n └───────────┬─────────────────┘\\\n │\\\n ┌───────────▼─────────────────┐\\\n │ 7. COACHING OUTPUT │\\\n │ \\\"Turn 3: -0.4s │\\\n │ Braked 12m too early │\\\n │ Car can do 1.4g, │\\\n │ you used only 1.1g │\\\n │ → Brake 12m later, │\\\n │ carry 7 km/h more speed\\\" │\\\n └─────────────────────────────┘\\\n```\\\n\\\n---\\\n\\\n### 17.3 Step 1: Lap Detection\\\n\\\n**Data source:** `spline_position` (0.0–1.0) from the Telemetry Tool feed. This field represents the car's position along the track's spline (normalized track progress). A lap crossing occurs when the value wraps from ~1.0 back to ~0.0.\\\n\\\n**Algorithm:**\\\n\\\n```rust\\\nfn detect_laps(frames: &[TelemetryFrame]) -> Vec {\\\n let mut laps = Vec::new();\\\n let mut current_lap_start = 0;\\\n let mut last_spline = frames[0].spline_position;\\\n\\\n for (i, frame) in frames.iter().enumerate().skip(1) {\\\n let spline = frame.spline_position;\\\n\\\n // Lap crossing: spline jumps backward (1.0 → 0.0)\\\n if spline < last_spline - 0.5 {\\\n // Transition: frames[current_lap_start..i] form one lap\\\n laps.push(Lap {\\\n start_frame: current_lap_start,\\\n end_frame: i,\\\n lap_time: frame.timestamp - frames[current_lap_start].timestamp,\\\n frames: &frames[current_lap_start..i],\\\n });\\\n current_lap_start = i;\\\n }\\\n last_spline = spline;\\\n }\\\n\\\n laps\\\n}\\\n```\\\n\\\n**Edge cases to handle:**\\\n- Invalid lap detection (off-track, cutting) → flag `is_valid` based on spline monotonicity check\\\n- First partial lap (crossing start before first full lap) → mark as \\\"out lap\\\"\\\n- Pit lane entry/exit → spline may jump; filter by `in_pit` / `in_pitlane` flags\\\n- Slow-speed crossings (creeping over start/finish) → minimum speed threshold\\\n\\\n**New data structures:**\\\n\\\n```rust\\\nstruct Lap {\\\n start_frame: usize,\\\n end_frame: usize,\\\n lap_time_ms: u64,\\\n is_valid: bool, // no off-track, no cutting, no pit\\\n is_out_lap: bool, // first crossing after leaving pits\\\n is_in_lap: bool, // lap before pit entry\\\n}\\\n```\\\n\\\n**Effort:** 1–2 days. This is foundational — everything depends on it.\\\n\\\n---\\\n\\\n### 17.4 Step 2: Track Mapping — Building the TrackModel\\\n\\\n**New use case:** `track_mapping`\\\n\\\nThis is a dedicated session type. The user deliberately drives boundary laps. The system builds a persistent `TrackModel` from these laps.\\\n\\\n**New data structures:**\\\n\\\n```rust\\\n/// Persistent track model, keyed by (game, track_name).\\\n/// Stored as JSON in data/tracks//.json\\\nstruct TrackModel {\\\n game: String, // e.g. \\\"assetto_corsa\\\"\\\n track_name: String, // e.g. \\\"vallelunga\\\"\\\n created_at: u64, // timestamp\\\n resolution: usize, // number of spline sample points (e.g. 1000)\\\n\\\n // Per-sample-point arrays, indexed by spline position\\\n center_line: Vec<[f32; 3]>, // [x, y, z] at each spline point\\\n left_boundary: Vec<[f32; 3]>, // left edge position\\\n right_boundary: Vec<[f32; 3]>, // right edge position\\\n track_width: Vec, // distance left→right at each point (meters)\\\n heading: Vec, // track direction angle at each point (radians)\\\n curvature: Vec, // κ = dθ/ds at each point (1/meters)\\\n\\\n // Auto-detected from curvature\\\n corners: Vec,\\\n sectors: Vec,\\\n\\\n // Metadata\\\n total_length_meters: f32, // track length\\\n sample_spacing_meters: f32, // meters between spline samples\\\n}\\\n\\\nstruct Corner {\\\n id: usize,\\\n entry_spline: f32, // where curvature starts rising\\\n apex_spline: f32, // peak curvature point\\\n exit_spline: f32, // where curvature returns to ~0\\\n radius_meters: f32, // effective corner radius\\\n direction: TurnDirection, // Left or Right\\\n sector_id: usize, // which sector this corner belongs to\\\n}\\\n\\\nenum TurnDirection {\\\n Left,\\\n Right,\\\n}\\\n\\\nstruct Sector {\\\n id: usize,\\\n start_spline: f32,\\\n end_spline: f32,\\\n sector_type: SectorType,\\\n}\\\n\\\nenum SectorType {\\\n Straight,\\\n Corner(usize), // references Corner id\\\n Complex, // multiple corners close together (chicane, esses)\\\n}\\\n```\\\n\\\n**Track building algorithm:**\\\n\\\n```\\\n1. RESAMPLE boundary laps to uniform spline positions\\\n - Left boundary lap: 60 Hz samples with (world_pos, spline_pos)\\\n - Right boundary lap: same\\\n - Interpolate both onto a uniform grid of 1000 spline positions (0.000, 0.001, ..., 0.999)\\\n\\\n2. BUILD center line\\\n - center[i] = midpoint(left[i], right[i])\\\n - This is the geometric center of the track, NOT the racing line\\\n\\\n3. CALCULATE track width at each point\\\n - width[i] = distance(left[i], right[i])\\\n\\\n4. CALCULATE heading at each point\\\n - θ[i] = atan2(center[i+1].y - center[i].y, center[i+1].x - center[i].x)\\\n\\\n5. CALCULATE curvature at each point\\\n - dθ[i] = angle_difference(θ[i+1], θ[i])\\\n - ds[i] = distance(center[i], center[i+1])\\\n - κ[i] = dθ[i] / ds[i]\\\n - Smooth with moving average (window = ~20m of track)\\\n\\\n6. DETECT corners from curvature\\\n - Threshold: |κ| > corner_threshold (auto-calibrate: use median(|κ|) * 3 as threshold)\\\n - Merge corners closer than 15m apart\\\n - For each corner group: entry = first sample above threshold, apex = max(|κ|), exit = last sample above threshold\\\n - Corner radius R = 1 / |κ_apex|\\\n - Direction: positive κ = left turn, negative κ = right turn\\\n\\\n7. COMPUTE sectors\\\n - Split track into sectors at corner entry/exit points\\\n - Label as Straight, Corner(id), or Complex\\\n\\\n8. PERSIST to data/tracks//.json\\\n```\\\n\\\n**API additions:**\\\n\\\n| Endpoint | Method | Description |\\\n|---|---|---|\\\n| `GET /api/tracks` | GET | List all mapped tracks |\\\n| `GET /api/tracks/{game}/{track_name}` | GET | Get TrackModel |\\\n| `POST /api/tracks/build` | POST | Build TrackModel from boundary runs (JSON: recording_id, left_run_id, right_run_id) |\\\n| `DELETE /api/tracks/{game}/{track_name}` | DELETE | Delete a track model |\\\n\\\n**New module:** `src/track_model.rs` (~300 lines) — TrackModel builder, persistence, corner detection, curvature calculation.\\\n\\\n**Effort:** 3–5 days. This is the most important single piece of work — every downstream feature depends on it.\\\n\\\n---\\\n\\\n### 17.5 Step 3: Corner Analysis\\\n\\\nOnce we have laps and a TrackModel with auto-detected corners, we can analyze each corner in each lap.\\\n\\\n**New data structures:**\\\n\\\n```rust\\\nstruct CornerAnalysis {\\\n corner_id: usize,\\\n lap_number: usize,\\\n\\\n // Speed profile\\\n entry_speed_kmh: f32,\\\n apex_speed_kmh: f32,\\\n exit_speed_kmh: f32,\\\n min_speed_kmh: f32,\\\n speed_delta_kmh: f32, // entry - min (how much speed was scrubbed)\\\n\\\n // G-forces\\\n peak_lateral_g: f32,\\\n avg_lateral_g: f32,\\\n peak_longitudinal_g_entry: f32, // braking G at entry\\\n peak_longitudinal_g_exit: f32, // acceleration G at exit\\\n\\\n // Tyre behavior\\\n peak_front_slip_angle: f32, // max front slip angle\\\n peak_rear_slip_angle: f32, // max rear slip angle\\\n understeer_detected: bool, // front slip >> rear slip during corner\\\n oversteer_detected: bool, // rear slip >> front slip during corner\\\n peak_nd_slip: f32, // max normalized slip across all 4 wheels\\\n\\\n // Driver inputs\\\n brake_at_entry: bool, // was brake applied at corner entry?\\\n trail_braking_detected: bool, // brake + steer overlap > 100ms\\\n throttle_application_spline: f32, // where throttle first exceeds 10% after braking\\\n steering_corrections: u32, // count of direction reversals in steering\\\n\\\n // Timing\\\n time_in_corner_ms: u64, // entry → exit duration\\\n time_loss_vs_best_ms: i64, // positive = slower than best lap's same corner\\\n\\\n // Grip utilization\\\n grip_utilization_pct: f32, // peak_lat_g / max_lat_g_from_envelope × 100\\\n}\\\n```\\\n\\\n**Key derived metrics:**\\\n\\\n| Metric | How to Calculate | Coaching Insight |\\\n|---|---|---|\\\n| **Trail braking detection** | Brake > 5% AND steer > 5% for > 100ms after corner entry | Advanced technique — indicates driver is rotating the car on entry |\\\n| **Understeer detection** | Front slip angle > rear slip angle by > threshold during mid-corner | Car is pushing — driver turning but car isn't turning |\\\n| **Oversteer detection** | Rear slip angle > front slip angle by > threshold | Car is loose — driver is catching slides |\\\n| **Grip utilization** | `peak_lateral_g / grip_envelope.max_lat_g(speed) × 100` | How close to the limit. <70% = lots of time on the table |\\\n| **Throttle application point** | First frame where throttle > 10% after last brake release | Early throttle = good exit, late throttle = cautious or poor line |\\\n| **Steering corrections** | Count zero-crossings in steering angle derivative | Smooth = 1 clean input, corrections = fighting the car or misjudged entry |\\\n\\\n**New module:** `src/corner_analysis.rs` (~400 lines) — CornerAnalyzer that takes laps + TrackModel and produces `Vec`.\\\n\\\n**Effort:** 3–4 days.\\\n\\\n---\\\n\\\n### 17.6 Step 4: Grip Envelope — The Car Performance Model\\\n\\\nFrom multiple laps of data, we can build a model of what this car is CAPABLE of. This is the \\\"grip circle\\\" — the boundary of maximum force the tyres can generate.\\\n\\\n**New data structures:**\\\n\\\n```rust\\\n/// Car performance envelope, keyed by (game, track, car, setup_hash).\\\n/// Built from multiple laps of telemetry.\\\nstruct GripEnvelope {\\\n game: String,\\\n track: String,\\\n car: String,\\\n\\\n // Maximum lateral acceleration at each speed range\\\n // Sorted by speed, gives us the cornering limit\\\n max_lateral_g_by_speed: Vec, // [(speed_kmh, max_lat_g), ...]\\\n\\\n // Maximum longitudinal acceleration (throttle) at each speed\\\n max_accel_g_by_speed: Vec,\\\n\\\n // Maximum braking deceleration at each speed\\\n max_brake_g_by_speed: Vec,\\\n\\\n // The grip circle boundary: combined lateral + longitudinal\\\n // Points on the edge of the (lat_g, lon_g) plot\\\n grip_circle_boundary: Vec<(f32, f32)>, // [(lat_g, lon_g), ...]\\\n\\\n // Derived constants\\\n estimated_mu: f32, // estimated coefficient of friction\\\n peak_lateral_g: f32, // overall maximum lateral G\\\n peak_brake_g: f32, // overall maximum braking G\\\n}\\\n\\\nstruct SpeedGPair {\\\n speed_kmh: f32,\\\n max_g: f32,\\\n}\\\n```\\\n\\\n**Building the grip envelope:**\\\n\\\n```\\\n1. Collect ALL telemetry frames across ALL laps in a session\\\n2. BIN by speed (e.g., 10 km/h bins: 0-10, 10-20, ..., 250-260)\\\n3. For each bin:\\\n - max_lat_g = max(|acc_lateral|) across all frames in bin\\\n - max_accel_g = max(acc_frontal) where throttle > 80%\\\n - max_brake_g = max(|acc_frontal|) where brake > 80%\\\n4. For grip circle:\\\n - Plot all (|acc_lateral|, acc_frontal) points\\\n - Compute convex hull → this IS the grip circle\\\n - The inside = within grip limits, the outside = sliding\\\n5. Estimate μ from peak lateral G: μ ≈ peak_lat_g / 9.81\\\n```\\\n\\\n**Why this matters for coaching:**\\\n\\\nThe grip envelope tells us the car's absolute performance limit. When we see a driver at 1.1g lateral in a corner where the car can do 1.4g, we know they're only using 78% of the available grip. That's a quantifiable coaching opportunity.\\\n\\\nThe grip envelope is also car-specific and setup-specific. Different cars have different envelopes. Different setups (tyre pressures, aero, suspension) change the envelope. This is why professional teams spend so much time mapping grip envelopes — it's the fundamental constraint that everything else is optimized against.\\\n\\\n**Effort:** 2–3 days for the builder module. The data is already there in the telemetry frames.\\\n\\\n---\\\n\\\n### 17.7 Step 5: Theoretical Best Lap — Sector Stitching\\\n\\\nThis is the approach that delivers the biggest coaching value for the least implementation effort. No physics model needed.\\\n\\\n**Algorithm:**\\\n\\\n```\\\n1. Load TrackModel for this (game, track)\\\n2. Load all valid laps from the session (e.g., 10 laps)\\\n3. Segment each lap into sectors using TrackModel.corners\\\n - Each sector = corner_entry to next corner_entry\\\n - Or use traditional S1/S2/S3 if the game provides sector times\\\n4. For each sector:\\\n - Find the fastest traversal across ALL laps\\\n - Record which lap it came from\\\n5. Stitch: theoretical_best_time = sum(fastest_sector_times)\\\n6. Build speed trace: for each sector, use the speed data from the lap that was fastest in that sector\\\n7. Build position trace: same, for track map visualization\\\n```\\\n\\\n**New data structures:**\\\n\\\n```rust\\\nstruct TheoreticalBestLap {\\\n track: String,\\\n total_time_ms: u64,\\\n sectors: Vec,\\\n speed_trace: Vec<(f32, f32)>, // (spline_position, speed_kmh)\\\n position_trace: Vec<[f32; 3]>, // world_pos at each spline point\\\n}\\\n\\\nstruct BestSector {\\\n sector_id: usize,\\\n best_time_ms: u64,\\\n source_lap_number: usize, // which actual lap this came from\\\n entry_spline: f32,\\\n exit_spline: f32,\\\n}\\\n```\\\n\\\n**Why this works so well:**\\\n- It's grounded in REALITY — the car actually achieved each sector time\\\n- It shows the driver: \\\"Your best T1 was Lap 5, your best T2 was Lap 12 — put them together and you're 0.8s faster\\\"\\\n- It naturally identifies which corners lose the most time across laps\\\n- It doesn't require a physics model, tyre model, or aerodynamic data\\\n\\\n**Effort:** 2–3 days.\\\n\\\n---\\\n\\\n### 17.8 Step 6: Time Loss Attribution — The Coaching Engine\\\n\\\nThis is where everything comes together. For each corner in each lap, we compare against the theoretical best and explain WHY time was lost.\\\n\\\n**Algorithm:**\\\n\\\n```\\\nFor each lap L:\\\n For each corner C in TrackModel:\\\n actual_time = time from C.entry_spline to C.exit_spline in lap L\\\n best_time = time for same corner from TheoreticalBestLap\\\n time_loss = actual_time - best_time\\\n\\\n If time_loss > threshold (e.g., 50ms):\\\n Determine WHERE in the corner time was lost:\\\n entry_phase = C.entry_spline to C.apex_spline\\\n exit_phase = C.apex_spline to C.exit_spline\\\n\\\n entry_time_loss = time_lost_in(entry_phase) vs. best\\\n exit_time_loss = time_lost_in(exit_phase) vs. best\\\n\\\n Determine WHY:\\\n\\\n If entry_time_loss > exit_time_loss:\\\n → Problem is at ENTRY\\\n Check:\\\n - Was entry_speed significantly lower than best?\\\n → \\\"Braked too early\\\" (most common amateur mistake)\\\n - Was entry_speed significantly HIGHER than best?\\\n → \\\"Braked too late, had to correct mid-corner\\\"\\\n - Was peak brake G lower than grip envelope allows?\\\n → \\\"Not braking hard enough — you can brake harder\\\"\\\n - Was trail braking not detected when best lap had it?\\\n → \\\"Try trail braking to rotate the car on entry\\\"\\\n\\\n If exit_time_loss > entry_time_loss:\\\n → Problem is at EXIT\\\n Check:\\\n - Was exit_speed significantly lower than best?\\\n → \\\"Not getting on throttle early enough\\\"\\\n - Was throttle_application_spline later than best?\\\n → \\\"Applying throttle X meters later than optimal\\\"\\\n - Was grip_utilization low (<75%)?\\\n → \\\"Only using X% of available grip — the car can take more speed\\\"\\\n - Was understeer detected?\\\n → \\\"Car is understeering — consider adjusting line or setup\\\"\\\n\\\n Mid-corner check:\\\n - Were steering_corrections > 2?\\\n → \\\"Steering is inconsistent — try a smoother, single input\\\"\\\n - Was there a mid-corner throttle lift?\\\n → \\\"Confidence lift detected — the car can carry more speed here\\\"\\\n```\\\n\\\n**Coaching output format:**\\\n\\\n```json\\\n{\\\n \\\"corner_id\\\": 3,\\\n \\\"corner_label\\\": \\\"Turn 3 (Right Hairpin)\\\",\\\n \\\"time_loss_ms\\\": 412,\\\n \\\"phase\\\": \\\"entry\\\",\\\n \\\"severity\\\": \\\"high\\\",\\\n \\\"findings\\\": [\\\n {\\\n \\\"type\\\": \\\"early_braking\\\",\\\n \\\"message\\\": \\\"Braked 15m too early\\\",\\\n \\\"detail\\\": \\\"Entry speed was 89 km/h vs. optimal 101 km/h\\\",\\\n \\\"data\\\": { \\\"actual_entry_speed\\\": 89, \\\"optimal_entry_speed\\\": 101 }\\\n },\\\n {\\\n \\\"type\\\": \\\"low_grip_utilization\\\",\\\n \\\"message\\\": \\\"Only using 71% of available grip\\\",\\\n \\\"detail\\\": \\\"Peak lateral G: 1.05g, car can do 1.48g at this speed\\\",\\\n \\\"data\\\": { \\\"actual_peak_g\\\": 1.05, \\\"max_g\\\": 1.48, \\\"utilization_pct\\\": 71 }\\\n }\\\n ],\\\n \\\"recommendation\\\": \\\"Brake 15m later, carry 12 km/h more speed into the corner. The car has 30% more grip available — trust it.\\\"\\\n}\\\n```\\\n\\\n**Effort:** 4–5 days for the core engine. Iterative refinement ongoing.\\\n\\\n---\\\n\\\n### 17.9 Step 7 (Future): Physics-Based Optimal Racing Line\\\n\\\nThis is the \\\"holy grail\\\" — calculating the mathematically optimal path around the track, not just stitching best sectors. Requires the GripEnvelope and TrackModel as prerequisites.\\\n\\\n**The theory:**\\\n\\\nThe optimal racing line through a corner maximizes the effective radius, which allows the highest cornering speed:\\\n\\\n```\\\nFor a simple corner:\\\n Track width = W (from TrackModel)\\\n Corner geometric radius = R (from TrackModel.curvature)\\\n Optimal line radius = R + W/2 (out-in-out uses full track width)\\\n Maximum cornering speed = sqrt(μ × g × R_effective)\\\n```\\\n\\\nFor complex corners (chicanes, esses, decreasing-radius), it's an optimization problem:\\\n\\\n```\\\nMinimize: total lap time\\\nSubject to:\\\n - Path stays within track boundaries (from TrackModel)\\\n - Lateral force stays within grip circle (from GripEnvelope)\\\n - Longitudinal force stays within grip circle\\\n - Speed = integral of acceleration\\\n - Position = integral of velocity × heading\\\n```\\\n\\\n**Simplified practical approach (good enough for coaching):**\\\n\\\nInstead of solving the full optimal control problem, use a geometric method:\\\n\\\n```\\\n1. For each corner, calculate the widest possible arc using full track width:\\\n - Entry: approach from outside edge\\\n - Apex: clip inside edge\\\n - Exit: track out to outside edge\\\n - This gives the maximum-radius path through the corner\\\n\\\n2. Calculate maximum speed at each point on this path:\\\n - At apex: v_max = sqrt(μ × g × R_effective)\\\n - On entry: calculate braking curve from approach speed to apex speed\\\n - On exit: calculate acceleration curve from apex speed to next straight's speed\\\n\\\n3. Combine with straight-line performance:\\\n - Full throttle acceleration curve from GripEnvelope\\\n - Maximum braking curve from GripEnvelope\\\n\\\n4. The result: a speed-at-every-spline-point profile\\\n → This IS the optimal lap, expressed as the fastest possible speed trace\\\n```\\\n\\\n**Why this is a future step (not immediate):**\\\n- Requires well-calibrated GripEnvelope (needs many laps to build accurately)\\\n- Assumes the tyre model is constant (ignores tyre wear, temperature effects)\\\n- The geometric approach works for simple corners but needs iterative optimization for complexes\\\n- The theoretical best lap (sector stitching) provides 80% of the coaching value at 20% of the effort\\\n\\\n**Effort:** 2–4 weeks for a robust implementation. Can be deferred until the simpler coaching features are proven useful.\\\n\\\n---\\\n\\\n### 17.10 Implementation Order and Dependencies\\\n\\\n```mermaid\\\ngraph TD\\\n A[Lap Detection] --> B[Track Mapping]\\\n B --> C[Corner Detection
from Curvature]\\\n C --> D[Corner Analysis
per-lap per-corner]\\\n C --> E[Grip Envelope
from multiple laps]\\\n D --> F[Theoretical Best Lap
sector stitching]\\\n E --> F\\\n F --> G[Time Loss Attribution
coaching engine]\\\n D --> G\\\n E --> H[Optimal Racing Line
physics-based
FUTURE]\\\n B --> H\\\n```\\\n\\\n**Recommended build order:**\\\n\\\n| Order | Module | Depends On | Effort | Value |\\\n|---|---|---|---|---|\\\n| **1** | Lap Detection | Spline data (already captured) | 1–2 days | Foundational |\\\n| **2** | Track Mapping + Boundary Recording | Lap Detection | 3–5 days | Foundational — enables everything |\\\n| **3** | Corner Detection (from curvature) | TrackModel | 2–3 days | Enables corner analysis |\\\n| **4** | Corner Analysis (per-corner metrics) | Laps + Corners | 3–4 days | Immediate coaching value |\\\n| **5** | Grip Envelope Builder | Multiple laps of data | 2–3 days | Enables optimal line, grip utilization % |\\\n| **6** | Theoretical Best Lap | Laps + Corners + Grip Envelope | 2–3 days | The \\\"ah-ha\\\" feature |\\\n| **7** | Time Loss Attribution | All of the above | 4–5 days | The actual coaching output |\\\n| **8** | Optimal Racing Line (future) | Grip Envelope + TrackModel | 2–4 weeks | Physics-perfect line |\\\n\\\n**Total effort for steps 1–7:** ~18–25 days of focused implementation.\\\n\\\n---\\\n\\\n### 17.11 What We Need From the Next Live Session\\\n\\\nTo start building these analysis features, we need specific data from the next AC session. Here's the session plan:\\\n\\\n**Session Goal: Track Mapping + Initial Laps at Vallelunga**\\\n\\\n| Run | Description | Duration | Purpose |\\\n|---|---|---|---|\\\n| 1 | Left boundary lap — slow, hugging left edge | ~2 min | TrackModel left boundary |\\\n| 2 | Right boundary lap — slow, hugging right edge | ~2 min | TrackModel right boundary |\\\n| 3–5 | 3 normal flying laps (Abarth 500, Vallelunga) | ~3 min each | Initial data for grip envelope, corner analysis, theoretical best |\\\n| 6 | Optional: more flying laps | ~3 min each | More data = better theoretical best |\\\n\\\n**What to verify during this session:**\\\n1. `spline_position` actually crosses 0.0→1.0 correctly for lap detection\\\n2. `world_pos` gives usable X/Y coordinates (check for NaN or zero values)\\\n3. `acc_lateral`, `acc_frontal` give plausible G-force values (compare to expected ~1.0–1.5g for Abarth)\\\n4. `tyre_slip_angle` and `nd_slip` show variation during cornering (not always zero)\\\n5. Speed values match expected range (0–200 km/h for Abarth at Vallelunga)\\\n\\\n**If the data checks out, we have everything needed to build steps 1–7.**\\\n\\\n---\\\n\\\n*Last updated: 2026-06-06 — Added §17: Analysis Use Cases (track mapping with deliberate boundary recording, lap detection, corner analysis, grip envelope, theoretical best lap, time loss attribution, optimal racing line, implementation order, next session plan)*\\\n*Next: implement §1.9 (feed merging, run deletion, session reopen), then §17.3 Lap Detection, then §17.4 Track Mapping, then live verification session at Vallelunga\"],[0,\"*\"]],\"start1\":19105,\"start2\":19105,\"length1\":311,\"length2\":46193}]" metadata_diff: {"new":{},"deleted":[]} encryption_cipher_text: encryption_applied: 0 updated_time: 2026-06-06T07:34:09.749Z created_time: 2026-06-06T07:34:09.749Z type_: 13