Status: Planned architecture and future implementation Last reviewed: August 31, 2026 Companion page: RaceIQ Analysis and Machine Learning Foundation

This page describes the operational half of RaceIQ's machine-learning plan: how models should be trained, packaged, distributed, loaded, updated, personalized, monitored, and run without making RaceIQ heavy or cloud-dependent.

The companion foundation page describes how RaceIQ creates trustworthy canonical telemetry, events, stints, quality decisions, provenance, findings, archives, and parity tests. This page assumes those lower-level contracts exist.

RaceIQ should use a local-first, CPU-friendly, task-specific machine-learning architecture.

The intended direction is:

Canonical telemetry and durable racing facts
 ↓
Deterministic quality and eligibility gates
 ↓
Versioned feature extraction
 ↓
Small shared task model
 +
Optional lightweight local driver calibration
 ↓
Calibrated prediction, confidence, and abstention
 ↓
Structured finding or recommendation candidate
 ↓
UI, report, Setup Engineer, or live-engineer arbitration
 ↓
Optional LLM explanation

The important operating principles are:

• Core telemetry interpretation and model inference should work locally.
• A network connection must not be required during a race.
• Initial production models should be small, explainable, and inexpensive on a normal CPU.
• Models should operate on compact features and bounded windows rather than repeatedly scanning full raw sessions.
• The first implementation should use task-specific models rather than one enormous model for every racing question.
• Shared models may improve from consented aggregate data, while a small per-driver layer can remain local.
• Models should be fixed during a live session; training and model replacement happen outside the race.
• A model must be able to abstain when required telemetry, fidelity, context, or confidence is missing.
• Model output must remain subordinate to deterministic evidence, quality rules, and live-message arbitration.
• AI-generated wording must not become the authority for what occurred.

The ML runtime should not read simulator-native packets directly or invent another data model.

It should consume the stable RaceIQ layers described by the foundation roadmap:

#130 source/session/participant identity
#205 canonical telemetry semantics
#229 lap classification
#232 canonical archive and hierarchy
#233 provenance and artifact generations
#234 durable race-event timeline
#235 participant, tire, driver, and pace runs
#236 quality and analysis eligibility
#237 deterministic findings
#238 live-engineer decision ledger
#239 processing parity

This gives a model enough context to know:

• which simulator, car, track, participant, and driver produced the input;
• whether values were direct, derived, simplified, stale, or unavailable;
• which lap, stint, corner, segment, or event window is being evaluated;
• whether the evidence is allowed for the model's task;
• which feature, dataset, and model versions produced the prediction;
• whether a prediction can be reproduced later.

A model should never treat a canonical field name as proof that two sources have identical fidelity.

For locally captured telemetry, the following should run on the user's computer:

• telemetry ingestion;
• canonical resolution;
• quality and eligibility evaluation;
• deterministic findings;
• feature extraction;
• normal model inference;
• live decision arbitration;
• UI and voice delivery.

Optional cloud services may help with:

• shared model training;
• model distribution;
• aggregate evaluation;
• user-selected AI explanation;
• explicitly authorized remote inference for a model that cannot reasonably run locally.

A remote RaceIQ model API should be an optional tier, not the only way core coaching functions work.

A model does not replace the authority stack.

The preferred authority order is:

Source-measured value
 ↓
Canonical conversion
 ↓
Physics or deterministic derivation
 ↓
Deterministic classification/finding
 ↓
Calibrated statistical prediction
 ↓
LLM narrative

A lower-authority layer must not silently overwrite a higher-authority fact.

For example:

• A model can estimate tire life, but it cannot claim a native tire-wear channel exists when it does not.
• A model can estimate understeer probability, but the output must retain the source limitations and confidence.
• An LLM can explain a finding, but it cannot strengthen an uncertain prediction into a fact.

The first models should be intentionally modest:

• regularized linear or logistic models;
• gradient-boosted decision trees such as LightGBM-compatible models;
• robust or quantile regression;
• hidden Markov or change-point models;
• isolation forests or similar low-complexity anomaly models;
• compact nearest-neighbor retrieval for analogous historical cases.

