My car has been grading itself since 2018. It keeps throwing the grades away.

Last week I left the Honda dealership with a 2018 Accord Sport, the 1.5-liter turbo model. It came with high mileage and the potential for several well-documented issues. One issue caught my eye: this model’s engine has oil dilution issues.

Honda’s remedy for the fuel-in-oil problem was to bundle an engine software update because the cause is thermal. The patch changed the engine’s temperature-control strategy: warm-up behavior, operating targets, and when the ECU decides the engine is hot enough. Honda can validate that calibration across a test fleet, but that still doesn’t tell me how a high-mileage Accord behaves through a Maryland winter. The question I care about is narrower: does my particular car actually warm up adequately in Maryland weather, and what happens over time when it doesn’t?

Years before I came across this car, it was already grading itself. While driving, modern cars run self-tests on emissions-related hardware: catalyst efficiency, oxygen sensors, etc. Each test produces a measured value, the manufacturer’s own limits for it, and a pass or fail. Some run constantly; others wait for conditions that might not come around for days. Then it writes the new results over the old ones… What if we flipped that dynamic?

I say: keep them, because failure was never the interesting part. A fault code is just a test that finally failed. I want to capture the trendline before that, the result quietly walking towards the test’s failing limit. From what I can tell nobody logs that walk; the car only keeps the latest result and the scan tool reports the value blindly and moves on. Mechanics have read Mode 06 this way for over a decade, always in the present tense. That’s not an oversight; it’s the spec working as intended. OBD-II is a compliance instrument, built to answer a regulator’s question: is this car, right now, polluting more than it’s allowed to? A present-tense question gets a present-tense answer: one slot per test, and the whole ecosystem of tools and workflows has been coupled to it.

Additionally, the typical consumer scan-tool workflow barely scratches the surface. Most shelf tools and phone apps never leave Mode 01 (live sensor data). Mode 06 sits one channel over, carrying graded self-tests with pass/fail reference ranges. Lower still? Raw frames straight off the CAN bus, manufacturer broadcasts with low/no public documentation; the modules are chattering to each other in a cryptic dialect Honda never published. There are no locks on the door, but no signs on them either. Just how much is down there, how little of it anyone keeps, and what you’d gain by keeping it - that’s the thread I’ll pull in later posts.

The manufacturers already operate on a time axis, too. Modern connected cars do keep telemetry, it just flows upstream, to the OEM’s servers, feeding warranty analytics and fleet engineering on terms you agreed to somewhere in the infotainment EULA. I don’t think that’s conspiracy so much as incentive gradient: OEMs gain little from sharing longitudinal data with the owner, scan-tool vendors prioritize diagnostic sessions focused on the car’s present state, and regulators get the snapshot they asked for. Nobody in that chain is against the time axis; the incentives just don’t line up around giving the owner this particular one. And the missing capability doesn’t require a new sensor or a new protocol: the car already produces the measurement, the ECU already supplies the limit, and commodity hardware can preserve the history. That’s not a technology gap. It’s an incentives gap, and incentives gaps are exactly where a fleet-of-one hobby project can live.

So the plan is deliberately scoped: keep every reading my car produces, on a time axis, and watch the margins. Commercial trend tools have to learn what “normal” looks like across thousands of vehicles; this works on a fleet of one precisely because Mode 06 ships the manufacturer’s own limit inside every record. What a fleet of one doesn’t give me for free is a population baseline, so I have to characterize normal variation from this car’s own history. A healthy monitor doesn’t sit still; it bounces with coolant temperature, fuel quality, and season, and until I know the width of normal bounce for this car, every cold snap looks like a dying catalyst. In control-chart terms: Honda gives me the spec limit for free inside every record, but I have to establish the process variation myself, from months of my own data. The resulting history should be captured continuously, stored durably, and reproducible by a stranger.

In maintenance terms, this is a small condition-based monitoring system: inspect the measured health indicator while the component is still functioning, rather than waiting for a binary fault declaration. Industrial systems do this routinely; the interesting question is how much of the same idea can be recovered from diagnostic data a consumer vehicle already produces. The bet is that a monitor drifting toward its limit is visible months before a code sets. And in my case, can monitoring this data give me early warning of what chronic cold running does to this engine, before the engine light does?

I went looking to buy this before I went looking to build it. No luck there, so I started building it. My first attempt framed the bytes wrong, which I only noticed when I checked my output against python-OBD - a story for the next post. I rewrote my decoder in Rust with equivalence against that same reference as the acceptance bar. The project is packaged so nix build produces the exact binary I run, rather than leaving the toolchain and dependency environment as another uncontrolled variable.

One caveat: the hardware hasn’t arrived, so none of this has met a real car yet. The first thing I’ll learn is whether this ECU volunteers enough Mode 06 to be worth charting; if it doesn’t, whatever’s worth watching may be hiding further down, on channels with no names. The car’s been keeping score since 2018, but this time I’m writing it down.