Design Review and Release

• Review finds a class of errors that verification cannotDRC and ERC check rules. A reviewer checks intent: is this the right part, does this circuit do what the requirement asked, is this connector on the wrong side, will this be assembleable. Both are necessary and neither substitutes for the other.
• Reviews need materials, prepared in advanceA review where the reviewer sees the design for the first time in the meeting produces shallow feedback. Circulate the schematic PDF, the layout, the BOM, the requirements and the specific questions you want answered, at least a few days ahead, and ask for written comments before the meeting.
• Review by checklist and by roleDifferent reviewers should be asked different questions: an assembly-focused reviewer looks at footprints, courtyards and DFA; a power reviewer looks at thermals and loops; a firmware reviewer looks at pin assignment and debug access. Assigning perspectives finds more than asking everyone to 'have a look'.
• The reviewer's job is to find problems, not to be agreeableA review that produces no findings has failed. As a reviewer, come with specific questions and be willing to say 'I do not understand why this is here'. As the designer, treat every finding as free information and never defend by explaining the intent — if the reviewer misread it, the schematic is unclear, which is itself a finding.
• Disposition every findingEach finding gets a disposition: fixed, deferred with a reason, rejected with a reason, or converted to a documentation change. Findings that vanish without disposition are the mechanism by which known problems ship.
• Release is a state, not a dateA released design has: a fixed revision, a tagged repository, an archived output package matching that tag, a BOM matching that revision, a documented set of known issues, and a statement of what has been verified and what has not. Anything less is a work in progress being treated as a release.
• Change control and revision numberingDistinguish changes that require a new board (layout changes) from those that do not (BOM changes, firmware changes). Use a revision scheme that makes this visible, mark the revision on the board itself, and never modify a released revision — create a new one.
• Documentation is part of the deliverableA theory of operation, a power tree, a pin assignment table, an interface list, a test procedure and a known-issues list. These take a day to write and save weeks, and they are what makes a design maintainable by someone other than its author.

ProblemYou are reviewing a colleague's board. What do you actually do, and how do the real findings emerge?

1. 1
   Before the meeting, read the requirements document first, not the schematic. You cannot judge whether a design is correct without knowing what it was supposed to do.
2. 2
   Read the schematic on paper with the requirements next to it. For each requirement, find the circuit that satisfies it. Requirements with no corresponding circuit are your first findings and they are usually the most serious.
3. 3
   Trace the power tree independently: every rail, its source, its consumers, its current. Compare against the designer's power tree. Discrepancies are findings.
4. 4
   Check every IC against its datasheet's minimum system requirements: supply pins, decoupling, strapping, reset, clock. This is mechanical and it finds real problems.
5. 5
   Check the connectors: every pin, against the mating part's datasheet, including the orientation and which side of the board it mounts on. This is where the example finding comes from — the designer placed a right-angle USB-C receptacle for bottom mounting but the enclosure cut-out assumes top mounting.
6. 6
   Note how that finding emerged: not from staring at the layout, but from checking the connector's datasheet against the mechanical drawing. Findings come from cross-referencing documents, which is why review is document-intensive.
7. 7
   Check the layout for the things DRC cannot: is the hot loop small, are the decoupling capacitors actually adjacent to their pins, does the crystal have a local ground, does any fast trace cross a plane split, is the analogue section separated.
8. 8
   Check the BOM: are all lifecycle statuses active, are there any single-source parts, do the footprints match the parts.
9. 9
   Check testability: are there test points on the rails, is debug accessible, can fine-pitch parts be reworked.
10. 10
    Write findings as: location, observation, why it matters, and a suggested action. 'J3 is placed for bottom-side mounting (see footprint F.Cu pads and the datasheet's Figure 8) but the enclosure drawing sheet 2 shows the cut-out on the top face. One of the two is wrong. Suggest confirming with the mechanical model before release.'
11. 11
    In the meeting, go through findings in severity order, not document order. Disposition each one explicitly and record the disposition.
12. 12
    After the meeting, the designer updates the design and circulates a findings table showing each item's disposition and, for fixed items, the commit that fixed it. The review is not closed until that table is complete.

AnswerRead requirements first, then cross-reference documents against each other — schematic against datasheets, connectors against mechanical drawings, BOM against lifecycle data. The best findings come from the seams between documents, not from any single document. Then disposition every finding explicitly and close the review with a completed findings table.

Tool: Git-based hardware review with KiBot diffs and a findings tracker