Small temporal convolution, GRU, or similar sequence models can be considered later when the data proves that engineered features and simpler temporal models are insufficient.

Large transformers or end-to-end raw-telemetry models should not be an early milestone.

RaceIQ should not begin with one universal model that attempts to answer every question.

Separate models may own tasks such as:

• fuel-use residual prediction;
• tire-degradation or pace-falloff prediction;
• corner-balance classification;
• lap-time opportunity estimation;
• anomaly or data-quality screening;
• driver-style calibration;
• setup-response estimation;
• live message usefulness or ranking.

Each model should have its own:

• feature contract;
• label policy;
• applicability rules;
• calibration;
• evaluation report;
• update lifecycle.

RaceIQ should not continually retrain or mutate a production model while a race is active.

During a session:

• the active model version is fixed;
• the feature definitions and thresholds are fixed;
• the personal calibration version is fixed;
• predictions are reproducible from recorded evidence;
• logging may collect examples for later review or training.

Training, promotion, model replacement, and personal recalibration should occur between sessions or while the application is idle.

A prediction is not always required.

A model should abstain when:

• required semantic values are unavailable;
• source fidelity is below the package's declared minimum;
• sample cadence is insufficient;
• the current simulator, car, track, or conditions are unsupported;
• the feature distribution is too far from training data;
• quality or eligibility policy blocks the selected range;
• confidence or calibration is below the product threshold;
• the model package is incompatible with the active RaceIQ schema.

The user-facing result should explain why the prediction is unavailable instead of showing a misleading zero or generic answer.

Most models should consume compact features rather than full raw telemetry streams.

Examples:

Corner feature vector
- brake onset distance
- peak brake
- brake release profile
- turn-in point
- minimum speed
- apex location
- throttle pickup point
- full-throttle point
- steering correction count
- path deviation
- corner time
- source quality and context masks

Stint feature vector
- eligible lap count
- early/middle/late pace summaries
- fuel-adjusted pace
- degradation slope
- tire-service identity
- traffic/caution contamination
- track and weather context
- confidence and missingness indicators

Feature extraction should happen once at the shared semantic boundary. UI, findings, ML, reports, and AI should reuse those results rather than separately rescanning telemetry.

RaceIQ should support several purpose-built views rather than one universal table.

High-rate data should be retained only for tasks that actually require high-rate evidence.

Not every model should run on every telemetry frame.

Preferred trigger scales include:

Every source frame
 deterministic canonical state and minimal safety checks only
Short bounded cadence
 fuel state, selected live context, nearby traffic state
Completed corner
 corner measurements, technique findings, corner model
Completed lap
 pace, fuel, degradation, comparison, driver-profile update
Run or stint update
 falloff, tire-life, setup-response, longer context
Adjustment or service event
 before/after experiment tracking and label collection

RaceIQ should avoid running whole-field ML at raw telemetry cadence. Opponent analysis should be limited to the participants and update frequency actually needed for the product question, such as nearby relevant cars, completed laps, or a bounded low-frequency estimate.

Live analysis should retain only what it needs to answer current questions.

Recommended structures include:

• current canonical state;
• short rolling ring buffers;
• active corner/segment accumulator;
• active lap accumulator;
• current participant/tire/driver/pace-run state;
• compact summaries of completed laps and corners;
• selected reference summaries;
• event timeline and active state;
• model feature caches;
• recent prediction and cooldown state.

Once a detailed live window is no longer needed, it can be released from RAM because the durable raw recording or verified canonical archive can rebuild historical analysis later.

The operating rule is:

Keep enough live state to answer current questions.
Persist enough durable evidence to rebuild everything else.

Normal RaceIQ inference should target CPU operation.

The expected production approach is:

• deterministic rules and simple calculations in TypeScript where practical;
• production ML exported to ONNX where supported;
• ONNX Runtime embedded in the RaceIQ process or a tightly managed local sidecar;
• models loaded once and reused rather than repeatedly initialized;
• batched logging and bounded background work;
• no dedicated GPU requirement for normal users.

