Grading a Tune Like a Jobsite
Two documents, one shape
There are two documents I've spent a career reading: the construction schedule update and the engine datalog. On the surface they have nothing in common. One tracks steel and concrete across months; the other tracks air, fuel, and spark across milliseconds. One arrives as a thousand activities in a scheduling system; the other as a few dozen channels sampled from a running engine.
They are the same document. Each one is a record of a plan colliding with reality, and each one rewards exactly the same reading discipline — which is why a project-controls guy ended up building a tuning-analysis platform and didn't find it strange.
Baseline, actual, variance
A schedule has a baseline: what you said would happen. An update has actuals: what did. The space between them is the variance, and the variance is the story. Everything else is formatting.
An engine calibration is a baseline in precisely the same sense — commanded fueling, targeted timing, expected airflow. The datalog is the update: what the engine actually delivered, sampled continuously while it worked. And you don't read either document by scrolling through it and forming an impression. You interrogate it. Where did actual diverge from plan? By how much, how often, and trending in which direction? Is this variance noise, or is it signal that the plan itself is wrong?
A scheduler who vibes through an update misses the slip that eats the end date. A tuner who vibes through a log misses the variance that eats the engine. Same failure, different invoice.
Triage: P1 through P4
On a jobsite, findings get triaged, because attention is finite. Life-safety first — always, no discussion. Critical-path items next, because they move the end date. Then quality. Then cosmetics, if there's daylight left. Anyone who's run a punch list knows the format: not "here are your problems" but "here is the order in which your problems deserve you."
TuneView returns findings the same way: graded, with revision guidance prioritized P1 through P4. A P1 is the finding you deal with before the next pull; a P4 is polish for when the important things have gone quiet. The ranking matters as much as the findings, because an unprioritized list of forty observations isn't guidance — it's homework. Generating observations is easy. Ranking them honestly, against evidence, is the actual work, and it's a measurement problem before it's anything else.
Read-only, on purpose
TuneView never touches the ECU. It reads the datalog, grades the calibration, and hands back findings — the tuner stays the one making changes. That's the most jobsite thing about it: a scheduler doesn't swing hammers. The schedule changes what the people holding the tools do next, and that's the entire mechanism.
Inside the platform, the same principle again: the parser is the decision layer. The component that measured the log is the component that makes the calls, and the AI's job is to explain those findings in plain language — it doesn't get a vote. If that division of labor sounds familiar, it's the one I argue for in What Project Controls Really Do: the record decides, the narrative explains, the human acts.
I didn't set out to build a scheduling philosophy into a tuning product. It's just what happens after twenty-plus years of watching plans meet reality for a living: you stop trusting any account of a machine — building or engine — that can't produce its own numbers.