Parts Intelligence
Working private toolMade a repair shop's own inventory trustworthy and queryable, and let a tech identify a part by photographing its label.
At a glance
- Outcome: A repair shop’s own inventory became trustworthy and queryable across 30,000+ assets and 2,300+ models: one dependable identity per part, duplicates collapsed, and a compatibility store that answers “does this fit?” with a confidence level attached.
- Status: Working private tool. The reverse-engineering and deduplication carried forward into the shop’s internal rebuild; the compatibility and identification work stands on its own.
- Role: Solo, built alongside my repair role.
- Stack & libraries: Python, SQL, nightly ingestion jobs, and an on-device vision model for part identification.
- Source: Private employer tooling; this page is the case study, with vendor and internal system names generalized.
- Validation: Reconciliation checked against known-good records, with identity traced across shipment and receipt tables where assets were linked; the identifier was used in the field by techs rather than only in testing.
- Limitations: The identifier is barebones. Confidence scoring is per-source rather than per-claim, so a well-sourced wrong fact still scores well.
Overview
The medical-device service shop I worked for ran on a legacy inventory app with no real API and two internal ID systems that disagreed with each other. The Repair Shop Automation tooling kept day-to-day work moving. This is the data work meant to outlast it, making the shop’s own inventory trustworthy and queryable and answering parts questions the legacy system never could. As with that writeup, vendor and internal system names are generalized.
What I built
- Reverse-engineering the inventory data: nightly pulls of the legacy app’s database exports into a queryable store, reconciling its two disagreeing ID systems so a part or asset has one dependable identity.
- Asset deduplication: collapsing the duplicate and near-duplicate records that accumulated through the legacy system’s quirks into single canonical entries.
- A parts-compatibility store: which parts fit and substitute for which, fused from shipment records, service-manual PDFs, email archives, supplier and parts-shop listings, and the firmware reverse-engineering work, with per-source confidence scoring so a fact’s reliability travels with it.
- A vision-LLM part identifier: a field tech photographs a part’s label and an on-device vision model identifies it, feeding the compatibility store. Barebones, but it was already useful in the field.
Status
The reverse-engineering and deduplication carried forward into the shop’s proper inventory rebuild, an internal replacement led by another engineer. The compatibility and part-identification work stands on its own. I pulled this out of the Repair Shop Automation writeup so the durable data work isn’t buried behind a label printer.