GPU or remote inference may be allowed for future optional models, but basic coaching and race-engineer features should not depend on it.

Not every simulator exposes the same channels.

A model package may provide:

• a full-fidelity model;
• one or more reduced-feature variants;
• a deterministic fallback;
• an abstention result.

The model router should choose explicitly. It must not silently substitute a simplified or missing channel into a model that was trained for a different contract.

The long-term plan should separate shared knowledge from personal adaptation.

A shared model learns broad relationships from approved training data, such as:

• typical fuel-use residuals;
• common pace-falloff patterns;
• corner-balance relationships;
• general technique patterns;
• expected confidence by telemetry source;
• event or anomaly signatures.

Shared models can be distributed to all compatible RaceIQ installations.

A lightweight personal layer can adjust a shared prediction for one driver without requiring the full global model to be retrained on the user's computer.

Possible personal components include:

• probability calibration;
• threshold adjustment;
• bounded residual correction;
• driver-specific baseline pace or consistency;
• preference weighting;
• local nearest-neighbor examples;
• confidence adjustment based on the driver's history.

Conceptually:

Shared model prediction
 +
Bounded local driver correction
 +
Deterministic guardrails
 =
Final calibrated prediction

The personal correction should be capped so a sparse or unstable local history cannot completely overturn the shared model and deterministic safety rules.

It allows RaceIQ to:

• ship useful behavior before one user has much local history;
• improve globally from consented aggregate examples;
• adapt to an individual driver's tendencies;
• keep personal behavior data local by default;
• update shared and personal components independently;
• reset or rebuild the personal layer without replacing the shared package.

Personalization should initially be conservative.

A practical sequence is:

1. Use the shared model only.
2. Accumulate quality-eligible personal examples.
3. Evaluate a personal calibration or residual offline.
4. Activate only when it improves held-out personal sessions.
5. Keep the previous personal version for rollback.

RaceIQ should not claim that a model is personalized merely because it has observed a handful of laps.

The preferred long-term architecture is hybrid:

RaceIQ TypeScript/Bun process
├── Canonical telemetry and evidence engine
├── Deterministic rules and feature service
├── Model router and compatibility checks
├── Embedded ONNX Runtime for supported models
└── Optional managed local sidecar for models that need Python-specific support

Preferred order:

1. Use TypeScript for rules and simple formulas.
2. Use embedded ONNX Runtime for production ML where conversion is reliable.
3. Use a local sidecar only when the model or preprocessing cannot reasonably be embedded.
4. Use a remote model API only as an optional, explicitly enabled capability.

A local sidecar must have a controlled lifecycle:

• launched and stopped by RaceIQ;
• local-only communication by default;
• version and health handshake;
• bounded queues and timeouts;
• no direct simulator ownership;
• no independent interpretation of telemetry semantics;
• graceful fallback when unavailable.

The active compatible model packages should remain available offline.

No connection should be required to:

• start RaceIQ;
• collect telemetry;
• perform deterministic analysis;
• run installed local models;
• view previous analyses;
• use deterministic live messages.

Network-dependent features should fail independently without disabling local analysis.

Production models should be distributed as versioned packages rather than loose files.

A conceptual package is:

raceiq-model-package/
├── manifest.json
├── model.onnx
├── feature_spec.json
├── preprocessing.json
├── calibration.json
├── thresholds.json
├── model_card.md
├── evaluation_summary.json
└── checksums.json / signature

A package may contain multiple model variants when necessary:

models/
├── full-fidelity.onnx
├── reduced-no-tire-detail.onnx
└── reduced-distance-only.onnx

A package manifest should include concepts such as:

model_id
model_version
model_task
package_format_version
runtime_type and runtime_version
training_code_sha
training_dataset_hash
label_policy_version
canonical_schema compatibility range
telemetry catalog compatibility range
feature_set ID and version
supported games, cars, classes, tracks, or declared generality
required semantic IDs
accepted mapping types for each feature
minimum sample cadence and range coverage
missing-value policy
quality/eligibility policy requirements
calibration identity
threshold identity
personalization compatibility
release state
created_at
retired_at
artifact hashes and signature