• Ensure the design is in git with KiBot generating outputs in CI, as set up in the fabrication outputs skill.
• Create a review branch and open a merge or pull request. Even for a solo project, this creates the review artifact.
• Configure KiBot's diff output to compare the current revision's schematic and copper layers against the previous release tag, generating images. Attach these to the review.
• Circulate: the schematic PDF, the layer images, the BOM, the requirements, and a written list of the specific questions you want reviewed. State what you are NOT asking for review on, so effort goes where it is needed.
• Reviewers file findings as issues or as line comments, each with location, observation, impact and suggested action.
• For layout findings, take annotated screenshots. A findings list referring to 'the capacitor near the regulator' will be misinterpreted; one with a boxed screenshot will not.
• Hold the meeting only for the findings that need discussion. Simple ones can be dispositioned in writing.
• Track disposition in a table committed to the repository: finding ID, description, severity, disposition, owner, resolution commit.
• For each fix, commit with a message referencing the finding ID. Now the git history explains why every change was made.
• When all findings are dispositioned, tag the release: git tag -a rev-B -m 'Release rev B'. Push the tag.
• Archive the output package generated by CI at that tag, and record its checksum in the release notes.
• Write the release notes: what changed from the previous revision, which findings were fixed, what known issues remain, and what has and has not been verified.
• Finally, run KiBot's diff between this tag and the previous one and read it as a reviewer would. This catches changes you made and forgot.

• Robert Feranec - design review videosfreevideo~180 minSeveral videos are real design reviews of real boards with experienced engineers. Watch how findings are phrased and how disagreements are resolved.
• KiBot diff and CI documentationopen licencetool~60 minRead the diff and the CI integration documentation. Visual diffs of copper layers between revisions transform hardware review.
• Open hardware projects with public review historiesopen licencereference~90 minFind projects where hardware changes went through pull requests and read the review discussions. Real examples of hardware review as code review.
• NASA / ESA design review practices (publicly available process documents)freereference~60 minFormal review gate definitions (PDR, CDR) and entry/exit criteria. Far heavier than most projects need, but the structure is instructive and freely available.

Run a full design review on someone else's board (or on your own after a two-week gap, treating it as a stranger's), then release your own design with a complete documentation and traceability package.

Deliverables

• A review package you circulated: schematic PDF, layout images, BOM, requirements, and a written list of the specific questions you asked reviewers to answer.
• A completed review as a reviewer: at least fifteen findings on a real board, each with location, observation, why it matters, severity, and a suggested action. At least three findings must come from cross-referencing two documents against each other rather than from reading one document.
• A findings disposition table for your own design's review, with every finding marked fixed, deferred, rejected or converted to documentation, each with a reason and, where fixed, the commit reference.
• A released design: a git tag, an archived output package matching that tag with a checksum, a BOM matching the revision, and evidence that the revision is marked on the board itself.
• Release documentation comprising: a theory of operation (two to four pages explaining how the board works, block by block), a power tree, a pin assignment table, an interface list with connector pinouts, and a test procedure.
• A known-issues list stating every unresolved problem, its severity, its workaround if any, and whether it blocks use.
• A verification statement: what has been verified, by what method, and what has not been verified and therefore should not be assumed to work.
• A change control statement: the revision scheme in use, what constitutes a revision change versus a BOM change, and where the revision is recorded.
• A visual diff between two revisions of your design (schematic and at least two copper layers), with the changes explained in writing.

Acceptance criteria — how you know it is good enough

• At least fifteen substantive findings were produced as a reviewer, and at least three came from cross-referencing documents.
• Findings are specific enough to act on: location, observation, impact, suggested action.
• Every finding on your own design has an explicit disposition with a reason.
• The release is tagged and the archived output package's checksum is recorded.
• The theory of operation is understandable by someone who has not seen the design.
• The known-issues list is honest and includes items you would rather not write down.
• The verification statement distinguishes verified from assumed.

If you want to push further

• Run a review on an open-source hardware project and submit your findings upstream as issues, then engage with the maintainer's responses.
• Define and document a reusable review checklist for your organisation or your own practice, organised by reviewer role, and use it on the next two designs, refining it each time.

• I prepare and circulate review materials in advance with specific questions.
• I review by cross-referencing documents, which is where the real findings are.
• I write findings that are specific enough to act on without further discussion.
• I disposition every finding explicitly rather than letting some evaporate.
• I release designs with a tag, an archived output package and a checksum.
• I write a theory of operation, a known-issues list and an honest verification statement.
• I treat hardware changes as reviewable code changes with visual diffs.