Parts Intelligence

At a glance

• Outcome: Reconciled 30,000+ assets across 2,300+ part and equipment models into dependable part identities, with duplicates collapsed and confidence levels on compatibility.
• Status: Working private tool, built during the Jan 2025 to Aug 2026 Sonovision role. Another engineer’s internal rebuild kept the reverse engineering and deduplication; compatibility and identification stand alone.
• Role: Built solo alongside a repair role; reviewed AI-assisted implementation.
• Contribution: I defined the identity, deduplication and confidence rules; AI drafted the Python and SQL, and I reviewed it.
• Validation: 273 hermetic tests cover the matching and merge rules, and I audited samples of merged duplicates and compatibility claims by hand.
• Stack & libraries: Python, SQL, an on-device vision model.
• Source: Private employer tooling, with vendor and internal names generalized.
• Limitations: The identifier is barebones. Confidence is scored per source rather than per claim, so a wrong fact from a good source still scores well.

Parts Intelligence answers whether a part fits a machine, with a confidence level attached. At Sonovision, that information was spread across an inventory app with no direct data access, two internal ID systems that didn’t match, shipping and receiving records, service-manual PDFs, emails and supplier listings. I built a tool that pulls all of it into one searchable place.

I loaded the inventory app’s nightly exports into a SQL database and matched up the two ID systems. Then I merged duplicates and near-duplicates across 30,000+ items and 2,300+ part and equipment models until each item had one identity. I checked the results against records the shop already trusted and traced linked items through shipping and receiving records to confirm the merges.

On top of that is a record of which parts fit which machines and which parts can substitute for others. It combines shipping records, service manuals, emails, supplier listings and findings from my firmware work. Every fit claim lists its source and a trust level for that source. A field part identifier reads a photo of a part’s label with an on-device vision model and adds the result. Techs used it on the job. The identifier is basic. The scoring has a known gap: trust is set per source, not per claim, so a wrong fact from a good source still scores well.

For example, with a made-up part number: a shipping record lists a probe as 2210400-7. A service manual prints 2210400 7. A label photo reads 221O400-7, with the letter O in place of a zero. Removing spaces, dashes and periods turns the first two into 22104007, which makes them one part with both sources kept as separate evidence. The system keeps O and 0 distinct on purpose, because that kind of misread should be caught and flagged, not quietly accepted. The photo’s reading is a close match, not an exact one. At a score of 0.92 or higher, the tech sees which machines the part fits right away. Between 0.82 and 0.92, the part still matches while the app offers “did you mean” alternatives. Below 0.82, or when no part number can be read, the photo goes into a review queue. A person approves, edits, skips or rejects each entry. An approved part is added with a note that it came from the field and a link to its photo. Trust adds up across sources. One recorded shipment is worth about 0.5 on its own, while a manual or email mention counts for less. Serial numbers are kept separate from part numbers. A serial-number pattern shared by many parts counts only as weak evidence.

The record cleanup and duplicate merging now live inside another engineer’s rebuild of the shop’s systems. The fit records and the part identifier remain a separate private tool. Repair Shop Automation covers the daily workflow tools built alongside it.