Hardware release intelligence for every CAD workflow

Know what stands between your board and production.

BoardReadyOps checks whether your board is ready to fabricate on every pull request — or right from your local terminal. One verdict, clear blockers, and verifiable release evidence.

Install on GitHub Preview repository setup Install on GitHub

Local CLI or GitHub Actions
Clear blockers before you order
Your repository stays in charge

Pull request evidence

Every pull request, reviewed like a design review.

DRC, ERC, BOM and manufacturing checks arrive as one answer instead of several logs, and every part of it links back to the GitHub run it came from.

01Layout and schematic rule checks
02Parts you can actually buy
03A complete manufacturing package
04Every result tied to a file and a checksum

Live pull requests

Watch it work before you install anything.

Two public repositories running the published Action on the same board, in opposite directions. Open either pull request and read the check: the findings, the files they point at, and the fabrication diff showing which BOM lines and outputs changed.

main is blocked: five findingsCheck on the PR: green
A board that gets fixed
The pull request closes the outline, deduplicates a reference designator, and sources the BOM. The check goes green and the comment shows which BOM lines changed.
Open the pull request
main is clean: no findingsCheck on the PR: red
A board that gets broken
The pull request reads as routine housekeeping and makes the board unfabricable. Nothing in the diff says so. The check goes red and names all five reasons.
Open the pull request

Synthetic hardware under MIT, so you can copy it. Reproduce either locally with npx @boardreadyops/cli run . — no KiCad installation needed.

Release workflow

From design change to release decision.

Keep the engineering path short: connect, evaluate, investigate.

01
Connect the repository
Install the GitHub App. Your source, branch protection and workflow history stay where they are.
02
Check the exact commit
KiCad, BOM and manufacturing checks run against the commit in the pull request, not a moving branch.
03
Decide before you order
Start with the verdict, then open the findings, files and execution history behind it.

What you see

The answer first. The reasons underneath.

Open a run and the verdict is the first thing on the page. Everything below it is there to explain that verdict, or to let you argue with it.

Investigationrepository / release revision

Decision first
Loads fast

Decision first

Shortest next action before low-level evidence.

See the stable readiness result, blocking state, and direct path to the evidence that can change the release decision.

Finding things

Search what matters, not everything you have ever run.

Filter findings and files without pulling your whole history down the wire.

Back to the source

Every answer links back to where it came from.

One click to the commit, the Check Run, the workflow run, the pull request, or the file itself.

Engineering coverage

Every check stays tied to the commit it ran on.

Layout, supply chain and manufacturing all reported the same way, so nothing needs translating.

Design

Layout and schematic

Every rule violation stays attached to the commit that introduced it.

Supply chain

Bill of materials

Missing part numbers, parts going end of life, and gaps between variants — before handoff.

Manufacturing

Manufacturing readiness

Gerbers, drill files, markings and assembly outputs, checked for completeness.

Traceability

Nothing unaccounted for

Every result traces back to a versioned file, its checksum, and the workflow run that produced it.

Speed

Fast on a long history

Search, filter and sort without waiting for your whole history to load.

Publication

It all lives in GitHub

Check Runs, pull requests and workflow logs stay in GitHub. No second place to look.

Trust boundary

Your repository stays the source of truth.

BoardReadyOps reads and reports; it does not take custody of anything. Your source, branch protections, pull requests, checks and full workflow logs stay in the repository you already run.

Source of truth: Repository commit and protected GitHub workflow evidence
Investigation: Findings and file details only — never your board design itself
Decision trail: Check Run, publication state, attempts, checksums, and audit boundary

How to read a release decision

Evidence is useful when another engineer can reproduce the reasoning.

BoardReadyOps is built around a small set of release principles that make hardware evidence easier to review now and easier to audit later.

Why an exact commit matters

Hardware reviews are often longer than software checks. A BOM can be refreshed, a footprint moved, or a fabrication output regenerated while somebody is still looking at the pull request. BoardReadyOps records the commit and workflow context that produced a result so a later change cannot inherit an earlier green decision by accident. When a new commit appears, it deserves new evidence. That keeps the question simple: the verdict on screen describes this revision, not a nearby version of the board. Every check run cryptographically binds its findings, logs, and generated fabrication archives to the specific Git commit SHA.

Evidence stays close to the engineering workflow

The useful place for a release decision is where engineers already review change: the pull request and its GitHub checks. The Check Run carries the short conclusion; findings explain what needs attention; artifacts and hashes show which generated outputs were evaluated; workflow logs preserve execution context. BoardReadyOps is deliberately not a replacement repository. It creates a navigable decision trail over evidence that remains owned by the project. Reviewers can triage DRC violations, verify component replacements, and audit signoffs without switching context.

