• The cell that inflated a board cost by 270×

    Bianca • 06/03/2026 at 17:46 • 0 comments

    Here's the bug that justifies this whole project.

    A BOM came through with an inductor whose package cell read `Φ18 x H25 x P7.5 mm`. The quantity column next to it was empty. My early quantity parser did the "helpful" thing: it scanned the row for a number and grabbed one. It found a number inside that dimension string and treated it as the quantity. One line item silently became thousands of parts. The estimated board cost came out 270× too high — and nothing in the output looked obviously wrong. The number was just… large.

    That's the nightmare case: not a crash, not an error, just a plausible-looking wrong answer that someone downstream trusts.

    The fix wasn't a smarter number-grabber — it was the opposite. The quantity phase now refuses anything that looks like a dimension or spec: if a cell contains units (`mm`, `mil`, `°`), a `Φ`/`ø` symbol, or a `<number> x <number>` pattern, it is rejected as a quantity, the row is flagged, and the quantity defaults conservatively (to the reference-designator count, or 1) instead of to a fabricated value.

    It's now a regression test: feed in `Φ18 x H25 x P7.5 mm`, assert the quantity is NOT a four-digit number. Determinism over cleverness — that's the whole philosophy in one test.

  • Log 1 — Why I keep getting BOMs that break everything

    Bianca • 06/03/2026 at 17:07 • 0 comments

    I want to start this project where the problem actually starts: with the files.

    Here are three real BOMs I've had to deal with (anonymized). The first one has a title block, a logo cell, and two revision rows before the header even begins — so every naive parser reads "Company Confidential" as a component. The second has the quantity column written as 1 pc, 2pcs, x3, and once, gloriously, see note. The third was exported fine, then opened in Excel by someone who merged the manufacturer cells "to make it cleaner."

    None of these are exotic. This is the format. The clean BOM is the exception, not the rule.

    What pushed me over the edge wasn't a single bad file — it was realizing I rewrite the same defensive parsing code every time, badly, under deadline, and then throw it away. So I'm building it once, properly, with a test suite made entirely of files that broke something.

    The design rule I'm committing to up front: never invent data. If a value can't be parsed, the tool flags it and moves on — it does not guess a number to make the row look tidy. A wrong-but-confident BOM is more dangerous than a messy one. More on why in the next log, where a single cell inflated a board cost by 270×.

    If you have a BOM that's defeated your scripts, send it (anonymized). The ugly ones are exactly what I want.