How TuneView Uses AI Without Letting It Invent Tuning Data

// 01 - THE WRONG AI METRIC

The easiest way to make an AI knowledge base look impressive is to count everything it writes.

That is also how a technical knowledge base becomes dangerous.

A paragraph can sound informed while still being unusable. It can name the right engine family, explain the right failure mode, and even include plausible values. But if it cannot name the parameter, identify the table or scanner path, state the action, define where the guidance applies, and point to canonical evidence, it is not a TuneView guided edit. It is prose.

On July 13, 2026, we ran a live quality-control pass over TuneView's calibration knowledge base. The first verified snapshot contained 2,142 rows in pending_review. At the end, a fully paginated read returned zero.

That does not mean 2,142 rows were waved through. It means every row selected for review was forced to a terminal decision: active or rejected. No row was allowed to remain pending because it looked difficult, because it had a lot of text, or because another agent might understand it later.

This is what we use AI for. It is also a useful example of what we refuse to let AI do.

// 02 - THE HARD BOUNDARY: PARSING IS NOT INFERENCE

TuneView begins with a deterministic parser. The parser reads what is actually present in an uploaded log or calibration artifact: channels, values, units, timestamps, operating regions, and the relationships the code is explicitly designed to calculate.

AI does not get to rewrite that measurement truth.

We use AI after deterministic extraction for tasks where reasoning is useful:

• organizing source-backed tuning knowledge into a consistent shape
• comparing a measured condition with known platform behavior
• identifying missing evidence or contradictory guidance
• converting validated research into a parameter, table path, action, and verification step
• challenging a specialist's proposed activation in an independent audit
• explaining a finding in language an owner can follow in VCM Scanner or VCM Editor

We do not use AI to:

• replace the parser
• invent a channel that was not logged
• infer a missing parameter or table path and store the guess as fact
• move a URL from narrative notes into canonical provenance without validating it
• turn one client's observed value into universal calibration guidance
• publish its own work merely because the work sounds complete

Inference can help form a research question. It cannot silently become stored truth.

Real TuneView verdicts: the parser supplies measured values; the system can mark an AI-guided revision improved, unchanged, or worse.

// 03 - WHY "DO BACKGROUND RESEARCH" DID NOT WORK

The research agents already had a standing instruction to validate and expand the KB when no other work was active. In practice, that instruction was too open-ended. An agent could decide it had done enough, classify rows without resolving them, or return a batch with blank fields for somebody else to finish.

We changed the unit of work.

Each assignment became finite and auditable:

• one named platform or an explicitly cross-platform batch
• usually 18 to 25 exact rows
• exact ordering rules, normally oldest first
• no family drift outside the assignment
• every selected ID must end active or rejected
• exact mutation and readback evidence in the issue comment
• no side spreadsheets, snapshots, or shadow datasets
• live KB APIs as the source of truth

The agents were not asked to "improve quality." They were asked to resolve a specific bounded set of rows under a written gate.

That difference mattered. It turned background intent into work that could be checked independently.

// 04 - THE FIELD GATE

For this pass, rich prose was not enough. A promotable guided-edit row needed, at minimum:

1. A specific parameter_name.
2. A real table_name or navigation_path.
3. A concrete correction_method or action.
4. Applicability and safety context.
5. A nonblank canonical source.
6. A terminal moderation readback proving the row was active.

Blank parameter, table/navigation, action, or source fields caused rejection unless the row could be corrected immediately from validated evidence. URLs buried in notes did not satisfy the source field. "Needs tool verification" did not satisfy an exact table path. A client log observation did not become general guidance merely because it was technically interesting.

The public serving rule is separate and simple: only active, non-deleted rows are served. Pending and rejected rows do not inflate the public count.

The July 13 quality-control run used finite row assignments, a required-field and provenance gate, and independent readback before a row could remain active.

// 05 - THREE ROWS THAT MADE THE CUT

After the cleanup, a read-only pass paginated the active KB and applied the same article evidence gate. It found 173 active candidates with a parameter, table or navigation path, action, context, and nonblank canonical source. Here are three exact examples.