The feature manifest should let RaceIQ determine before inference:

• Are all required semantic concepts available?
• Are their units and shapes compatible?
• Are direct, derived, or simplified mappings permitted?
• Is the observed cadence sufficient?
• Is the selected range quality-eligible?
• Does the package support this simulator or source type?
• Is a reduced model available?
• Must the model abstain?

Training may use Python-native files such as joblib, LightGBM, or PyTorch checkpoints.

Those research artifacts should not automatically become the desktop production format. The production package should prefer a portable and validated inference format such as ONNX, together with the exact preprocessing, feature, calibration, and threshold contracts required to reproduce the result.

RaceIQ can ship a small baseline set of broadly useful models with the application, for example:

• data-quality or anomaly screening;
• fuel residual prediction;
• a basic pace or degradation model;
• model-router and compatibility test fixtures.

The shipped baseline should remain small enough that RaceIQ does not become a multi-gigabyte download merely because ML support exists.

Additional packages can be downloaded only when useful for the user's installed games or enabled features.

Examples:

• simulator-specific model;
• oval-racing package;
• road-course technique package;
• endurance strategy package;
• supported car-class package;
• experimental advisory model.

A user who never enables a feature should not need to download its models.

A RaceIQ model registry should publish metadata before package download.

The client should be able to query:

model ID and task
latest compatible approved version
package size
supported RaceIQ/schema/catalog range
supported simulator/source range
required telemetry capabilities
release state
minimum application version
changelog
retirement or rollback status

The registry may be hosted by the RaceIQ project, mirrored, or packaged in releases. Inference itself should not depend on continuous registry access.

A model update should follow a staged process:

Check registry while idle
 ↓
Select package compatible with current RaceIQ version
 ↓
Download to temporary location
 ↓
Verify size, hashes, signature, and manifest
 ↓
Run package compatibility and smoke tests
 ↓
Stage the new model
 ↓
Activate atomically between sessions
 ↓
Retain the previous known-good package for rollback

A failed download, validation, or smoke test must leave the current model active.

RaceIQ should not replace an active model while a live session is running.

Updates may be:

• downloaded while idle;
• staged during a session without activation, if safe;
• activated after the session ends;
• manually deferred by the user.

The model manager should retain:

• active version;
• previous known-good version;
• activation reason and timestamp;
• package hash;
• compatibility status;
• failure or rollback reason;
• retirement state.

A model may be remotely marked as retired or unsafe, but the client should still apply a clear policy rather than silently deleting evidence or rewriting historical predictions.

Historical records must retain the model version that actually produced them.

Model packages should be capable of updating independently from the main RaceIQ application when their feature and schema contracts remain compatible.

A model must require an application update when:

• the runtime changes incompatibly;
• required feature extraction code is absent;
• the canonical schema range is unsupported;
• preprocessing cannot be described by the package contract;
• a security or package-format change requires new loader behavior.

RaceIQ should have one model router rather than letting every feature load arbitrary model files.

The router should consider:

requested task
active RaceIQ and schema versions
simulator and source kind
participant kind
car/class/track/conditions context
available semantic channels
mapping fidelity
observed cadence
quality and eligibility decisions
package release state
user feature settings
personal-layer availability

Possible routing outcomes are:

use full model
use reduced-feature model
use deterministic baseline
use shared model without personal layer
use shared model plus personal layer
use optional remote model
abstain with reason

The selected route and reasons should be included in the prediction provenance.

Training should occur offline from live inference.

A typical flow is:

Raw/canonical source evidence
 ↓
Versioned dataset builder
 ↓
Quality, eligibility, consent, and leakage filters
 ↓
Lap / corner / event feature views
 ↓
Labels and weak-supervision records
 ↓
Grouped train / validation / test splits
 ↓
Baseline and candidate training
 ↓
