OpenDAP's board team took 30 lessons about manufacturing and reliability and wrote them into the KiCad files for its T1 main board. The checks cover details such as copper near mounting holes, components beside panel break tabs, access around fine-pitch packages, fiducials used by assembly machines, and heat sources near the battery. Each rule has a test board with one object that should pass and one that should fail.
That changes when the review happens. A rule that once lived in a fabricator's email or a senior engineer's memory can now reject a board while the designer is still editing it. We think this is the start of a broader shift: printed circuit board (PCB) review is becoming a build step, much like software tests that run before code can merge.
OpenDAP gives every rule its own test
The OpenDAP change is useful because it shows what executable board review looks like in practice. The project stores its product-specific rules in a .kicad_dru file, KiCad's text format for custom design checks. A mounting hole must follow one set of clearances. A ball grid array, a chip package with connections underneath, must leave room for repair. A hot component must stay away from the battery pocket. The board objects carry names and properties that let the rules find them.
OpenDAP also tests the checks themselves. Its generated test board contains a passing and failing example for each rule, and a script confirms that every expected failure appears once while the passing side stays clean. That matters because a silent rule is worse than no rule. It gives the team false confidence while the old review process disappears.
The project is honest about coverage. Some questions still don't fit KiCad's design rule checking (DRC), the automated pass that checks board geometry against manufacturing and electrical limits. Impedance, copper area, voltage protection, and test-point coverage need other checks. OpenDAP lists those gaps instead of treating an incomplete run as a clean board.
The project captures its own manufacturing choices and product risks in files that travel with the board, beyond the standard clearance rules every PCB tool already has. A new engineer, a supplier, or an automated design tool gets the same review criteria without first learning which mistakes caused the last three board spins.
The checks are crossing engineering boundaries
Several projects moved in the same direction this month. TextEDA added a check that compares a two-terminal part's voltage rating with the full voltage range across the nets it connects. In its example, a 12-volt capacitor on a rail that can reach 19.8 volts fails with both numbers in the message. The project deliberately reports devices it cannot evaluate instead of counting them as passed.
Case Constructor attacks a different boundary. It reads a board drawing, extracts the outline and mounting holes, and compares them with the enclosure catalog entry. A board and case that disagree on a hole position can now fail before anyone orders either part. That check connects electrical computer-aided design (CAD) data with the mechanical definition of the product.
Boardwise, an open-source board reviewer, shows how the rule library can improve after real hardware comes back. Its October release fixed three classes of silent misses found on physical boards, including high-voltage spacing between separately named conductors and current checks across copper that carried two net names. The release reports 6,242 passing tests for the checker itself. Its repeatable rules will catch the same classes of mistake on the next board.
These tools cover geometry, component ratings, enclosure fit, and lessons from physical builds. Together they point toward a board repository that contains more than the design. It contains enough of the team's review knowledge to answer whether a proposed change is safe to send onward.
KiCad made small checks practical
Three years ago, a small team could write these checks, but the plumbing was expensive. Board data often had to be exported through a graphical interface, scripts depended on fragile plugin setups, and results came back as reports meant for a person to read.
KiCad has lowered that cost. Its board and rule files are text, so projects can inspect and version them. KiCad 8, released in February 2024, added command-line electrical and design rule checks with machine-readable JavaScript Object Notation (JSON) reports for automated pipelines. The current KiCad command-line interface can also run saved job sets and export manufacturing files. Those commands fit into continuous integration (CI), the automated checks that run when a project changes.
OpenDAP can combine KiCad's built-in geometry engine with project rules. TextEDA can read a design description and compare ratings. Case Constructor can parse Drawing Exchange Format (DXF) files used for mechanical outlines. A team can build one small checker around the failure it cares about and run it beside the standard checks, without waiting for the PCB editor vendor to add a menu command.
AI increases the need for this work. A human designer may remember that a battery needs space from a hot regulator because the last prototype failed there. An AI router or board agent only sees what the project and its tools make explicit. If the rule isn't written down, faster editing produces bad revisions faster too. Executable review lets a team automate more of the design work without asking the same system to grade itself.
Review products must move closer to the change
Small hardware teams gain first. They rarely have a dedicated signal-integrity engineer, manufacturing engineer, and mechanical reviewer available for every revision. A project-specific check lets those specialists' decisions run again after they have moved to another task, while leaving new and ambiguous problems for human review.
Contract manufacturers and design partners gain when customers send boards with named, reproducible checks instead of screenshots and scattered exception notes. The discussion can start from one failing rule and the exact object that caused it. Teams making hardware design agents gain too, because these checks give an agent a bounded target and an independent way to decide whether a change helped.
The exposed category is review sold as a repeated manual pass over each revision. Design-for-manufacturing services will still matter for process knowledge that a customer doesn't have, but the same mounting-hole, spacing, and assembly findings shouldn't be billed and rediscovered on every board. PCB collaboration products that stop at comments on static exports are exposed for the same reason. A comment explains one mistake once. A checked-in rule stops its return.
This argument can fail if the checks become noisy. Board rules depend on accurate net names, footprint properties, voltage declarations, and mechanical reference data. If maintaining that metadata costs more than the failures it prevents, engineers will disable the checks. Analog behavior, thermal interactions, electromagnetic compatibility, and manufacturability at an unfamiliar factory also resist simple pass or fail rules. Senior review remains essential where the team doesn't yet know how to describe the risk.
A practical starting point is the last board review your team paid for. Pick one finding that has appeared on more than one revision, write the smallest check that detects it, and add one passing and one failing example. Run it with the existing KiCad checks on every board change. By the end of 2027, we expect serious KiCad projects to treat project-specific electrical, manufacturing, and mechanical checks as part of the release package, alongside the schematic, layout, and fabrication files. Teams that start now will learn which review knowledge can be automated before a design agent forces the question on a live product.