WOT full-throttle enable threshold

Row: 96c14ae9-789d-41fe-b6ea-18921fb9b3b9

Parameter: WOT Full Throttle Enable TPS Threshold

Table: Transmission > Auto Shift Speed > Full Throttle Enable / WOT Shift Table Selects

Action: Set Full Throttle Enable to 90-95% TPS for drive-by-wire Gen5 applications. Log actual TPS at pedal-to-floor to verify the threshold is achievable with the specific throttle body and pedal mapping in use.

Verification: Verify WOT shift table activation by monitoring shift PID while performing WOT runs.

Source: HPTuners EU documentation - vcm_editor_parameters_gm_trans_shiftspeed.htm

This row is useful because it does not stop at a target value. It identifies the exact table, limits applicability to drive-by-wire Gen5 applications, and requires the user to prove that the threshold is reachable on the actual vehicle.

Flex-fuel enable path

Row: cc34faeb-e338-42a2-bb51-fcd880440ed5

Parameter: HPTuners Flex Fuel Enable Path and Required Parameters

Table: Engine > Flex Fuel > Flex Fuel Enable

Action: Set Flex Fuel Enable = Enabled. Verify sensor input pin matches physical wiring. Log Fuel Ethanol Content % to confirm sensor reading. Populate Alcohol Spark Correction and PE Fuel Multiplier vs. Ethanol Content.

Verification: Verify AFR targets at WOT with wideband lambda sensor on E85, followed by light-load fuel-trim logging.

Source: HPTuners EU documentation - vcm_editor_parameters_gm_eng_flexfuel.htm; HPTuners forum community (forum.hptuners.com)

The difference between this and generic "enable flex fuel" advice is the chain of proof: physical input, scanner reading, dependent tables, wideband verification, and follow-up trims.

Torque reduction during shifts

Row: 42f6b0ec-e8c4-4b40-b535-ca981af6f481

Parameter: Torque Reduction vs Torque vs Shift - Normal/Performance/Downshift Tables

Table: Transmission > Torque Management > Torque Reduction vs Torque vs Shift

Action: First check whether measured torque exceeds the table axis. If it does, extend the range; otherwise reduce the high-torque row by a bounded 5-10% and increase base shift pressure to match the higher torque the clutch must carry.

Source: HPTuners EU documentation - vcm_editor_parameters_gm_trans_tm.htm

The row connects symptom, table-domain check, bounded change, and companion action. It does not jump directly from "mushy shift" to a universal percentage.

// 06 - ROWS THAT DID NOT MAKE THE CUT

The rejected examples are more revealing because several looked excellent at first glance.

Rich prose is not a data contract. Required fields and canonical provenance decide whether a row can serve users.

Rich content, wrong provenance field

Row: 70606a5f-56fc-4ab0-90b6-51561f25b7ea

Parameter: ECT fail-safe default before warmup, fan, fuel, or spark grading

Table: Engine Input > Engine Coolant Temperature (ECT) Sensor > Engine Coolant Temperature (ECT) Sensor Default

Navigation: VCM Scanner: Engine Coolant Temperature (ECT), ECT Sensor Voltage, ECT DTC Fault Active, DTCs P0117/P0118.

Source: null

The row had a parameter, table, scanner channels, DTCs, a safety-first action, and source URLs inside its notes. It was still rejected. Canonical source was null, and the exact fail-safe value was calibration-specific.

The content looked rich. The data contract failed.

An explicit research question stored as if it were knowledge

Row: 383da62f-6b58-4210-98f9-f97211eac1d2

Category: ethanol_detection

Parameter: null

Table: null

Navigation: null

Action: null

Source: null

Its notes said that the exact table axis and values required a stock L83 E92 .hpt file. That is a valid research requirement. It is not a finished knowledge row. The system rejected it instead of asking AI to guess the missing structure.

A sensible diagnostic gate without canonical evidence

Row: 458d0df7-1f54-4d72-9cd9-a2ca74dafac9

