Why a Manufacturing Gate Matters More Than an AI Designer

Generation speed is irrelevant if the release boundary is weak

An AI designer can create a schematic or layout quickly. A skilled engineer can also make a fast change under deadline. Both can produce a board that looks finished while the BOM points to the wrong package, the PCB is stale relative to the schematic, or the fabrication archive contains yesterday’s drill file.

A manufacturing gate sits between editable design work and an irreversible order. It accepts one version only when independent checks and named reviewers satisfy release criteria. It does not care whether the source was drawn manually, generated from code, routed by an optimizer, or edited by an agent.

That makes the gate more durable than any particular designer. Tools change; the requirements for traceable, internally consistent manufacturing data remain.

Define the input and output precisely

The gate input is a versioned design candidate:

• requirements and approved exceptions;
• exact KiCad schematic, PCB, project, rules, and libraries;
• exact MPN and approved-alternate data;
• tool and dependency versions;
• mechanical inputs and the target fabrication capability profile.

The output is one immutable release bundle:

• Gerber and drill files;
• BOM and pick-and-place data;
• fabrication and assembly drawings;
• optional STEP, IPC-2581, test, and programming files;
• ERC/DRC and other check reports;
• source revision, hashes, approvals, and release notes.

The meaning of release for manufacturing is this controlled transition. Copying files into a folder named final-final is not a release process.

Layer 1: source completeness and identity

Before running electrical checks, fail on missing identity:

• fitted symbols without manufacturer or full MPN;
• footprints without a reviewed package mapping;
• unresolved text variables or missing project libraries;
• unknown tool version or uncommitted generated changes;
• DNP state that differs between schematic, BOM, and placement data;
• requirements or rule profiles not tied to a revision.

For generated libraries, require a primary-document pin contract. ERC cannot detect a consistently wrong symbol and footprint mapping, as explained in why LLMs hallucinate pin numbers.

Layer 2: deterministic KiCad checks

Run checks in a clean build directory and make violations fail the command. A KiCad 9 shell skeleton is:

#!/usr/bin/env bash
set -euo pipefail

SCH="hardware/controller.kicad_sch"
PCB="hardware/controller.kicad_pcb"
OUT="build/release"

rm -rf "$OUT"
mkdir -p "$OUT/checks" "$OUT/gerbers" "$OUT/drill" "$OUT/assembly"

kicad-cli sch erc \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o "$OUT/checks/erc.rpt" \
  "$SCH"

kicad-cli pcb drc \
  --schematic-parity \
  --severity-error --severity-warning \
  --exit-code-violations \
  -o "$OUT/checks/drc.rpt" \
  "$PCB"

--exit-code-violations makes KiCad return a nonzero status when reported violations exist. --schematic-parity checks that the PCB agrees with the schematic. This is the core of headless KiCad automation, but it is not the whole gate.

Do not make CI green by suppressing warnings globally. Each exclusion needs a technical reason, owner, source location, and review. Prefer fixing rule configuration or the design.

Layer 3: sourcing and assembly consistency

Export the BOM from the checked schematic, not a manually maintained copy:

kicad-cli sch export bom \
  --fields 'Reference,Value,Footprint,Manufacturer,MPN,${QUANTITY},${DNP}' \
  --labels 'Refs,Value,Footprint,Manufacturer,MPN,Qty,DNP' \
  --group-by 'Value,Footprint,Manufacturer,MPN' \
  --exclude-dnp \
  -o "$OUT/assembly/bom.csv" \
  "$SCH"

kicad-cli pcb export pos \
  --format csv --units mm --side both --exclude-dnp \
  -o "$OUT/assembly/positions.csv" \
  "$PCB"

Add scripts that compare fitted reference sets, reject duplicate positions, require exact MPNs, validate allowed footprints, and check live stock/lifecycle for critical parts. Confirm the assembler’s chosen catalog entry maps to the same MPN and physical package. A syntactically valid BOM/CPL pair can still specify the wrong component.

Layer 4: regenerate fabrication data from scratch

Never promote files left by an earlier run. Plot into the empty release directory:

kicad-cli pcb export gerbers \
  --layers F.Cu,B.Cu,F.Mask,B.Mask,F.Silkscreen,B.Silkscreen,Edge.Cuts \
  -o "$OUT/gerbers/" \
  "$PCB"

kicad-cli pcb export drill \
  --format excellon --excellon-units mm \
  --generate-map --map-format pdf \
  -o "$OUT/drill/" \
  "$PCB"

test -s "$OUT/assembly/bom.csv"
test -s "$OUT/assembly/positions.csv"

Parameterize the layer list for the actual stackup; a four-layer board needs its inner copper files. Assert expected layer and drill filenames, a single board outline, nonempty copper, and consistent origins. Apply the shop-specific limits in the PCB DFM checklist.

Generate hashes after every artifact is final:

find "$OUT" -type f ! -name SHA256SUMS -print \
  | LC_ALL=C sort \
  | while IFS= read -r file; do shasum -a 256 "$file"; done \
  > "$OUT/SHA256SUMS"

The source commit and checksum file let purchasing prove which bytes were approved and uploaded.

Layer 5: human visual and engineering review

Automation cannot decide every physical question. Require named sign-off for:

• schematic power, reset/boot, protection, and critical circuits;
• exact symbol-to-footprint pin mappings;
• decoupling, current loops, return paths, RF/high-speed geometry, and thermal design;
• connector orientation, enclosure clearance, test access, and polarity markings;
• Gerber/drill overlay and board outline;
• assembly preview, rotations, bottom-side mirroring, and DNP population;
• fabrication quote options against the intended stackup and finish.

The reviewer must inspect the generated outputs, not only the KiCad canvas. The manufacturer’s renderer is another independent view and should match the local Gerber review.

For production or expensive prototypes, separate design approval from order placement. Purchasing should upload only an archive whose checksum matches the signed release record. That small two-person boundary prevents an engineer’s scratch export or a portal-side edit from bypassing the gate.

A gate checks release quality, not product function

A clean gate proves that encoded rules passed and the released artifacts are consistent. It does not prove the circuit meets requirements, survives faults, passes EMC, or works across temperature. Physical bring-up and verification remain part of the product plan.

This boundary is also where a pipeline such as MakeIRL can be useful: the value is not merely generating a board, but making evidence-backed checks unavoidable before manufacture. Any tool should be judged by the artifacts and controls it exposes.

The gate matters more than an AI designer because it contains errors from every designer. It turns speed into safe iteration: generate freely, fail visibly, approve deliberately, and order only one traceable release.