Inspiration
At Maruti Suzuki, in manufacturing quality and engineering, I watched one part live several lives. Engineering called it one thing in the BOM, procurement bought it under another name, and every product line had its own supply team. When engineering reduced that part's quantity, the people buying it never heard. Nobody made a mistake: the systems simply don't share one identity for a part. That gap is where margin leaks, and finance only sees it at year-end.
What it does
OmniPart RECON is an evidence layer between engineering BOMs and procurement spend.
- Links every purchased SKU to its engineering part using two signals: names/specs and production behavior.
- Reveals true product cost: in our demo, linking one renamed motor moved a product's material cost from about \$17 to \$97 per unit.
- Reconciles BOM vs reality between stock counts. It caught a gear the BOM says is used twice per unit but the shop floor now uses three times.
- Sizes exposure honestly: mutually exclusive buckets, P10–P90 ranges, and a money ladder (indicative → qualified → approved → realized).
- Closes the communication gap: a resolution board routes each finding to its owner, and messages are drafted for engineers, buyers, plant managers and executives (templates or Claude).
- Track 1 unlock: finds near-duplicate parts across product teams and computes the net saving of merging them, including when not to merge.
How we built it
For each engineering part (j), expected monthly demand comes from the BOM and production: $$E_{j,t} = \sum_{p} q_{p,j}\, U_{p,t}$$ where (q_{p,j}) is the BOM quantity and (U_{p,t}) the units of product (p) built in month (t). A SKU's behavior score compares its rolling 3-month purchases to (E_j) on levels and on changes, squared, then multiplied by a volume-plausibility check against demand not already covered by other suppliers. The name score uses TF-IDF on character n-grams plus overlap of spec numbers. A decision cascade accepts a strong name match, lets behavior rescue a link only when it clearly beats the runner-up, and otherwise leaves the SKU unresolved.
Reconciliation uses physical counts: $$\text{Observed}{[t_0,t_1]} = C{t_0} + \text{Purchased}{[t_0,t_1]} - C{t_1}$$ Change-point detection on Observed / Expected finds unrecorded BOM changes, and NNLS estimates the implied quantity per unit with confidence intervals. Link confidence comes from 300 block-bootstrap resamples and Wilson-calibrated bands.
Stack: Python (pandas, NumPy, SciPy, scikit-learn), a FastAPI server, ReportLab PDFs, optional Claude drafting via the Anthropic API, and a single-file JavaScript/SVG front end that also runs fully offline. 18 automated tests.
Results (synthetic data)
On a blind holdout company with settings frozen beforehand, name-only matching found 65.8% of links, behavior-only 36.8%, and RECON 97.4% with zero false links. On a deliberately messy third company, RECON still made zero false links, abstaining instead of guessing.
Challenges
- Lumpy purchasing hides the demand signal. Rolling windows and a residual-demand volume check fixed it.
- Averaging the two signals made results worse under noise, so we replaced it with a cascade.
- Look-alike parts with identical demand patterns can't be separated by behavior, so we flag them for a human.
- ERP consumption is often calculated from the BOM itself, which makes it useless as evidence. We built a detector for it.
What we learned
The hard part isn't the matching; it's trust and communication. A finding nobody receives, nobody trusts, or nobody owns changes nothing, which is why the workflow matters as much as the model.
What's next
Pilot on one real plant's exports, then Track 2: attach warranty and customer feedback to parts so standardization decisions protect what customers value.
Built With
- anthropic-claude-api
- claude
- css3
- fastapi
- html5
- javascript
- numpy
- pandas
- pytest
- python
- reportlab
- scikit-learn
- scipy
- svg
- uvicorn
- velocity-ai
