Community: Open Component Cards

OpenComponentCards is Jacob Warren's open draft format (GrizzlyRay LLC) for publishing how much a component varies. It's a good spec. Its data, as v0.1 says itself, is placeholder. This page shows that the Adom wiki already holds that data, sourced to datasheet pages, and includes two real cards built from it that pass Jacob's validator.

What a card is

A Component Card is a small YAML file that sits next to an existing model file (SPICE, IBIS, Touchstone, Verilog-A). It does not replace the model. It adds three things the model files leave out:

1. How much the part varies. A probability distribution for each key value, with a stated basis and a confidence.
2. Where the numbers came from. Sources with exact evidence (table, page), a method, and a maturity level modeled on IBIS quality levels.
3. Who published which version. Author, date, a sha256 link to the previous version, and a Sigstore signature.

The repo ships a JSON Schema (draft 2020-12), example cards for a resistor, a ceramic capacitor and a power MOSFET, a validator, and a GitHub Actions workflow that signs every card.

What the spec gets right

• Variation sits beside the model, not inside it. Vendor SPICE models stay untouched and are pinned by hash. That is the only way this can work with encrypted or licensed vendor models.
• Every number must say where it came from. basis and confidence are required on every distribution. Most tolerance data in the wild has neither.
• Part-to-part spread and "we're not sure" are kept apart. kind: population vs kind: epistemic, following GUM (JCGM 100/101). Those two get confused constantly in Monte Carlo setups.
• Correlation is first class, and checked. The validator confirms the matrix is symmetric, has a unit diagonal and is positive semidefinite, so it can drive sampling directly.
• It is upfront about its limits. The README says plainly that the example spreads are assumptions, not manufacturer statistics.

Our wiki has your data

The Adom wiki carries hundreds of component pages. Each one is built from the manufacturer's datasheet, and each spec row cites the datasheet page it came from. The datasheet PDF is mirrored on the page, so the source has a fixed URL and a hash. That covers most of what a card asks for:

What a page does not have yet is the tolerance in a form a program can read: the ±10% is in the Key specs text, not in a field. Adding that field is a small step for us, and once it's there each page can emit a card without anyone typing one.

Two real cards

Both cards are in this page's Files tab under cards/. Every value comes from an existing Adom component page and carries its datasheet page number. Both pass Jacob's v0.1 validator unchanged:

