The Model Finds the Defect. The Standard Decides What It Means.

The first time the app produced something other than a bounding box, I didn't trust it. I'd uploaded a bare board with an obvious spurious-copper defect crowding a fine-pitch pad, watched YOLOv8 draw its usual green rectangle — I'd seen that a hundred times by then, that part was never the hard part — and then, in a new column next to it, three lines rendered: IPC-A-600, spacing reduction, conductor spacing section. Class 2: accept if spacing holds above minimum. Class 3: reject regardless. Probable cause: under-etch, or a scratch on the phototool. I have written that exact sentence in a real 8D report, for a real board, at a real company. Watching a local model produce it — unprompted, grounded in a Markdown table I wrote myself, running entirely offline on my laptop — was the moment pcb-defect-copilot stopped feeling like a YOLO tutorial with my name on it.

Anyone Can Fork a YOLO Repo. Not Everyone Can Finish the Sentence.

Object detection on PCB defects is not a hard problem to find code for. Half a dozen public repos fork the same HRIPCB dataset, drop in Ultralytics, and ship a Streamlit demo with bounding boxes over missing holes and mouse bites. I studied two of them before writing a line of my own, and they told me exactly where the real work starts: the box. A bounding box tells you where something is wrong. It says nothing about whether that's a problem, what standard governs the call, or which process step upstream actually broke.

That's the part four years on a PCBA floor actually pays for. IPC-A-600 and IPC-6012 govern bare-board acceptability — hole presence, conductor spacing, etch quality — and draw a hard Class 2 versus Class 3 line that changes the verdict on the same physical defect depending on who's buying the board. IPC-A-610 is a different standard, for a different domain: solder joints and component placement after assembly, not the bare board underneath. Manual inspectors know this distinction cold. It's why they're expensive, and why fatigue, not ignorance, is the real failure mode — accuracy measurably drops after an hour or two of squinting at the same six defect classes under a scope. A vision model doesn't get tired. It also doesn't know the difference between IPC-A-600 and IPC-A-610 unless somebody who's read both standards teaches it, row by row, which class of board gets which verdict and which upstream process step to check first. That table is the part nobody forks, because nobody forking a GitHub repo has stood at an AOI station arguing with a customer about a Class 3 reject.

A Firewall Made of Regex, Not Vibes

The architecture is deliberately boring where it counts. YOLOv8n trains locally on an M5 Pro over MPS — no cloud GPU, no API bill for the vision half. The IPC mapping itself lives as static Markdown tables I authored from the actual standards, one table per domain, checked into the repo as the single source of truth. At inference time, a local Ollama model (gemma3:12b, fully offline) takes the detected classes plus the relevant table rows and phrases them into a sentence a process engineer would actually say — no retrieval index, no vector store, because there's nothing to retrieve when the entire knowledge base is a page of Markdown small enough to paste into a prompt.

The part I didn't plan for going in was the firewall. Early on, in testing, the model cheerfully cited IPC-A-610 — the assembly standard — for a bare-board defect, because nothing was stopping it from blending domains it had no business blending. So the mapping layer now hard-validates every LLM response against the class it was asked about: a bare-board row that mentions "IPC-A-610" anywhere in its output gets rejected outright, and an assembly row that leaks "IPC-6012" gets the same treatment. It's a few lines of regex, not a clever model — but it's the difference between a demo that sounds right and a tool I'd trust to draft the first line of an actual nonconformance report. That validator, plus the rest of the test suite, sat at 110 passing checks after Phase 2 shipped and grew to 157 once the assembly domain landed in Phase 3.

The Number That Wouldn't Move

Here's the part I'd leave out of a pitch deck and won't leave out of this post. The bare-board baseline is strong — mAP@50 of 0.991 on the direct PKU HRIPCB ingest, 1.43 ms per image on the same M5 Pro. Pushing into assembly defects with the SolDef_AI dataset for Phase 3 was messier — which is the honest state of real engineering, not the pitch-deck version. The first assembly baseline landed at mAP@50 0.855. A round of augmentation tuning lifted it to 0.877 and pulled real gains out of three of the four classes — spike recall up 6.9 points, no_good up 10.5, exc_solder up 3.3.

poor_solder didn't move. It sat at 0.583 recall before the tuning pass and 0.583 after, no matter which augmentation knobs I turned, because the class has exactly twelve instances in the validation set and there is no amount of hyperparameter searching that manufactures more data. I tried once more after that — segmentation masks and class weighting, a genuinely different approach, not just another augmentation sweep — and it didn't beat the number either. So the shipped model is the one from the tuning pass, the newer attempt is documented as a no-win, and poor_solder stays flagged as a known limitation rather than something I quietly rounded up in a README. A twelve-instance floor is a data problem, not a modeling problem, and pretending otherwise is how projects end up with metrics nobody can reproduce.

What's Actually Hireable Here

The YOLOv8 weights are not the resume line. The resume line is that the mapping from defect to IPC criteria to probable process cause is domain knowledge that came out of a Dallas PCBA floor, not out of a paper, and it's now sitting in a repo with a test suite that enforces its boundaries automatically. That's the pitch for a Process Engineer who builds AI: not "I can train a model," which is table stakes now, but "I know which standard applies and why, and I can make a machine say it correctly, offline, on hardware I own." pcb-defect-copilot is the first of a small portfolio built on that exact bet — if you want the fuller picture of the architecture, the training ladder, and where the honest limits sit, the pcb-defect-copilot project page has all of it in one place.