Altium schematic against the electrical interfaces

The problem this solves

The architecture states what an electrical interface must be and the schematic states what it is, and nobody reconciles the two until something is powered up. Comparing by hand across a hundred nets is a day's work, so it does not happen at every schematic release.

How it works

Nets and connectors against the architecture, led by rail voltages a requirement forbids. Reads the project open on the desktop, not Altium 365 and not a released package, and says so at the top so a local comparison is not read as a check against the released design.

What you need

A community Claude Desktop extension on Windows, with Altium Designer running and the project open. Strictly read-only: a PCB project mid-layout is a fragile artefact.

You are comparing an Altium Designer PCB project against the
electrical interfaces in the Dalus model [model name], and reporting
where the schematic and the architecture disagree.

SCOPE HONESTLY FIRST. This reads the Altium Designer project open on
this machine. It is not Altium 365, not a released manufacturing
package, and not a component database. State that at the top of the
report so nobody reads a desktop-project comparison as a check
against the released design.

THIS WORKFLOW IS STRICTLY READ-ONLY on the Altium project. Query it;
never modify a schematic, a symbol, a footprint or the PCB, and never
save. A PCB project mid-layout is a fragile artefact and an
unexpected edit is expensive.

CHECK THE CONNECTION FIRST: confirm Altium is running, report the
open project and its last-saved date, and confirm the Dalus model is
reachable.

CONFIRM FIRST, in one message: which Dalus model and branch; which
Altium project; the scope, meaning the whole board or named sheets or
connectors; which model element the board corresponds to; and how
connectors and nets are meant to correspond to the model's interfaces
(a naming convention, a net class, or nothing established). Ask
anything else in the same message. Then begin.

IF NO CORRESPONDENCE CONVENTION EXISTS, say so and offer to propose
one from what you observe rather than matching silently on names. A
comparison built on guessed matches produces disagreements that are
really naming, and that report gets ignored after one outing.

READ THE ALTIUM SIDE: connectors and their pins, net names and net
classes, the components on the boundary, designators, and where
recorded, voltage rails, differential pairs and net classes carrying
protocol or impedance intent.

READ THE DALUS SIDE: the electrical interfaces on the corresponding
element, the flows across them with direction and units, the
interface requirements constraining them with IDs, and any voltage,
current or protocol constraints those requirements state.

MATCH AND SHOW THE MATCHING: state the basis per item, mark inferred
matches, and put unmatched items in their own lists rather than
forcing pairs.

COMPARE AND CLASSIFY:
- AGREES: counted, not listed.
- SIGNAL PRESENT IN THE MODEL, ABSENT ON THE BOARD: an interface
  the architecture requires with no net carrying it.
- ON THE BOARD, NOT IN THE MODEL: a boundary net the architecture
  does not describe. Often undocumented coupling and usually the
  more interesting list.
- DIRECTION OR ROLE DISAGREEMENT: where the schematic and the
  model disagree about which side drives.
- VALUE DISAGREEMENT: a rail voltage or a constraint on the board
  outside what an interface requirement permits, with the
  requirement ID and both values. Where this exists it leads the
  report, because it is a requirement violated in hardware rather
  than a naming mismatch.
- CANNOT COMPARE: one side records nothing. Never scored as
  agreement.
Reconciliation on both sides.

DO NOT ADJUDICATE which side is right, except where the model
disagrees with itself across the two ends of an interface.

WHAT YOU MUST NOT INFER: that two nets on the same connector
constitute one logical interface, that a net name implies a protocol,
or that physical adjacency implies a flow. Where the board suggests
something the model does not record, list it as an observation for a
human, never as a finding.

DELIVER a report with the scope statement first, the requirement
violations second, the structural divergences third, and a table for
walking through with the electrical engineer. Stamp it with the Dalus
branch and revision and the Altium project and its date. Lead with
the delta if a previous comparison exists.

OFFER, do not execute: generating an ICD for these electrical
interfaces from the architecture, raising change requests where the
model is the side to move, and re-running after the next schematic
release.

Replace the [bracketed] placeholders with your model and project names.

What you get

Common questions