Use case · Library
One approved library, kept consistent while projects move.
Libraries drift: duplicates accumulate, footprints fork per project, and parts go stale after approval. Circuitly audits the library itself and proposes fixes as diffs — the per-design risk of a part already on a board is covered under component and supply-chain risk.
The problem
An approved library is only approved at the moment of approval. Then it drifts: two engineers add the same MCU with different pin maps, a footprint gets tweaked inside one project and never flows back, a datasheet revs, a part goes NRND. Nobody audits the library because auditing it is nobody's job — until a board inherits the wrong variant.
Connected workflow
Circuitly connects the library the way it already lives — repositories, project forks, and the availability data behind the parts — then audits it continuously and proposes corrections as reviewable diffs. Your approved-parts.md policy runs as a check, so the library is held to the rules your team wrote down.
Connect
Libraries, project repositories, and component data sources.
Audit
Duplicates, footprint drift, datasheet revisions, and lifecycle status.
Propose
Merges, deprecations, and updates prepared as diffs with evidence.
Approve
The library owner decides what changes and what stands.
Audit output
- Two STM32F103C8T6 symbols with different pin maps — flagged with a proposed merge
- Pad geometry that diverged between two projects, traced to the fork that caused it
- An approved part now marked NRND in the connected availability data
- Violations of
approved-parts.md— your library policy applied as a check, not a wiki page
Owner decision
Deprecating or merging a part is always a human call — production boards depend on it. Circuitly surfaces the drift and prepares the change; the library owner decides what the team builds on.
Find out what your approved library actually contains.
We’ll map your libraries, the drift worth catching, and the approval flow your library owner keeps.