Inspiration
Ask a manufacturer what one product really costs and you get three different answers. The bill of materials (BOM) says one thing, purchasing spend says another, and supplier part names never match. Without a clean link between them, nobody can price a swap, defend a savings number, or tell which rules affect which parts. We built PartLink for Corporate Track 3, BOM Cost Linkage.
What it does
PartLink links every BOM line to the spend that actually bought it, then makes the savings real.
- Linking: it matches messy supplier text to BOM parts and routes each link by confidence. High confidence is auto-accepted, the middle goes to a human review queue, and low confidence stays unmatched.
- Savings you can defend: a savings ledger tracks every dollar as identified, approved, or realized, and every sourcing rule carries a source.
- Dated rules: we join dated regulations to spend, so the cheapest swap is also one you are allowed to buy. This is not forecasting, it is rules tied to dollars.
- Not drone-only: drones are our demo, but the same engine runs a medical devices pack, and we built rule libraries for six industries.
How we built it
Python and Streamlit, with pandas for data and rapidfuzz for matching. The pipeline normalizes text, scores IDF-weighted tokens, snaps typos with fuzzy matching, remembers supplier SKUs, converts units of measure, and flags prices that look wrong (over 2.5x the median). Confidence combines score and margin over the runner-up, so a close second place lowers trust. The live demo is hosted on Streamlit Community Cloud.
Results (on synthetic data)
We graded PartLink against a hidden answer key on synthetic data, so these are demo results, not production claims. The review queue, savings simulator, regulatory outlook, and medical devices pages are all live in the app.
Challenges
Supplier text is messy: typos, abbreviations, and different units for the same part. Near-duplicate parts were the hardest, because a confident wrong match is worse than sending a line to review. We also had to keep savings numbers honest, so we separated identified, approved, and realized dollars.
How we used Velocity AI
Velocity AI's premise is that cost and risk get locked in early in product development, then force late compromises. We used the Velocity AI challenge as our brief and built PartLink around that idea: link BOM lines to real spend early, flag rules that change what can be bought, and tie every savings claim to evidence, with human review for uncertain matches.
What we learned
Claims are cheaper than proof. Savings are only potential until invoices confirm them, and the real test is real data, which will score lower than our synthetic set.
What's next
An 8-week, read-only pilot on one product family with five pass/fail gates agreed before any data loads: dollars linked, precision on auto-accepted links, swaps reviewed, savings evidenced, and verified realized savings. If linkage is not trusted, we fix the master data before selling a savings claim.
