Decision 31: Yukart informs the driver, never controls the car; the goal in OVERVIEW

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DDwfd6Ki8UfG4hK6W5YpJz

OVERVIEW.md

@@ -3,6 +3,10 @@ type: reference
 ---
 # Project Yukart Overview
 
+**The goal:** take the car's telemetry, add more of our own, and do the calculations off the car's
+ECUs, so the results inform the **driver**. Yukart controls the driver's information, never the car
+(architecture decision 31).
+
 A Mitsubishi Z27AG Colt Ralliart, plus  
 
 A Jetson Orin Nano that can:

docs/ARCHITECTURE.md

@@ -380,3 +380,4 @@ rewriting the document.
 | 28 | Every Orin → tablet sender caps its socket (`SO_MAX_PACING_RATE`, ~5 MB/s); unpaced bursts stall the USB link for seconds | **Proposed** | 2026-10-11 |
 | 29 | `svc-vision` is Python: camera pipelines and inference live in that ecosystem. Exception to 5 | Accepted | 2026-10-12 |
 | 30 | The car's CAN broadcast is the source for every displayed vehicle value. OBD-II (K-line, ISO 9141-2, through the Bluetooth ELM327) is calibration, recorded beside the frames; a value proven absent from CAN may be displayed from OBD-II, and keeps its `obd_` name either way. GNSS speed is shown beside the decoded speed, to show their error. The ELM is the Orin's only way onto the K-line, so DTC scans go through it too; it is reached over classic Bluetooth serial (SPP, no pairing), BLE only if it proves as easy | Accepted | 2026-10-13 |
+| 31 | Yukart informs the driver; it never controls the car. It extracts the car's telemetry (CAN, OBD-II), adds its own (GNSS, IMU, camera), and does its calculations off the car's ECUs; the results go to the driver (display, voice). No actuation of any kind (locks, lights, throttle), by CAN transmit or by wiring into the car's switches. Decision 3's "no TX on CAN" follows from this rather than only from caution | Accepted | 2026-10-15 |