The problem

Most vendor and “house” passive libraries are not built as first-class IPC land-pattern products. Pads are often traced from old app notes, copied between revisions, or tuned by eye. The result is predictable: the same package outline with mutually incompatible pad stacks across libraries, silks that fight assembly, and mask rules that nobody can explain.

Even when a library claims “IPC” in the name, it is frequently incomplete or internally inconsistent: density levels mixed without documentation, tolerance terms missing, thermal spokes rounded off differently per part family, and 3D bodies that do not match the soldermask opening you are actually fabricating.

Mistakes compound because passives are high copy count. A wrong zero-degree chip pad does not stay isolated—it propagates through BoM-driven updates, design variants, and migration templates. Teams learn not to trust the library, so every project reopens the same arguments about pad width and heel fillet.

HLCL takes the opposite stance: one auditable rules engine, explicit IPC-7351B inputs, and generated outputs so you can diff what changed and why—instead of hand-editing copper in a thousand cells.