OpenComponentCards: Real Tolerance Data for the Parts You Already Use

I'm not an electronics engineer. I want to say that up front.

But I spotted a gap, and I wanted to see if it was real. So I used Grok and AI assistants to research it, including two Grok DeepSearch runs. The gap held up. This is my first try at filling it.

What SPICE and IBIS Models Are Missing

Engineers simulate circuits with model files they already know: SPICE, IBIS, Touchstone, and Verilog-A. Those files are useful. But three things are missing.

Real tolerance distributions. Libraries give a nominal value, or min, typical, and max. They don't say how parts actually spread. So engineers guess the spread from datasheet limits when they run a simulation.

A record of how a model was built and checked. Did it come from physics, from data, or both? Was it ever compared to real measurements?

Signed, versioned models. Trust today comes from vendor reputation, official download sites, and file headers. Software and AI models get signed and tracked. Electronics models mostly don't.

What OpenComponentCards Is: Tolerance Data Next to Your Model Files

It's a thin card layer that sits next to the model files you already use. It doesn't replace them.

Each Component Card is a small YAML file. It adds three things:

1. How much the part varies. Each key value gets a probability distribution with a stated basis and confidence.
2. Where the numbers came from and how they were checked. Sources, method, and a maturity level.
3. Who made it and which version it is. Author, date, signature, and a link to the previous version.

Each card points to its model file by a content hash, so it's tied to that exact file.

How Signed Component Cards Work (Git and Sigstore)

Cards live in git and get signed with Sigstore. The hash and signature cover the exact bytes of the card, so any change is a new version.

No blockchain. It adds complexity and can turn engineers off before they look at the real work.

Here's what signing does today, straight up. Right now the repo signs its own cards, and that mostly proves what git history already shows. It's groundwork. Signing starts to really matter once trusted signers, like manufacturers or test labs, publish and sign their own cards. So the first question isn't how to sign. It's who should be trusted to sign.

A signature proves who published a card and that it hasn't changed. It doesn't prove the numbers are right. That's what the maturity levels and sources are for.

What OpenComponentCards Isn't

It isn't manufacturer statistics. Every spread in the example cards is an assumption. The real-data cards use published datasheet limits, but datasheets don't say how parts are actually distributed inside those limits. Real parts are often tighter, off-center, or shaped differently.

It isn't a new model format.

It isn't a finished standard. v0.2 is still a starting point, and fields will change.

What Shipped in v0.1: Schema, Example Cards, and a Validator

• A JSON Schema for cards.
• Three example cards: a generic 10k resistor, a 10 uF X5R ceramic capacitor, and an N-channel power MOSFET tied to a SPICE file.
• Two real-data cards, built from actual datasheets (more on that below).
• A validator that checks rules the schema can't, like whether a correlation matrix can actually be sampled. All five cards pass.

Code, schema, and tools are Apache-2.0. Card data is CC-BY-4.0.

It also borrows from good work that already exists: IBIS revision and quality levels, the evidence and confidence pattern from datasheet2spice, and model cards from the software and AI world.

Real Datasheet Cards Within Hours

Within hours of putting this out, Drew Owens, an engineer at Adom, took it and ran with it. He built two real cards from Adom's datasheet-backed component pages: a Royalohm 4.7 Ohm resistor and a Samsung 4.7 uF capacitor. Every value carries its datasheet page number, and both passed the v0.1 validator without any changes.

He also wrote up seven suggestions for v0.2, from family cards that cover a whole part series to separating lot-to-lot spread from part-to-part spread. Each one became a GitHub issue, with his credit. His cards are in the repo as the first real-data cards, with his permission.

That's exactly what I was hoping for. Thank you.

What's New in v0.2

v0.2 shipped on October 13. Drew's seven notes turned into seven GitHub issues, and all seven were closed in a day. I used Grok and AI assistants to work through them, the same way I built v0.1.

• Datasheet limits field. Cards can now store the published limits on their own, apart from the assumed spread.
• Standard condition keys. Temperature, bias, and other test conditions use the same names on every card.
• Derived sources. A value worked out from other sources can say so and point back to them.
• Lot vs. device spread. A distributions list separates lot-to-lot spread from part-to-part spread.
• Model-binding transforms. Clearer rules for how a card value changes a parameter inside a model file.
• Family cards. One card can set rules for a whole part series, like the TCR bracket in Drew's Royalohm card.
• Signer trust. There's a public signer list and an open "Become a Signer" form on GitHub. The GrizzlyRay registry workflow is the first signer, and manufacturers and test labs can apply to be verified. A card can also carry more than one signature now.

There are two breaking changes. The migration guide is in the repo.

Release: OpenComponentCards v0.2

Open Questions: SPICE Monte Carlo Export and More

This is where engineers come in. One question already has a first answer. When the shape of a spread is unknown, the default will be uniform over the published limit. Drew made that call in his cards, and it's the honest choice. If all you've got is a limit, uniform doesn't pretend to know more than the datasheet says.

A few questions are still open:

• How should cards export to SPICE Monte Carlo syntax?
• Should cards map to CycloneDX so existing tools can read them?
• Do the v0.2 binding transforms hold up against real vendor subcircuit models?
• Is the signer list the right way for users to decide which signers to trust?

If you work with these models, tell me where this is wrong. Open an issue on GitHub. I'd rather hear it now than after people build on it.

Why I'm Doing This

I like finding problems that sit between fields. This one sits between electronics and the way software already handles trust. I don't have to be an expert in both to notice it. I do need people who are.

I'll give it a few weeks, see if people care, and decide what's next.

Repo: GrizzlyRay/opencomponentcards

Drew's write-up: Community: Open Component Cards

Here's my question: if you simulate circuits, how do you handle tolerance today?