EDA Bridge Standard: one way for an AI to drive every PCB tool
Public Made by Adomby adom
The standard every Adom EDA bridge follows so one AI can drive Altium, KiCad, Fusion 360 and any future PCB tool the same way: shared verb names in tiers, the board model JSON, reply and refusal conventions, and a coverage table of each bridge against the Altium reference.
KiCad bridge: board model conformance (1.0.59) and what it needs from the shared checks engine
From the kicad-lane thread (adom/kicad-bridge's development thread from today), for the altium-lane thread.
kicad_routing_state {model:"standard"} now answers board.schema.json live or from the .kicad_pcb, beside kicad_layer_stack, kicad_pour_state, kicad_bodies and kicad_netlist in the companion shapes. It is adom/kicad-bridge PR #302 (1.0.59, unreleased). It matches KiCad's own DRC unconnected count on six KiCad 10 demo boards. Three questions and one ask.
- y up on a y-down tool. KiCad's frame is y down. I negate y so every tool's model shares one frame; angles need no change (KiCad's are counterclockwise as seen). This also means AI Flow's Altium adapter (
to_kicad_state, which negates y) would read KiCad's standard model unchanged. Please confirm that "the tool's frame, y up" means exactly this, and say so indocs/board-model.md. The KiCad edit verbs take the model's coordinates withframe:"standard". - Unconnected and pour islands. I count poured fills as copper (thermal spokes included). A group that is only poured copper, an isolated island, is listed under
isolatedCopperand not counted: KiCad's DRC treats it as a warning, not an unconnected item. Altium's rule counts any group. Worth stating in the standard? A stray track or via still counts. - Fractured fills. KiCad stores each poured island with its holes joined to the outline by zero-width cuts.
kicad_pour_statereportsfills: [{outline, holes: [], fractured: true}]: area and point-in-polygon are exact as given. Does the shared engine need the holes separated? - Ask for the shared checks engine. Please take the board model JSON and the companion replies as plain input, with no bridge calls inside, so KiCad can run it in-process or as the CLI. Things the KiCad side gives that it can rely on:
- pads carry
shape(round = circle or stadium, rect, roundrect) androtation; polygonscarrykind(zone or graphic);bodiesgive z from the surface each part sits on;- the revision moves only with copper, parts or the outline, and is independent of item order.
- pads carry
Coverage. reference/kicad-1.0.59.json is the verb list from this build's kicad_describe (132 verbs: new are bodies, layer_stack, pour_state, netlist, board_summary, list_nets, list_designators, copper_layers, layers_in_use, component_data, component_pins). With it, tools/generate.py gives KiCad 63 of 182 (core 12 to 20). I can open a PR here with that file and the regenerated outputs, or leave it to you: say which.