---
name: eda-bridge-standard
public: true
description: >-
  The standard every Adom EDA bridge follows so one AI can drive Altium, KiCad, Fusion 360 and any future PCB tool the
  same way: the shared verb names in tiers (core, native, checks, app, platform), the board model JSON every
  <prefix>_routing_state returns (mm, KiCad copper layer names, revision guard), the reply and refusal conventions, and
  how far each bridge covers it. Altium bridge is the reference for the board model and checks; any bridge can propose
  verbs (tools/proposed/<thread>.json). Use when building or extending an EDA bridge, adding a
  verb to kicad/fusion/altium bridges, porting a check between bridges, comparing what each bridge can do, or reading a
  board model from any bridge. Trigger words: eda bridge standard, bridge parity, same verbs every eda tool, board model
  json, routing_state schema, port altium verb to kicad, what can the kicad bridge not do, standard verb names.
---

# eda-bridge-standard

The standard for Adom EDA bridges. The Altium bridge is the reference for the board model, the conventions and the
checks; verbs come from any bridge. Altium's verbs were the first list, and other bridges add verbs through
`tools/proposed/<thread>.json` once another bridge's thread agrees. The standard-lane thread keeps the page: reach it with an
issue whose title starts with your thread's name (the pinned issue says how).

## Read first

| File | What it holds |
|---|---|
| `verbs/standard.json` | every standard verb: name (no prefix), tier, summary, input, output, hint, pitfalls, related, example |
| `docs/coverage.md` | each verb on Altium, KiCad and Fusion 360: exact, partial or missing |
| `schema/board.schema.json` | the board model (`<prefix>_routing_state`) |
| `schema/companions.schema.json` | stack-up, poured copper, 3D bodies, sheet parts with pin types, netlist |
| `docs/board-model.md` | the board model's rules, with the reasons |
| `docs/conventions.md` | names, units, the reply envelope, refusal codes, how to treat the user's tool |

## When you add a verb to a bridge

1. Look the job up in `verbs/standard.json` and use that name with your prefix (`kicad_return_path`), its inputs and
   its output keys. If the standard does not have it, propose it on an issue, then in `tools/proposed/<thread>.json` (README, *Proposing a
   verb*): neutral name and shape, and `agreedBy` from another bridge's thread before it lands.
2. If your tool does the job under its own verb already, keep it and add the standard name as an alias.
3. Reply with `success`, `errorCode` and `error` on refusal, and a `_hint` that says the next step. Take
   `expectedRevision` on edits; offer `dryRun` where a plan can be wrong.
4. Push the bridge's verb list (`<prefix>_describe`) as `reference/<bridge>-<version>.json` from a fresh clone of the
   page's head, that file only, and say so on an issue. The standard-lane thread regenerates `docs/coverage.md`; a
   bridge thread does not run `generate.py` and push its outputs (README, *Keeping it in sync*).

## When you port a check (the checks tier)

The checks are computed from the board model and its companions, not by the tool. A bridge that returns the board
model exactly as the schema says can run them from the shared engine, `engine/` on this page (`adom-eda-checks`:
a Rust crate and a command; `copper_balance`, `return_path`, `fab_check`, `impedance`, `current_capacity` so far). The
checks not yet moved are still in the Altium bridge's Rust (`bridge-rs/src/` in adom/altium-bridge).
Planners (pair routes, serpentines, designators, via fences, thermal vias, panels) answer geometry; each bridge applies it
with its own core verbs (`route_net`, `place_vias`, `apply_silkscreen`).

## Rules that bite

- Millimetres, absolute, the tool's origin with y up (a y-down tool negates y, nothing else): what `routing_state`
  reports is what `route_net` takes.
- Copper layers as `F.Cu`, `In<n>.Cu`, `B.Cu`, `*.Cu` on every tool.
- A custom-shape pad is reported as its bounding rectangle, never 0 x 0, with its real outline in `copperPoints` when
  the bridge can read it.
- `unconnected` is computed from the copper; poured copper that reaches nothing else of its net goes in
  `isolatedCopper`, not the count. A stray track or via counts.
- Replies in mm, unit-named fields as `xMm`.
- Net-less copper (a hatched pour's pieces) stays in the model with an empty net.
- Fab limits come from adom/pcb-design-rules, with the vendor page and date in the reply.