Calibration and slice evaluation
 ↓
Model package construction
 ↓
Registry review and promotion

RaceIQ may use a self-hosted training system. Production users should not need a paid AI or ML API for normal model inference.

RaceIQ should not upload an example and immediately mutate the shared production model.

Shared retraining should be trigger-based and reviewed.

Triggers may include:

• sufficient new quality-approved labels;
• material feature or outcome drift;
• a simulator protocol or physics update;
• a new car class or source type;
• degraded calibration;
• a newly supported feature set;
• a documented product requirement.

A reasonable starting review cadence is periodic, such as quarterly, with earlier retraining when a material trigger occurs.

Every training run intended for promotion should retain:

training code commit
configuration
input dataset IDs and hashes
feature-set version
label-policy version
split-policy version
random seeds where applicable
library/runtime versions
metrics and slice reports
calibration artifacts
candidate package hashes
review and approval outcome

RaceIQ remains local-first.

By default:

• telemetry stays on the user's computer;
• local analyses stay on the user's computer;
• the personal calibration layer stays local;
• no raw telemetry is uploaded for training;
• model inference continues without an account or network connection.

Separate permissions should exist for:

• personal local analysis;
• uploading structured derived features;
• uploading raw or canonical telemetry;
• uploading intervention or setup-change records;
• uploading driver annotations;
• uploading optional free text;
• using data for shared training;
• using data for evaluation or public benchmarks;
• retention and deletion terms.

Consent version and permitted-use state should travel with every contributed example.

Shared training should not require continuously streaming every raw telemetry frame to a server.

Preferred contribution forms are:

1. compact structured labels and intervention records;
2. derived feature rows with quality and provenance;
3. selected high-value event or corner windows;
4. complete canonical or raw sessions only under a separate explicit permission.

Uploads should be:

• compressed;
• deduplicated by content identity;
• resumable;
• encrypted in transit;
• bounded and rate-limited;
• performed while idle or after a session;
• cancellable;
• visible in a contribution history;
• removable where the data policy permits.

An optional local contribution queue can stage approved examples.

The queue should record:

example or artifact identity
consent state and version
size
source and feature versions
upload status
retry count
server receipt
retention category

A network failure must not interfere with recording, analysis, or local model inference.

Useful ML labels can be collected before a model exists.

RaceIQ should preserve objective change events such as:

• brake-bias adjustment;
• tire-pressure change;
• fuel or tire service;
• setup change;
• driver change;
• repair;
• other detected configuration or intervention events.

An intervention remains valid evidence even when the driver provides no annotation.

The preferred order is:

Adjustment detected
 ↓
Ask what the driver was trying to improve
 ↓
Ask the driver's perceived outcome
 ↓
Run or reveal RaceIQ's objective assessment
 ↓
Compare subjective and objective evidence

Showing RaceIQ's conclusion before asking the driver can bias the label.

Do not collapse an adjustment into one field such as:

adjustment_worked = true

Preserve:

observed intervention
intent
subjective outcome
objective measured outcome
confounding factors
attribution confidence
analysis version
consent state

Driver perception and objective telemetry may agree, disagree, or remain inconclusive. Disagreement is valuable data and should not be forced into a simple positive or negative label.

The first question-selection system can be deterministic.

Later, an active-learning policy may prioritize questions where:

• a meaningful intervention occurred;
• objective confidence is low;
• two candidate explanations disagree;
• the example fills a rare car/track/context slice;
• a personal model is poorly calibrated;
• the expected label value is high.

Question frequency should remain user-controlled and bounded.

Canonical telemetry allows common feature definitions, but it does not prove that every simulator produces identical data.

Differences may include:

• physics implementation;
• update rate;
• noise and filtering;
• source precision;
• tire detail;
• assists;
• weather behavior;
• parser behavior;
• native versus derived channels.

A safe progression is:

Simplified sources should follow an explicit policy:

exclude from the full-fidelity model
use a reduced-feature model
include with source-domain and missingness indicators

They should never be silently treated as direct, full-fidelity measurements.

