The one-file part library

Placing a part copies it into the project's own library — symbol, units, pins, every footprint variant, simulation model, vendor rows and all. You can see it as the Library node in the browser tree. From that moment the document resolves everything from its own copy.

A file you hand to somebody with zero libraries installed opens perfectly. That's the single most important property of the whole design, and it's why nothing ever resolves a part by path or by which library you happen to have installed. Where a part originally came from is recorded only so that an explicit "update from library" has something to compare against.

The document's library is never auto-pruned. Delete the last instance of a part, undo, and the definition is still there. Cleaning it up is an explicit action, not something that happens behind you.

A library of yours that shares an identity with a shipped one shadows it. Remove your overlay and the shipped copy comes back. You can't paint yourself into a corner.

The library manager lives in the part picker: import a library file, create an empty one of your own, or remove one you added.

Worth knowing, because it's what the rest of the workspace is built on:

• Typed pins. Every pin carries an electrical type — input, output, power input, open collector, no-connect and the rest — which is what makes the rules check able to say anything useful. Retrofitting types across a shipped library later is miserable, so they were mandatory from day one.
• Multi-unit symbols. An LM324 is four opamps plus a power unit, and the library says so, which is why placing four gates gives you U1A–U1D rather than four chips.
• Every footprint the part can use, each with its own label — "¼W axial, 0.4″ pitch" — and a pin map for the packages whose pad numbering doesn't match the symbol's.
• A simulation model. A primitive device, or a small internal netlist for anything with structure — a regulator, an optocoupler, a 555. A part with no model is not an error: it's captured, it's manufacturable, and it simply isn't simulated, reported by designator so you know what was skipped.
• Declared properties that become dialog fields, simulation parameters and BOM columns at once — see Part properties and datasheets.
• Vendor rows — see Designing around what's in stock.

Parts come in two flavours. A concrete part is a specific device — an NE555P — and its name is its value. A discrete class is a family — Resistor, Capacitor, LED — and the library carries exactly one of them. You type the value at placement and pick the footprint variant there too.

That single decision is what keeps a curated library a few hundred entries instead of a hundred thousand, and it's what makes the value you typed available for a live vendor lookup.

A library file records the format it was written in. An older one is brought up to date when it's opened; a newer one is rejected with a clear message rather than half-read. And the file carries its own description of its schema, so a library written by a newer JetCad3 arrives with enough information to be described rather than merely refused.