The tool reads the BOM description to catch multi-pad or polarized parts sitting on a plain chip footprint. Its word lists only knew a few spellings. On main, 46 of 65 realistic BOM lines came out ready as a plain two-pad chip. Examples were 'RES NET 4 ISOLATED 10K 0603', '8P4R', 'Trimmer potentiometer', 'CMC 90 ohm', 'LED RGBW 1210', 'POSCAP', 'Ta cap', and tantalum written in German, French, Spanish, Polish or Chinese. That is a wrong footprint passing as ready.
Recurring agent failure issue in PCBLIVINGLIBRARY (oliBrowne)
What engineers report
A recurring agent failure problem in PCBLIVINGLIBRARY (oliBrowne) that mostly hits the electrical engineer.
Failure pattern: agent / false pass
Analyst note
From the Grok pain-radar digests, Nov 11-12 2026 (Nov 11 8:41 AM ET through Nov 12 5:41 AM ET digests plus the Haitch editions). Verified live 2026-11-12: issue/PR read; title and state confirmed.
What it costs a team
Modeled annual cost
$30,000
For a team of 5
Prototype delay
3 days
Modeled schedule slip per occurrence
Time lost
240 min
Per engineer per month, about 1 incidents
How the cost is modeled
240 min/month × 5 engineers × 12 months = 240 hours × $125/hour = $30,000
A modeled estimate with medium confidence. Swap in your own team size and loaded rate to size it for your team.
Engineering tools that address it
No engineering tool profile lists this error yet. Browse tools that connect to PCBLIVINGLIBRARY (oliBrowne).
Evidence
More recurring errors in PCBLIVINGLIBRARY (oliBrowne)
- A full review of oliBrowne's KiCad/Altium part library pipeline found that a BOM line with 0805 or 1206 in the footprint column became a plain two-pad chip even when the description said array, common-mode choke, balun or RGB, and was marked ready. Polarized caps were only recognised by part-number prefix, so a tantalum could get a symmetric land. A crash in the footprint checker or the KiCad vs Altium comparison counted as a warning, so the part passed. And a reject written while release-check was writing the plan got overwritten, so the rejected part was exported.ECAD · impact 74
- An AI datasheet reader was building wrong footprints and marking them ready, so the fix is to hold the part for a person. Cases it used to build: a 2 x 2 mm WSON read as 2 x 50.8 mm, inch values labelled mm, values the reader itself listed as unread built as guessed, and a pin list that put every pin on one net, which switched off the pad overlap check. A 6-pin QFN got split 1+2+1+2.ECAD · impact 74
- A bug hunt on a living KiCad/Altium component library logged 40+ bugs, each with a regression test that failed first; HIGH items include a metric "Case Code (mm)" BOM field read as imperial ("built wrong"), an inch pad table read as mm, a KiCad export that shipped draft, typo, duplicate and deleted statuses, KiCad-to-PcbLib conversion dropping arcs, circles and bottom pads, and an edited recipe or STEP file of a released part shipping with no change control.ECAD · impact 66
- A part the librarian marked passive only from its BOM letter, like R5 or C3, got passive pins in Altium but kept its source's input and output pins in KiCad. Same part, two tools, two different electrical definitions. The fix records the passive decision in the plan so both outputs use it. The same PR found that on Debian and Ubuntu the KiCad 10 plugin button never appeared because pip was missing for the virtual environment.ECAD · impact 66
- A part-library pipeline hunting package drawings let 7 wrong documents through out of 8 on the Oct 24 run (checks too loose: part-number prefix, family plus pin count, full MPN on a document with no drawing); the Oct 23 run also picked up end-of-life change notices as if they were drawings.ECAD · impact 66
- A through-hole header pulled from EasyEDA had its 3D body sunk 3 mm into the board and was reported 5.5 mm tall when it is 8.5 mm; separately, typing a bare LCSC number in Altium's Add part was refused as a BOM mismatch, so the part was held with no symbol or footprint.ECAD · impact 66
Sourced from public community reports. Costs and delays are modeled estimates, not measurements. Know a better source or a fix? Tell us at hello@productflo.io.