The first production pilots should be selected for clear labels, measurable value, and low runtime cost.

Use deterministic fuel-per-lap calculation as the baseline, then predict a bounded residual using context such as:

• pace;
• caution or traffic context;
• fuel state;
• track and car;
• weather where available;
• recent eligible laps.

Output:

fuel per lap
fuel to finish
prediction interval
applicability and confidence

Use stable pace segments and eligible lap windows.

Output:

expected pace loss
falloff onset probability
prediction interval
supporting lap window

Begin with deterministic quality rules and robust statistics. Add a compact anomaly model only when it improves review precision without excessive false alarms.

Output:

anomaly score
affected range and channels
likely data issue versus driving outlier
confidence and reason

Begin with deterministic understeer/oversteer proxies. Train a calibrated model only after source-aware labels and expert or driver feedback are sufficient.

Output:

neutral / understeer / oversteer / indeterminate
confidence
source limitations
supporting features

Estimate recoverable time by corner or segment relative to a declared compatible reference.

The model should not claim causal setup advice merely because it predicts a time opportunity.

Defer until sufficient data and evaluation exist:

• large end-to-end sequence models;
• universal setup recommendation models;
• fully autonomous race strategy;
• cross-simulator unified models without slice validation;
• models that require constant cloud inference;
• models that speak directly without the live decision ledger.

Every production prediction should be a structured artifact.

A conceptual record includes:

prediction_id
model_id and version
package hash
feature-set version
source/artifact generation
session / participant / lap / corner / segment scope
input evidence and feature IDs
applicability result
quality and eligibility references
raw model output
calibrated output
confidence and uncertainty interval
shared-model output
personal correction
final bounded output
abstention or limitation reasons
inference runtime and latency
shadow/advisory/approved state
created_at

The prediction should not store final prose as its identity.

A deterministic renderer or LLM can create wording from the prediction and related findings later.

Models should move through explicit states.

Promotion should require:

• reproducible training;
• fixed leakage-resistant test sets;
• comparison with deterministic and simple statistical baselines;
• calibration evaluation;
• simulator, car, track, source-fidelity, and quality slices;
• performance and latency checks;
• failure review;
• shadow-mode review;
• model card and update history;
• rollback package;
• explicit approval.

A model should not become authoritative merely because one aggregate metric improves.

Monitor four distinct layers.

Useful review triggers include:

• a simulator update changes packet layout or physics behavior;
• an expected channel becomes sparse or unavailable;
• observed cadence falls below a package minimum;
• model confidence rises while delayed-label performance falls;
• one simulator, car, class, or track performs materially worse;
• deterministic findings and model predictions disagree unusually often;
• a personal layer no longer improves held-out personal sessions;
• live shadow output becomes too frequent, late, distracting, or redundant.

Local monitoring should remain useful without uploading telemetry. Aggregate monitoring should require the appropriate data permission.

The machine-learning model and the language model are different systems.

RaceIQ's LLM layer should receive a compact evidence packet containing:

• approved deterministic findings;
• approved model predictions;
• measurements and units;
• confidence and uncertainty;
• evidence IDs;
• applicability and quality limitations;
• counterevidence;
• prohibited unsupported claims.

The LLM may:

• summarize;
• prioritize;
• explain;
• tailor a drill or coaching plan;
• answer a follow-up question.

The LLM must not:

• infer directly from an uncontrolled raw telemetry dump;
• invent a measurement;
• claim a missing channel was observed;
• override a deterministic fact;
• strengthen a prediction beyond its confidence;
• bypass the live-engineer arbitration system;
• make a model update decision.

A local LLM or direct user-selected provider may be supported. A cloud LLM should receive only the minimum evidence required unless the user explicitly authorizes richer data.

The current #229/#232–#239 work establishes the evidence foundation. The operational ML work should be tracked separately rather than added to one existing issue.

Scope:

• versioned lap, corner, and event feature views;
• dataset builder;
• label contracts;
• split and leakage policy;
• consent-aware export;
• dataset manifests and hashes.

