When we explain what CADY does, we get a consistent question: why analyze the netlist instead of the schematic directly? The schematic is what the engineer drew. Analyzing it directly feels more natural. The answer has to do with what information is actually in each representation and what a rule engine needs to operate reliably.
This article explains the structural difference between a schematic and a netlist, what each format preserves and loses, and why working at the netlist layer is the right choice for the kind of checks CADY runs.
What a schematic is
A schematic is a visual document. It contains graphical objects (symbols, wires, buses, labels, power flags) arranged on a canvas in a way that communicates the circuit's design intent to a human reader. The same electrical circuit can be drawn in many different ways on a schematic while remaining electrically identical: components can be placed in different positions, wires can take different paths, labels can be used instead of direct wire connections between symbols.
This is a feature, not a problem. Schematics are optimized for human comprehension. Engineers organize symbols by functional block, use net labels to avoid long wire runs across a page, and use hierarchical sheets to break a complex design into reviewable sub-sections. The visual organization carries meaning to a human reader that a tool cannot extract from positions and wire paths alone.
The consequence is that a schematic is not a clean data structure for automated analysis. The electrical connectivity is implicit: it depends on wire junction detection, label matching, bus expansion rules, and hierarchical port resolution. These rules are consistently implemented in EDA tools, but extracting them programmatically from a proprietary schematic file format is expensive and fragile.
What a netlist is
A netlist is the result of applying all connectivity resolution rules to a schematic. It is the EDA tool's own answer to the question: given this schematic, what are the electrical connections? The output is a flat table of three elements: component instances (with reference designators and properties), pins (with component assignment and pin type), and nets (with the list of pins connected to each).
A netlist has no positions, no wire paths, no visual organization. It only has connectivity. From a netlist, you can determine exactly which pins are electrically connected to which other pins, what components are present in the design, and what properties those components carry (value, footprint, manufacturer part number). You cannot determine how the components were arranged on the schematic sheet, or why the engineer chose a particular signal path.
This makes netlists ideal for automated checking. The information needed to evaluate connectivity rules, BOM consistency rules, pin type rules, and power supply structure rules is all present in the netlist, in a structured and well-defined format. The information that is absent (visual arrangement, designer intent) is information that automated rules cannot reason about correctly anyway. For a detailed look at how CADY converts that structured data into a component graph and runs predicate rules over it, see Automating Schematic Design Review with a Rule Engine.
What gets lost in netlist export
Understanding what the netlist does not contain is important for setting realistic expectations about what CADY can and cannot check.
Physical proximity is not preserved. A netlist tells you that a bypass capacitor is connected to the same supply net as a power pin, but not whether the capacitor is placed near the power pin or at the other end of the schematic sheet. Physical proximity concerns become layout concerns, not schematic concerns, once the netlist is extracted.
Human-readable annotations are partially preserved. Component values and reference designators are present. Schematic notes, text labels that are not net labels, and block borders used for visual organization are not. If a schematic note says "place R12 within 2mm of U4," that note does not appear in the netlist.
Bus expansion detail is resolved away. A bus carrying 8-bit data has 8 individual net entries in the netlist (DATA[0] through DATA[7]). The bus grouping is gone. Rules that need to know a net is part of a bus group must infer that from the net naming convention, which is reliable for standard naming patterns but not universal.
Hierarchical structure is partially preserved, depending on format. KiCad's XML netlist export preserves hierarchical sheet paths in net names. Altium's IPC-2581 format flattens hierarchy into a single component and net list. The flat representation is usually sufficient for connectivity checks; some custom rules that need to know which sheet a component lives on may need the hierarchical form.
Why not analyze the schematic image directly
An alternative approach to automated schematic review would be to analyze a rendered image of the schematic using computer vision. This approach was explored in several academic and commercial projects in the early 2020s and remains an active research area. It is not what CADY does, and the reasons are worth explaining.
Image analysis of schematics is unreliable for the kinds of checks that matter for design rule verification. Determining that a specific pin on a specific component is connected to a specific net requires reading component reference designators, matching them to a pin definition table, identifying which wire segment connects to which pin, and tracing that wire to its terminal net label. This chain of steps degrades in accuracy with schematic complexity, non-standard symbol shapes, overlapping wire segments, and handwriting or non-standard fonts in labels.
More fundamentally, image analysis produces probabilistic outputs. An image model might determine with 92% confidence that a particular capacitor is connected to the VCC net. Schematic checking requires deterministic outputs: a component is either connected to that net or it is not. A connectivity check result that is correct 92% of the time is not useful for design rule verification.
The netlist is already the deterministic connectivity model that the EDA tool computed from the schematic. Using the netlist means we are analyzing the authoritative answer to the connectivity question, not inferring it from pixels.
What this means in practice for CADY users
When you submit a netlist to CADY, the review operates on the connectivity and component data that your EDA tool extracted from your schematic. CADY's rule engine evaluates this data against the rule library and reports violations.
CADY does not parse your schematic's visual representation, does not interpret schematic notes or annotations that are not part of the netlist structure, and does not infer design intent from visual organization. Rules fire based on what is structurally present or absent in the netlist data.
This means that if your EDA tool's netlist export has an error or omission, CADY's analysis will reflect that error. If a hierarchical port is missing from an export, the net on the other side of the hierarchy boundary will appear disconnected in the netlist, and CADY will flag it as undriven. The fix is to correct the schematic and re-export, not to add a rule exception.
Working at the netlist layer gives CADY the precision needed for reliable design rule checking. It also means CADY's checks are tool-agnostic: the same rule library applies to a KiCad netlist and an Altium IPC-2581 export because both are representations of the same underlying connectivity model, regardless of which tool produced the schematic.