A PCB review should leave receipts

By Spencer and Claude. Claude did the writing; the material is Spencer's engineering notes, measurements, and repositories. Nothing here has been independently fact-checked, so accuracy is not guaranteed — read it as a lab notebook, not a datasheet.

A useful PCB review should survive the conversation that produced it. Every recommendation needs the evidence in the current design, the decision being proposed, the reason, a verification step, and the primary source behind it. That turns a list of fixes into an engineering record.

We gave an agent a schematic, board file, manufacturing archive, and an older bill of materials. It found problems. That part was useful, but not especially interesting.

The interesting result was the shape of the review it left behind.

The review begins with a release verdict, not a reassuring count of completed checks. The board library, source revision, schematic, BOM, manufacturing artifacts, findings, changes, and releases remain connected in one workspace.

A list of fixes is disposable

“Change the reset circuit.” “Reroute the Ethernet pairs.” “Check the footprint.”

Those may all be correct, but they are poor instructions. They separate the recommendation from the evidence that produced it. When someone opens the board a week later, they must either trust the reviewer blindly or repeat the investigation from scratch.

PCB work makes that especially risky. A recommendation can be electrically reasonable and still be wrong for the product. A generic checklist does not know which interfaces are used, which constraints are intentional, or which manufacturing process the board is meant for.

So the review uses one repeated structure:

current evidence → proposed decision → rationale → verification → source

Each part has a different job.

• Current evidence anchors the finding to a named revision of the actual design.
• Proposed decision says what should change without pretending there is always only one valid implementation.
• Rationale connects the evidence to the decision.
• Verification defines what must be measured, inspected, or re-extracted before the finding can close.
• Source lets the designer check the interpretation against a datasheet, application note, fabrication rule, or other primary document.

The source is not a decorative footnote. It is the escape hatch from trusting the reviewer.

One finding is a compact argument. Its status and designators remain visible above four explicit panels, followed by the current-design and manufacturer evidence side by side.

One small example

One finding concerned an Ethernet PHY reset network. The schematic showed a 51 Ω resistor and a 100 nF capacitor, a nominal RC product of 5.1 µs. Microchip's Table 5-8 requires that nRST not be deasserted until at least 25 ms after every external supply reaches 80%, and that a commanded reset stay asserted for at least 100 µs. An RC product is not a reset release time, which also depends on the input threshold and the rail ramp, but 5.1 µs is roughly 4,900 times short of the power-on figure, so the finding does not hang on that distinction.

A weak review would say “increase the capacitor.” The receipt is more useful: it preserves the circuit that was reviewed, shows the calculation, cites the exact table in the manufacturer datasheet, and leaves a verification gate: measure reset during both fast and slow power ramps on the revised board.

The evidence narrows the problem, but it does not smuggle in a topology decision. The designer may choose an RC network, a supervisor, or another solution that satisfies the same requirement. What matters is that the next revision can be checked against the reason for the change.

The receipt continues below the pictures. The exact source claim sits beside the working record, where notes, re-review verdicts, changes, and the reason for clearing an item survive the next revision.

The design is more than the schematic

A release normally arrives as several overlapping descriptions of reality:

• the schematic says what the circuit is intended to do;
• the board file says what was placed and routed;
• the Gerbers say what the fabricator will receive;
• the BOM says what someone intends to buy;
• the placement file says where the assembler will put it.

None is authoritative by itself. A schematic can name one part while the supplier field points to another. A value can claim a voltage rating that the selected component does not have. A footprint can be routed cleanly while belonging to the wrong package. A polished CSV can preserve all of those contradictions perfectly.

That is why the review stores the inputs as one named revision and compares them. The goal is not simply to extract structured data. It is to keep the electrical intent, physical geometry, purchased identity, and manufacturing output from drifting apart.

The verdict matters more than the score

Automated review tools are tempted to reward activity: checks passed, nets parsed, placements found, warnings closed. Those numbers can describe the work, but they cannot approve a board.

The honest output may be do not fabricate this revision.

That verdict should remain until the open decisions have evidence of closure. A routed board with no airwires can still contain a startup loop, a mismatched part identity, an invalid land pattern, or a power path that has never been tested at load. Completeness is not correctness, and structured data is not release approval.

The review therefore ends in gates rather than confidence scores:

1. preserve the exact source revision;
2. reconcile schematic, layout, parts, and manufacturing outputs;
3. resolve each decision or explicitly accept its risk;
4. generate the assembly files from approved identities and placements;
5. inspect the assembler's preview;
6. archive the inputs, outputs, citations, and verification evidence together.

Automation should make those gates easier to reach. It should not quietly step around them.

The interface is part of the engineering

The review lives beside the BOM and source artifacts rather than in a chat transcript. That placement lets a finding turn into a part choice or layout change without losing its reason.

It also gives the next revision something durable to update. A new board file should refresh the current evidence, rerun the mechanical checks, and leave a decision open until its verification passes. The useful history is not merely that a red card turned green. It is a record like this:

Reset network changed from an RC delay to a supervisor. Source requirement unchanged. Power-ramp measurement still pending.

That sentence tells the next reviewer what changed, why it changed, and what remains unknown. A checkmark cannot.

AI can accelerate the reading, comparison, and organization involved in a PCB review. It can also produce confident advice that loses its context the moment the conversation closes. The difference is not a smarter checklist. It is an artifact that makes every important claim inspectable.

An engineering review should not ask for trust. It should leave receipts.