Top Tier Tune builder — how filtering actually works, certainty by category, and why accessory lists must not read as “fits your car.”
Worked example: Bosch EV14 1000cc ×4 on a Chaser/Soarer build after a plug-in ECU is selected.
| Step | Detail |
|---|---|
| Vehicle shown | Toyota Chaser / Soarer (1990–1996) — typically 6-cyl |
| SKU shown | 101-0052 Bosch EV14 1000cc injectors (×4) |
| What code compared | ECU/path visibility — not vehicle make/model/engine |
| Cylinder mismatch | ×4 pack vs common 6-cyl — no quantity/engine gate |
| Missing checks | Connector style, rail fit, flow vs HP/duty, fuel pump, return |
| Honest label | Available for custom builds — not a suggested direct-fit part |
| Vehicle-fit certainty | ~10% |
getGroupItems() never reads build.vehicle for accessory groups. Vehicle is used earlier to pick the plug-in ECU and to note harness options on plugin path.
| Layer | Compared fields | Certainty % | Note |
|---|---|---|---|
| Vehicle → plug-in ECU | build.vehicle vs plug-in catalog rows | 90 | High when year range matches a published Link application |
| ECU → essentials / harness | path, platform, canConnector, ecuOnly, bundle includes | 75 | Strong ECU-side match; some install notes (e.g. G5 CAN repin) |
| ECU capability gates | meta.diCapable, ethrottle, needsBLoom, needsELoom, onboardWideband | 85 | Correct for “can this ECU drive it?” — not chassis fit |
| Accessory catalogs | Almost no build.vehicle fields — only ECU/path filters | 20 | Availability for customization, not verified vehicle fitment |
Estimated vehicle-fit certainty by filter layer
Certainty = confidence that “this part is a correct direct fit for this chassis,” not that the SKU exists or works electrically with the ECU.
| Category | Example | Vehicle-fit % | What is filtered | Support risk |
|---|---|---|---|---|
| Plug-in ECU (vehicle step) | Toyota Chaser / Soarer → matching plug-in | ~90% | Make / model / year fitment table | Low if year is in published range |
| Essentials / harness | A/B loom, CAN Lambda, expansion | ~70% | path + platform + connector (+ vehicle note for harness on plugin) | Medium — electrical match, install still shop work |
| Sensors | MAP, E85 content, oil pressure | ~25% | Walkthrough + ECU capability only | Adapters, bung location, calibration — not OE fit |
| Boost control | 3-port / 4-port solenoid | ~20% | Listed for any compatible ECU path | Plumbing, wastegate style, tune required |
| Injection & ignition | Bosch EV14 1000cc ×4 (101-0052) | ~10% | Catalog visibility only (no cylinder count check) | Critical — connector, count, duty cycle, fuel system, rail |
| E-Throttle | External controller / TB kit | ~15% | requiresEthrottle on ECU meta | Pedal, TB, wiring not vehicle-validated |
| Displays & data | MXS Strada, CAN gauge | ~30% | CAN path / splitter prompts | Mount + CAN config; electrical OK-ish |
| Power & controls | Razor PDM, keypads | ~20% | Shown with build ECU | Full custom electrical architecture |
“Matched to your vehicle” + “Only showing options that fit this car and ECU” implies chassis validation for every listed SKU.
Customers reasonably expect injectors/sensors to be application packs. They are not.
No per-vehicle accessory matrix at runtime. accessory-compat style data is unused for these groups.
Injector packs lack cylinder-count, connector, and duty-cycle gates — easy to show a ×4 pack on a 6-cyl platform.
Soften to vehicle context + honest split: ECU/harness matched where we have data; accessories are customization options, not direct-fit guarantees.
Cite more SKUs/vehicles in a working session to decide: hide vs warn vs require “I understand” acknowledgment; whether injectors stay in the builder at all; and priority for a real accessory fitment table.