Manufacturing readiness is broader than DRC and ERC

A clean schematic and layout are necessary, but they do not prove that a contract manufacturer received a usable package. The release also needs the expected Gerbers and drill files, a BOM that matches the selected variant, component placement data, useful fabrication notes, and any project-specific vendor requirements. BoardReadyOps brings those checks into one release-readiness view so missing handoff evidence is visible before an order is placed. Verifying component availability, lead times, pin 1 orientation, and drill drawing notes prevents expensive fabrication scrap.

Repository control remains explicit

The production GitHub App is intentionally narrow. Repository-owned configuration and workflow files go through the same protected pull-request process as the board itself. BoardReadyOps can report a decision and dispatch the repository-owned evaluation workflow, but it does not quietly rewrite design files or bypass branch protection. That boundary makes a green result easier to trust because the automation cannot change the source in order to make its own check pass. Your team maintains total control over design rules and fabrication tolerances.

Automated release gates replace brittle manual spreadsheets

Traditional hardware handoffs rely on manual checklists, tribal knowledge, and error-prone spreadsheet reviews that slip under release deadlines. BoardReadyOps formalizes hardware release policies into repeatable CI/CD pipelines. Every pull request executes deterministic DRC, ERC, netlist comparison, BOM validation, and Gerber completeness checks in an isolated environment. The result is documented, auditable compliance before money is committed to copper, tooling, and surface-mount assembly.

A reviewable release-evidence checklist

A green verdict should be explainable without access to the original engineer's workstation. These are the evidence categories a reviewer should expect to trace.

Source revision Record the immutable Git commit that the decision describes. A branch name can move after review starts; the release evidence must not.
Design checks Keep DRC and ERC results associated with the evaluated project so schematic and layout findings can be traced to the same revision as the handoff.
Manufacturing outputs Verify that expected Gerbers, drill data, BOM, CPL or position files, drawings, and configured vendor deliverables are present and current rather than leftovers from an older build.
Evidence identity Use manifests, hashes, or equivalent identifiers for important artifacts. A reviewer should be able to tell which exact output was checked without trusting a filename alone.
Policy and exceptions Preserve the release policy, blocking threshold, suppressions, and waivers that shaped the verdict. Exceptions should remain visible engineering decisions with scope and rationale.
Workflow record Keep the GitHub workflow and Check Run that produced the result. Together they show when the evaluation ran, which revision it evaluated, and where a reviewer can inspect the authoritative execution evidence.

Release-readiness questions

Practical boundaries that keep the verdict understandable instead of turning it into a black box.

Does BoardReadyOps generate the manufacturing files?

You can generate them with BoardReadyOps or bring your own. Use 'boardreadyops generate' to produce Gerbers, drill files, BOM, and position files directly via kicad-cli, or keep your existing KiBot/export pipeline. BoardReadyOps validates that the package is complete, current, and matches the evaluated commit before you order boards. It verifies layer counts, drill tool tables, format versions, and checksum manifests against your specified fabrication profile.

When should a release check run again?

Whenever the source revision or evidence that supports the decision changes. A footprint edit, BOM substitution, regenerated fabrication archive, policy change, or new commit can change the release conclusion. The exact-commit model makes that boundary visible: an older green Check Run remains a record of what it evaluated, but it is not silently promoted to evidence for a different revision. Branch changes immediately invalidate prior stamps.

How should a reviewer interpret a waiver?

A waiver is a documented engineering decision, not a deleted finding. Reviewers should be able to see what was waived, why the exception was accepted, which scope it applies to, and whether the underlying condition still exists. That makes temporary manufacturing exceptions and known design tradeoffs auditable without teaching the automation to ignore the problem forever. Each waiver retains author identity, commit context, and rationale.

What makes a manufacturing handoff reviewable later?

The handoff needs more than a folder of outputs. It needs a traceable source revision, a manifest or equivalent inventory, hashes for important files, the policy that was evaluated, and a workflow record showing how the evidence was produced and checked. BoardReadyOps organizes those facts around the release decision so another engineer can reconstruct why the board was considered ready without relying on somebody's local workstation state. Audit logs preserve the complete verification trail.

How does BoardReadyOps verify schematic and layout synchronization?

BoardReadyOps extracts electrical netlists from both the schematic (via kicad-cli or eeschema exports) and the routed PCB layout (via pcbnew exports) and performs a deep structural netlist comparison. Any pin disconnect, unintended net merger, swapped differential polarity, or missing pull-up resistor triggers a blocking finding with exact component designators and schematic sheet references.

Glossary

The hardware-release terms behind the verdict.

These definitions describe the evidence BoardReadyOps reports. For implementation details, continue to the canonical documentation; for the public machine-readable service contract, see OpenAPI.

