What hardcore checks, and what it misses

What it checks, and how.

Every check runs on the delivered files, not on what the agent says it did. Each one comes back pass, fail or "can't verify", with the evidence.

Check	How
Electrical and design-rule checks (ERC, DRC)	KiCad's own built-in checker, which looks for wiring mistakes, layout rule breaks and unrouted connections, with schematic-to-board matching on. Mismatches count as errors.
Footprints vs datasheets	The package and pad numbers are compared with tables we wrote from the maker's datasheet. Pad sizes and pitch aren't compared yet.
Pinouts vs datasheets	Every pin name and its net, against the datasheet. MCU pins against the vendor's own pin database.
Firmware vs the board	Every pin the firmware uses is checked against the net it lands on.
Firmware builds and tests	It's compiled for the real chip with warnings as errors, and the host unit tests are run where they exist.
Loop bounds	Loops over fixed-size arrays are checked against the array size.
Trace width vs current	The standard IPC-2221 formula: is each track wide enough to carry its stated current without heating more than 10 C (outer layer, 1 oz copper)? Copper pours, vias and inner layers aren't modelled.
Power budget	Each regulator's rating against the worst-case loads we know.
CAD collisions	Every pair of solids in the assembly STEP that could touch is intersected.
Board vs enclosure	The board outline against its slot, and connector plug paths out through the enclosure.
Parts and BOM	The BOM is checked against the schematic, and every part against distributor stock (cached daily, not live).

How often it catches mistakes.

We planted one known mistake at a time into copies of our two example designs, then counted it caught only if a check newly failed.

23 / 26 that ran

A first measurement, not a guarantee. 9 more planted mistakes didn't run (see below). Of the 23 caught, 3 were caught only by KiCad's own design-rule check, and 1 by a firmware build that was already failing before we planted it. Counting only hardcore's own checks and leaving that one out, it's 19. The set is small, we planted the mistakes ourselves in our own designs, and the datasheet tables were written for the parts in those designs. A real mistake can be subtler than a planted one. We'll keep re-running this with mistakes picked by someone else, and update this page.

Kind of mistake	Planted	Caught
Wrong footprint	6	6
Swapped pins	7	7
Trace too thin for its current	3	3
Parts colliding in CAD	4	4
Firmware off-by-one	6	3

The three it missed.

A loop that skipped the last capture slot (chess board firmware).It compiled and the tests passed, because no test covered that loop. Only a warning came back.
A current-sense reading taken from the wrong ADC channel (robot hand firmware).The index arithmetic was off by one. The loop-bounds check only looks at loop limits, not index maths, and this firmware has no unit tests yet.
A grip loop that skipped the thumb-rotation motor (robot hand firmware).Same cause: compile-checked only. On a real hand you'd see it on the bench in seconds, but the checks didn't.

The pattern: firmware logic without tests is the weak spot. Where firmware has no tests, hardcore now marks that logic "can't verify" and tells you, instead of passing it.

Not covered yet.

Wrong component values, part polarity and missing decoupling.None of these are checked yet. They're next on the list.
Pad geometry, net classes and clearances in CAD.Package names and pad numbers are checked, but not pad sizes. Parts are checked for collisions, but not for clearance, tolerance stacks or assembly order.
High-voltage spacing, stackup, impedance and manufacturability.Creepage and clearance for higher voltages, layer stackup, controlled impedance and differential pairs, thermal design and fab-specific manufacturability checks are all not covered yet. DRC uses each board's own rules; a pinned rule set per fab is still to do.
Parts without a datasheet table.For these, only the power and ground pins are sanity-checked, and the check is marked "can't verify". Most real designs have some of these.
Nine more planted mistakes that didn't run.These were power budget, BOM part number, board fit and firmware-to-pin mistakes. A bug in our test harness stopped them running, so they're not in the 23 of 26. We'll publish them once they run, whether or not they're caught.

What always needs a physical test.

Some things only a real build can tell you. hardcore marks these "needs physical test" and never passes them.

Emissions and radio

EMC and radiated emissions need a pre-compliance scan at a test lab. Radio range needs a real unit in a real room.

Heat and wear

Real temperatures inside the enclosure, and how long moving parts last, need thermocouples and cycle tests on a prototype.

Behaviour on the bench

Timing, noise, friction and feel. For example, how the chess pieces slide on the real board surface.

What it can't do yet.

Certification.No FCC, CE, UL, medical, automotive or aviation sign-off. hardcore can design with those in mind, but certification needs a lab and a qualified engineer.
Controlled or regulated work.No export-controlled (ITAR/EAR) data, defense work or medical devices in the beta. Please don't upload them.
Mains-powered products.Not in the beta. Low-voltage DC boards only, up to about 48 V, so 24 V industrial I/O is in scope. The boards aren't CE or UL marked, and you stay responsible for your product's compliance.
Lossless Altium round-trips.Altium projects come in and go out through KiCad. Altium's importer can drop some design rules and stackup settings, so check them after opening. We haven't yet tested the round-trip on customer boards.
Very dense boards.On very dense boards, automatic routing may stop short and need a person to finish the last connections. You'll see exactly which nets are left open; it never hides them. Our robot hand driver board is still being routed.
Prove it works.Nothing designed by hardcore has been built yet. The first builds of both examples are in progress. Until then, "designed" means designed, not tested.

FALSE PASS LOG

0 entries so far.

A false pass is when a check says "pass" and the design turns out to be wrong in that respect, whether it's found by you, by an engineer review or on a real build. Every one we learn about goes here, with what happened and what we changed.

To be honest about the zero: nothing has been built yet, and the beta hasn't started. So it's zero because nobody has had the chance to find one, not because there aren't any.

Found one? Reply to any email from us, or tell us in the project chat, with the project and the check. If it's real, it goes in this log and we fix your design free.

no entries

What it checks, and what it misses.