Scope:

• embedded ONNX Runtime or managed local sidecar;
• package loading;
• compatibility and applicability checks;
• reduced-model routing;
• deterministic fallback;
• prediction contract;
• CPU, memory, and latency tests.

Scope:

• package format;
• manifest and signatures;
• registry index;
• on-demand download;
• staging and atomic activation;
• rollback and retirement;
• offline behavior.

Scope:

• reproducible training jobs;
• baseline comparison;
• calibration;
• slice evaluation;
• model cards;
• package construction;
• promotion review.

Scope:

• local calibration/residual contract;
• minimum sample requirements;
• held-out personal evaluation;
• capped correction and guardrails;
• versioning, reset, and rollback;
• shared-versus-personal prediction provenance.

Scope:

• granular opt-in;
• contribution queue;
• compressed and resumable sync;
• raw versus derived permission;
• annotations and free text;
• retention, review, export, and deletion.

Scope:

• research/shadow/advisory/approved states;
• drift and health metrics;
• champion/challenger evaluation;
• rollback controls;
• live shadow review;
• interaction with #238 callout arbitration.

1. Land the canonical evidence foundation
 (#205, #229, #232–#237, and incremental #239 work)
 ↓
2. Add intervention/change records and optional driver debrief labels
 ↓
3. Build versioned lap, corner, and event feature views
 ↓
4. Build consent-aware dataset export and reproducible dataset manifests
 ↓
5. Implement local model package/runtime/router contracts
 ↓
6. Train one low-risk regression or anomaly pilot
 ↓
7. Run the pilot offline and in shadow mode
 ↓
8. Add package registry, safe distribution, rollback, and monitoring
 ↓
9. Promote useful models to advisory output
 ↓
10. Add a bounded local personal calibration layer
 ↓
11. Permit approved predictions to feed findings and live arbitration

ML does not need to exist before intervention records, driver labels, objective before/after assessments, and consent-aware exports are built. Collecting trustworthy labels early is more valuable than rushing a model onto weak data.

RaceIQ's ML runtime can be considered lightweight when:

• The application remains fully usable without a network connection.
• Normal inference runs on CPU without requiring a dedicated GPU.
• Models operate primarily on compact features and bounded windows.
• Heavy models do not run at raw frame rate unless the task explicitly requires it.
• Whole-field opponent inference is bounded by participant relevance and update cadence.
• Model packages load once and reuse state safely.
• Completed raw windows can be released from RAM after compact summaries are retained.
• Model download is on demand and independent of the core application where compatible.
• Failed updates leave the previous model active.
• Models are never replaced mid-race.
• A deterministic fallback or explicit unavailable state exists.
• Missing and reduced-fidelity sources use explicit routing or abstention.
• Personalization is a small bounded layer rather than full on-device retraining.
• Uploads are optional, minimized, compressed, resumable, and kept out of the live path.
• Model predictions pass through quality gates, findings, and live arbitration.

The RaceIQ ML preparation branch currently focuses on the trusted evidence foundation through deterministic findings.

The following operational ML areas are planned but should not be presented as already implemented:

• production local model runtime;
• ONNX package loading and model routing;
• shared model registry and download system;
• safe activation, rollback, and retirement;
• per-driver residual or calibration layer;
• consent-aware training-data synchronization;
• reproducible shared training service;
• model drift monitoring and promotion workflow;
• complete shadow deployment through #238;
• production model pilots.

The current work is still valuable because these systems require stable telemetry semantics, quality, context, provenance, hierarchy, findings, and parity before they can be trustworthy.

RaceIQ should not become a heavy cloud ML client that streams every telemetry frame to a server.

The intended end state is:

Local canonical evidence and deterministic authority
 +
Small downloadable task models
 +
Optional local driver calibration
 +
Opt-in shared training and model updates
 +
Safe shadow/advisory promotion
 +
Evidence-grounded optional LLM explanation

This keeps the normal product fast, private, offline-capable, and understandable while still allowing the shared system to improve over time.