Generate a Raspberry Pi Pico Carrier with AI: Scope Guide

MakeIRL's generator treats a Raspberry Pi Pico carrier prompt as a module carrier. Current status: in envelope needs block.

Pico/Pico W carriers are in the intended envelope, but no exact module block is currently cataloged. Pico W also invokes RF policy even if its pin rows resemble Pico.

MakeIRL V2 extracts a strict CarrierSpec from the prompt, applies a deterministic scope policy, resolves only cataloged blocks, composes deterministic connectivity and exact-MPN BOM data, emits KiCad artifacts, and runs the manufacturing gate. The language model does not invent pins, topology, parts, placement, routing, or substitutions.

1. Exact Pico/Pico W/module revision, header or castellated mounting, pin map, VSYS/VBUS/3V3 direction, USB ownership, RUN, SWD, and BOOTSEL access
2. Peripheral pin assignments, Qwiic/UART/SPI/GPIO connectors, aggregate current, protection, dual-source/backfeed, and firmware
3. Module overhang and USB face, socket height, antenna keepout for Pico W, mounting, enclosure, test pads, and removal access

Block plan:

• Future verified exact Raspberry Pi Pico module/footprint and power block
• Verified Qwiic/status and low-speed connector blocks
• Pico W RF use remains refused unless radio-module policy changes and evidence is added

Interfaces: GPIO/I²C/UART/slow SPI, module-owned USB, SWD/RUN/BOOTSEL. Power plan: Use Pico VSYS/VBUS/3V3 according to official direction and limits, avoid dual-source backfeed, and stay within 12 V/2 A overall envelope.

• Keep module USB, BOOTSEL and SWD accessible, align both 2.54 mm rows and overhang, support socket loads, and preserve Pico W antenna keepout.
• Freeze the board outline, mounting holes, connector faces, component height zones, test access, and keepouts before evaluating generated placement or routing.

Gate checks:

1. S1Generated connectivity and schematic parity. Verify exact Pico variant, forty-pin mapping/view, power direction and backfeed, RUN/SWD/BOOTSEL, connector voltages, module orientation, and mechanical row spacing.
2. S1Catalog and exact-MPN provenance. Every Raspberry Pi Pico carrier block, footprint, pin map, required companion, BOM line, and block-status claim must resolve to the pinned catalog version; the prompt cannot create missing hardware.
3. S2PCB DRC, fabrication profile, and release identity. Run KiCad DRC and schematic parity, compare geometry with one quoted fab profile, regenerate Gerbers/drills/BOM/CPL from the approved revision, and inspect both local and supplier previews.

• Review Pico versus Pico W differences, USB/power architecture, module regulator current, ADC reference/noise, RF keepout, socket mechanics, and firmware recovery.
• A reviewer must check primary datasheets, exact symbol-to-footprint mapping, power and protection, return paths, connector orientation, mechanical fit, test coverage, and every gate waiver before release.

Failure modes:

• Feeding VBUS and VSYS from conflicting sources can backfeed a host or supply, and a reversed 2×20 mapping can look mechanically correct.
• ERC and DRC can prove encoded consistency but cannot prove requirements, component source truth, analogue stability, RF/EMI, thermal margin, firmware, safety, compliance, or delivered product function.

Validation plan:

• A future block needs fit with real headers and module, USB/BOOTSEL/SWD, every exposed rail/pin, dual-source cases, Qwiic, current/thermal, and Pico W RF tests if ever allowed.
• Bring up first articles with current limiting, measure every rail before fitting expensive modules, program minimal test firmware, exercise every interface and fault assumption, and retain measurements against the released revision.

• Refuse unspecified Pico variants, Pico W radio use, battery charging, motors, or unknown module clones.
• A Pico module carrier is distinct from a bare RP2040 minimal design and needs separate verified evidence.

The intended carrier envelope is 2-layer FR-4, at most 100 × 100 mm, at most 40 BOM lines, at most 12 V SELV and 2 A, with cataloged modules and low-speed I²C, UART, GPIO, slow SPI, or power-only USB-C connections. The current catalog is narrower than that intended envelope.

Deterministic policy refuses unsupported or hazardous requests, including mains, motors, lithium charging, RF design, switch-mode power, high-speed buses, excessive size/current, and unknown modules. A refusal is a safety and truthfulness result, not a failed attempt to improvise a circuit.

The current seed catalog contains ESP32-C3 carrier, USB-C power, and Qwiic/status-LED blocks at checked status. They have passed deterministic checks but are not yet physically verified through the documented two-lot bring-up ladder; pages must not call those current seeds verified.

The output is a gated design candidate for engineering review. Current placement/routing can still produce blocking or review findings, so a generated board is not automatically fab-ready, functionally validated, certified, or safe to order. MakeIRL does not autonomously place a fabrication order from a prompt. Human review, source and output inspection, gate resolution, order-specific fab confirmation, and physical bring-up remain required.