$ python3 tools/validate.py --schema schema/card.schema.json cards/*.yaml
schema card.schema.json: valid JSON Schema draft 2020-12

cards/royalohm-0603waf470kt5e.yaml: PASS
cards/samsung-cl21a475kaqnnng.yaml: PASS

2/2 cards passed

The resistor card, trimmed of its empty fields (the full file is in cards/):

card_version: "0.1"
id: occ:resistor/[email protected]
part:
  manufacturer: "Royalohm (UNI-ROYAL)"
  mpn: "0603WAF470KT5E"
  category: resistor
  description: "4.7 Ohm, 1%, 0603, thick film, 1/10 W, TCR +/-200 ppm/K"
  package: "0603"
model_files: []
parameters:
  - name: resistance
    unit: Ohm
    nominal: 4.7
    distribution:
      type: uniform
      applies_to: value
      kind: population
      params: { min: 4.653, max: 4.747 }
      basis: "Datasheet +/-1% tolerance (p.3). Shape not published; uniform over the limit."
      confidence: low
    conditions: { temperature_c: 25 }
    source_refs: [ds1]
  - name: tcr
    unit: ppm/K
    nominal: 0
    distribution:
      type: uniform
      applies_to: value
      kind: epistemic
      params: { min: -200, max: 200 }
      basis: "Datasheet TCR +/-200 ppm/K, the 0603 bracket for 1 to 10 Ohm (p.3). Values above 10 Ohm get +/-100 ppm/K."
      confidence: low
    source_refs: [ds1]
  - name: load_life_drift
    unit: "1"
    nominal: 0
    distribution:
      type: uniform
      applies_to: value
      kind: population
      params: { min: -0.0206, max: 0.0206 }
      basis: "Datasheet load life: Delta R within +/-(1% + 0.05 Ohm) (p.3). At 4.7 Ohm that is +/-0.097 Ohm, or +/-2.06%."
      confidence: low
    source_refs: [ds1]
derivation:
  kind: physics
  method: "R(T) = R25 * (1 + TCR * 1e-6 * (T - 25)), plus load-life drift; every spread is a datasheet limit"
validation:
  maturity: "1.0"
sources:
  - ref: ds1
    kind: datasheet
    uri: "https://wiki.adom.inc/download/aravk/0603waf470kt5e/1.0.0/0603WAF470KT5E-datasheet.pdf"
    sha256: "6344d3f6a60ea3d3a4c4726f3562df5847a0e5910ce0bd4356328c1363a25f0d"
    evidence: "p.1 ratings, p.3 tolerance, TCR and load-life table"
    confidence: high
provenance:
  author: "Adom (wiki.adom.inc), from the adom/0603waf470kt5e component page"
  created: "2026-10-13"
license: CC-BY-4.0

We used uniform distributions over the published limits throughout. Neither datasheet publishes a distribution shape, and with only a limit to go on, uniform is the conservative choice. That is our answer to the first question in Jacob's feedback list.

What we learned writing real cards (notes for v0.2)

Writing cards from real datasheets showed a few rough edges. All of these are suggestions:

1. Keep the datasheet limit as its own field. In a card, "±1%" only survives inside params and the basis text. A limits: {min, typ, max} block with its conditions would keep the published fact separate from the modeling choice, and lets two people model the same fact differently.
2. Family cards. One Royalohm datasheet covers the whole 0603WAF series, and the TCR bracket depends on the value (±200 ppm/K for 1 to 10 Ω, ±100 ppm/K above 10 Ω). One card per MPN repeats this hundreds of times. A family card with value-dependent rules, inherited by MPN, would scale.
3. A shared vocabulary for conditions. We had to invent frequency_hz, ac_vrms, temperature_min_c and a free-text preconditioning. A small vocabulary of standard keys would let tools compare cards.
4. A source kind for derived data. These cards come from a wiki page that cites the datasheet. kind: datasheet is close, but a way to record "derived from page X, which cites datasheet p.3" would make the chain explicit.
5. Lot-to-lot vs device-to-device spread. SPICE Monte Carlo separates LOT and DEV, and parts from one reel track each other. The schema has no place for that yet.
6. Machine-readable model binding. model_binding.transform is free text today. An enumerated set (offset, scale) would let an exporter apply it without a human reading the note.
7. Signing comes after deciding who signs. A signature from the repo's own workflow proves what git history already proves. Signing starts to matter once manufacturers or test labs publish cards, so who the trusted signers are is the question to answer first.

Why we care: Monte Carlo on real boards

Adom runs SPICE from an AI thread: ngspice in the container, LTspice and PSpice for TI on a Windows host for vendor models. Three engines are cross-checked against each other (SPICE Simulation Skills). A 2,000-run Monte Carlo of a Sallen-Key filter takes about 5 s on 16 cores. Today the tolerances in those runs are typed into the netlist by hand. Cards built from our component pages would let a Monte Carlo run use the real limits for the real parts on the board.

The 12 V to 5 V buck molecule shows that flow end to end, from prompt to circuit to three SPICE engines in agreement to layout:

Links

• Jacob's repo: github.com/GrizzlyRay/opencomponentcards (feedback goes in its issues)
• Source pages for the cards: adom/0603waf470kt5e, adom/cl21a475kaqnnng
• SPICE Simulation Skills
• Parts Search: Mouser, DigiKey and JLCPCB in one search

Card data on this page is CC-BY-4.0, matching the license Jacob's repo uses for cards.