DRC: Design Rule Check. KiCad checks board geometry such as clearances, widths, keepouts, and connectivity against the rules defined by the project. BoardReadyOps keeps the resulting evidence tied to the exact commit being reviewed instead of treating a local DRC run as timeless proof. Track clearances, annular rings, track widths, hole sizes, and microvia rules across all copper layers deterministically.
ERC: Electrical Rules Check. ERC catches schematic-level problems such as incompatible pin types, missing drivers, and unconnected signals. It complements DRC: a board can be geometrically clean while the schematic still contains an electrical contradiction that should block release. Pin-to-pin directionality, power supply conflicts, floating inputs, and netlabel mismatches are surfaced before tapeout.
BOM: Bill of materials. BoardReadyOps evaluates the part list that belongs to the release, including manufacturer part numbers, lifecycle signals, variant consistency, approved alternates, and evidence that the selected parts match the design being handed off. It guards against obsolete silicon, unpopulated references, ambiguous packaging codes, and out-of-stock components before placement.
Manufacturing package: The fabrication and assembly deliverables required by the chosen handoff: Gerbers, drill data, BOM, position files, and drawings. BoardReadyOps can generate these through boardreadyops generate (wrapping kicad-cli) or validate the outputs generated by your existing toolchain. Each package manifest guarantees that all layers, drill files, and pick-and-place lists correspond to identical source revisions.
Release evidence: Versioned facts used to justify a hardware release decision: check results, manifests, hashes, reports, workflow runs, and manufacturing outputs. Evidence is useful only when a reviewer can trace it back to the exact source revision and see whether it is still current. Every verification assertion records timestamp, Git commit SHA, exit status, and SHA-256 artifact signatures.
Check Run: GitHub's native status-and-detail record for a commit. BoardReadyOps publishes a concise readiness conclusion there, then links deeper findings and artifacts so an engineer can start with the decision without losing the audit trail behind it. Annotations appear inline on changed layout or schematic files so hardware reviewers stay in their core pull request workflow.
Exact-commit evaluation: The rule that every release decision must identify the immutable Git commit it evaluated. A moving branch name is not enough: if the branch changes after a check begins, the evidence remains attached to the original revision rather than silently describing different source. This guarantees reproducible fabrication audits across distributed hardware engineering teams.
CPL / position file: The component placement list used by an assembler to place parts on the PCB. Coordinates, rotation, side, reference designators, and package identity need to agree with the released board and BOM; stale placement data can make an otherwise clean design impossible to assemble correctly. BoardReadyOps verifies pin 1 rotation conventions and coordinate origins across SMD footprints.
Waiver: An explicit, reviewable decision to accept a known finding under defined conditions. BoardReadyOps treats waivers as evidence with scope and history, not as a way to erase a warning from the record. The underlying finding remains understandable to future reviewers, carrying author justification, expiration parameters, and project owner sign-off.
Source of truth: The protected repository commit and its GitHub workflow evidence. BoardReadyOps presents and normalizes that evidence, but the repository, pull request, Check Run, workflow history, and versioned files remain authoritative for what was reviewed and released. No external database overrides what the cryptographic Git log proves.
Gerbers (RS-274X & X2): The standard vector artwork format for printed circuit board fabrication, describing copper conductors, solder mask openings, silkscreen legends, and mechanical outlines. BoardReadyOps inspects layer assignments, aperture macros, coordinate precision, and perimeter continuity to prevent manufacturing delays at the PCB fabrication plant.
IPC-2581 & ODB++: Intelligent manufacturing data exchange formats consolidating layer stackup, drill definitions, component placement data, and electrical netlists into a single digital container. BoardReadyOps validates schema conformance and cross-checks layer definitions against board physical stackup parameters.
Annular Ring & Drill Breakout: The margin of copper pad surrounding a drilled via or through-hole lead. Inadequate annular ring width risks drill breakout during multi-layer board lamination, leading to intermittent opens or impedance discontinuities. Automated checks ensure all plated holes respect fabricator minimum annular tolerances.
Solder Mask Dam & Web Clearance: The minimum physical bridge of solder mask material between adjacent surface mount pads. Missing or undersized solder mask webs cause solder bridging and short circuits during convection reflow assembly. BoardReadyOps catches tight-pitch pad clearances that violate vendor mask capability.
Impedance & Layer Stackup: Controlled dielectric heights, copper weights, and trace geometries required for high-speed differential pairs, USB, Ethernet, and RF routing. Release validation verifies that PCB stackup tables in drawings match the physical layer definitions exported in Gerber and drill archives.

Next release

Check your next board before you order it.

Install on GitHub Review setup first