Parameter: Ford BARO sensor substitute behavior before altitude/load-based fueling edits

Table: BARO Sensor Default / MAP Sensor Default / MAP or BARO DTC Minimum/Maximum

Action: Hold MAF transfer, VE, and boost-target changes until MAP/BARO validity is confirmed; repair and re-log before tuning load-based tables.

Source: null

That is conservative diagnostic advice. It was still rejected because the exact Ford substitute value remained unverified and canonical source was blank. Being directionally safe is not the same as being complete enough to serve as platform-specific knowledge.

// 07 - THE PROMOTION AUDIT DID ITS JOB

The strongest evidence came from rows that had already been promoted.

Two Mopar fail-state rows were initially activated because their parameter, table, navigation, and action fields were unusually complete. An independent audit found that canonical source was null and the URLs existed only in notes. Both were moved from active to rejected.

Later, four cross-platform diagnostic rows received the same audit. All four were also active, all four had detailed content, and all four had source: null. The audit reversed every activation.

One of them, e878aa0d-1300-45a7-809f-ff6b599609b3, contained:

• parameter: Sensor fail-soft default substitution triage before calibration edits
• table: Sensor Default / DTC Minimum / DTC Maximum strategy fields
• navigation: VCM Scanner channels: sensor value, sensor voltage, DTC Fault Active, current/pending DTCs
• notes containing official and technical URLs
• canonical source: null

It was rejected.

No marginal row stayed active merely because its prose looked professional. The audit was not a rubber stamp; it changed the live dataset.

// 08 - THE LAST 13

The final unrestricted sweep found 13 pending rows. Every one contained technical narrative. Every one was also blank for parameter_name, table_name, navigation_path, and source.

Examples included supercharger workflows, E85 dual-file discussion, HPFP monitoring, OBD readiness guidance, injector characterization, and AFM inhibit behavior. Several explicitly said that exact values or paths still required stock-file verification.

All 13 were rejected. Readback found all 13 under moderation_status='rejected'. A fresh, fully paginated pending query returned zero.

This is the parser-versus-inference boundary in its clearest form. AI could have generated plausible labels and guessed likely HPTuners paths. We did not let it. Missing evidence stayed missing, and unfinished research stayed out of the public KB.

// 09 - WHAT THE NUMBERS MEAN

At the close of the run, TuneView's public stats endpoint reported 16,939 active rows, 918 categories, and 311 engine families. The app and API both returned 200.

Those numbers are not the quality claim. The process is.

The quality claim is that:

• pending and rejected rows are not publicly served
• a pending queue of 2,142 reached zero terminally resolved rows
• independent audits reversed activations that failed provenance
• blank required fields were not filled by inference
• public row count was allowed to fall when live rows failed the gate
• no side dataset was used to make the result look cleaner than the canonical KB

The strict active-row evidence pass also exposed the next gap: the six examples it could safely select were GM rows. It did not produce Ford examples without lowering the canonical-source and complete-action gate. That is not something to hide. It is the next bounded quality assignment.

This case study is a pending-queue cleanup and promotion audit, not a claim that every historical active row has now been revalidated under the newest field contract. Quarantine and legacy-active review are separate work, and rows should add to the public count only when they survive those gates.

// 10 - AI WITH NARROW AUTHORITY

The lesson is not that AI should be kept away from technical data. AI made this pass possible at a scale that would have been punishing to review manually. Specialists handled platform lanes. Research agents handled residual sets and independent audits. The system paginated live state, froze exact IDs, applied decisions, and read the results back.

The lesson is that AI needs narrow authority.

Let it research. Let it normalize. Let it compare. Let it explain. Let one model challenge another model's conclusion.

Do not let it replace deterministic extraction. Do not let it infer missing evidence into existence. Do not let it publish its own answer because the answer sounds good.

A larger tuning database is not automatically a better one. A useful knowledge base is the part that survives being told no.

...and yes - this entire white paper was written with Codex 5.6 Sol. My daily driver models for this whole project has been a mix of Claude Opus and Fable. Thought you might get a kick out of that - especially that last section. --TuneView