Hardware release intelligence for every CAD workflow
Connect a GitHub repository, check the exact design revision, and open visual findings. Your source and branch protections stay in GitHub.
Pull request evidence
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.
Live GitHub pull request demos
Two public pull requests show the actual BoardReadyOps GitHub App verdicts, Actions execution and downloadable reports on synthetic KiCad and BOM data. These are reproducible demonstrations, not customer manufacturing evidence or a fabrication approval.
See a real GitHub App release-readiness success on a public PR, with the corresponding Actions run and downloadable reports.
See real Check Run blockers for a synthetic board outline, duplicate references, and BOM compliance risks, with workflow evidence.
The synthetic prototype-ready run reports one medium fabrication-notes finding, with zero high-severity blockers. Its recorded readiness is at-risk, but the configured high-severity release threshold does not block this example.
This is a checked-in CLI scenario report, not a hosted GitHub App WARN Check Run.
These are separate synthetic examples; they are not one recorded customer revision history.
Synthetic hardware is included in the repository. Run boardreadyops run examples/golden-demo/broken or boardreadyops run examples/golden-demo/fixed — no KiCad installation needed.
Release workflow
Keep the engineering path short: connect, evaluate, investigate.
Install the GitHub App. Your source, branch protection and workflow history stay where they are.
KiCad, BOM and manufacturing checks run against the commit in the pull request, not a moving branch.
Start with the verdict, then open the findings, files and execution history behind it.
What you see
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.
See the stable readiness result, blocking state, and direct path to the evidence that can change the release decision.
Filter findings and files without pulling your whole history down the wire.
One click to the commit, the Check Run, the workflow run, the pull request, or the file itself.
Engineering coverage
Layout, supply chain and manufacturing all reported the same way, so nothing needs translating.
Every rule violation stays attached to the commit that introduced it.
Missing part numbers, parts going end of life, and gaps between variants — before handoff.
Gerbers, drill files, markings and assembly outputs, checked for completeness.
Inspect findings, checksums, and run evidence. Source-to-output proof is distinct from an output hash.
Search, filter and sort without waiting for your whole history to load.
Check Runs, pull requests and workflow logs stay in GitHub. No second place to look.
Trust boundary
BoardReadyOps keeps your source and repository-owned workflow logs in GitHub. The hosted control plane can retain normalized findings, run metadata, audit events and optional managed artifacts under its data-lifecycle policy; it does not require taking custody of your source files.
How to read a release decision
BoardReadyOps is built around a small set of release principles that make hardware evidence easier to review now and easier to audit later.
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. Recording a commit SHA and artifact digests identifies the evaluated evidence; proving those outputs were generated from that commit requires a separately trusted same-run attestation.
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.
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. Reviewing component availability, placement conventions, and drill drawing notes reduces avoidable handoff risk but cannot guarantee fabrication success.
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.
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. For configured repositories and supported workflows, the GitHub Action can run deterministic design, BOM and manufacturing checks against the selected source revision. The evidence helps reviewers make a release decision; it is not a certification, compliance finding, or promise that a board can be fabricated.
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.
Practical boundaries that keep the verdict understandable instead of turning it into a black box.
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 checks the available manufacturing files against configured profiles and recorded hashes. Those checks alone cannot establish that a given output was generated from the exact commit under review. It verifies layer counts, drill tool tables, format versions, and checksum manifests against your specified fabrication profile.
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.
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.
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.
When enabled and KiCad CLI is available, BoardReadyOps runs KiCad ERC on schematics and DRC on PCB layouts, tying their diagnostics to the evaluated revision. Optional pinmap rules compare configured pin assignments and net names with parsed schematic data. These checks do not independently prove schematic-to-PCB netlist equivalence, differential-pair polarity, or the presence of required pull-up resistors; engineering review remains necessary.
Glossary
These definitions describe the evidence BoardReadyOps reports. For implementation details, continue to the canonical documentation; for the public machine-readable service contract, see OpenAPI.
Next release