AI never invents part numbers

There is a category of AI mistake that’s worse than an obvious error: the plausible fabrication. Ask a language model for an LCSC part number and it will happily produce one — correct format, credible prefix, the confident ring of truth. It may point at nothing. It may point at a real component that is not remotely the one you asked for. Either way you’ll find out weeks later, holding a reel of the wrong capacitors, or worse, a fully assembled board with them already soldered on.

So my electronics workflow has exactly one inviolable rule: a part number must originate from a real catalogue lookup. Always. No exceptions. The model can search, script, scrape, and cross-reference — it may never remember a part number into existence.

This post is about the pipeline I built around that rule.

The problem, concretely

My projects run off a master BOM spreadsheet — a hundred-plus line items across boards and synth modules, with TME (Poland, fast to Spain) as the primary supplier and LCSC (China, absurdly cheap per unit) as the secondary. The strategy is boring and effective: small urgent orders from TME, everything batchable accumulated into big LCSC orders so shipping and import costs amortise across the batch.

The work nobody wants: for every BOM line, find the correct LCSC part code. Manually, that’s an evening of tab-switching per project. Naively delegated to an AI, it’s an evening of tab-switching plus a treasure hunt for the lines it quietly made up.

The pipeline

The result is lcsc_pipeline.py, a small CLI tool with three subcommands and a firm division of labour based on how verifiable each component class is.

A tolerant BOM loader. Real-world spreadsheets are hostile: preamble rows before the header, codes buried in a Notes column as (LCSC C123456) asides, lines already sourced that shouldn’t be touched. The loader handles all of it, because a pipeline that requires a pristine input file is a pipeline you’ll stop using by Thursday.

An offline engine for passives. Resistors, capacitors, and other jellybeans are structured data — value, package, tolerance, voltage. Those can be matched deterministically against a downloadable parts database (the community-maintained dump of JLCPCB’s catalogue), completely offline, no model judgement involved. Deterministic input, deterministic output, nothing to hallucinate.

A browser batch for ICs. Chips are where nuance lives — package variants, tape-vs-tube suffixes, second sources — so the pipeline doesn’t guess. It emits a batch worksheet of lookups for an actual browser session against the actual catalogue, then a third subcommand ingests the results and triages every line: PASS, REVIEW, or NO_HIT, each with reasons. A human (or an agent driving a real browser) confirms against real product pages. The model’s job is orchestration and cross-checking, never recall.

Every output row carries its code, the URL it came from, and its status. Provenance or it didn’t happen.

The bugs were educational too

Building the deterministic half surfaced the kind of failures that make you trust the approach more, because they were all catchable precisely because nothing was fuzzy:

• Excel eats leading zeros. Export a BOM to CSV and package code 0603 becomes 603 — which matches nothing. If you’ve ever wondered whether spreadsheets hate you personally: yes.
• The parts database split its flags. What I expected as one “library type” field was actually two boolean columns, so the matcher silently filtered out nearly everything until the query logic matched reality.
• Bare numeric codes. LCSC codes want their C prefix; a join key that’s right 95% of the time is a join key that’s wrong.

Three dumb bugs, three deterministic fixes, validated against real pasted catalogue data. Contrast that with a hallucinated part number, which produces no error, no empty result, no smell — just a wrong component wearing a right component’s clothes.

The generalisable bit

Strip away the electronics and the pattern is this: generative AI plus deterministic verification is a system you can trust. Generative AI alone is a system you can only hope at.

The model is superb at the parts of sourcing that are genuinely hard to automate classically — reading a messy spreadsheet’s intent, deciding that a KEMET polymer tantalum is a legitimate substitute for the Panasonic on the BOM (same 220µF/10V, same case, better ESR — real example), orchestrating the whole flow. It is catastrophically bad at being a parts catalogue, because a parts catalogue’s one job is to be exactly right, and “exactly” is not what next-token prediction sells.

So build the seam deliberately: let the model reason, and make anything that must be precisely true — part numbers, prices, footprints, pinouts — flow from a source of truth the model can query but not impersonate. That seam is the entire difference between an AI workflow that ships working hardware and one that ships confident fiction.

The pipeline’s getting cleaned up for an open-source release; that’ll be its own short post. In the meantime, if you take one thing from this: the next time an AI hands you a part number, a citation, or a price, ask it where that came from. If the answer is “memory,” the answer is no.