RFD 0014Document view
Catalog
RFD 0014
draftmdx0014.mdx

Electronics Knowledge Base Sibling App

Scope a private sibling application for distilled electronics parts, datasheets, comparison sets, and reusable analysis patterns.

Authors
Ian Cleary
Updated
Jul 1, 2026, 12:00 AM

Summary

Build a follow-on private sibling application for electronics knowledge: parts, datasheets, comparison sets, design evidence, and reusable analysis patterns.

The motivation is practical: comparing parts and reading datasheets repeatedly creates useful judgment, but that judgment is usually trapped in PDFs, screenshots, spreadsheet fragments, chat threads, and temporary notes. The sibling app should turn those raw artifacts into durable, reviewable, structured knowledge that can be queried by humans and maintained by agents.

The recommendation is:

  1. Keep the current RFD site focused on RFDs and decision history.
  2. Use 0013 as the general compiled-knowledge pattern.
  3. Create a separate private sibling app or short-lived fork for electronics knowledge.
  4. Treat PDFs as immutable raw sources, not the final knowledge object.
  5. Distill datasheets and comparisons into typed pages, normalized fields, citations, analysis patterns, and reviewable diffs.
  6. Start read-only and file-backed before introducing a database, procurement integrations, or ECAD integrations.

Problem

Electronics work has a high bookkeeping burden.

A single component choice can require:

  • reading multiple datasheets,
  • comparing package options,
  • checking absolute maximum ratings and recommended operating conditions,
  • evaluating thermal margin,
  • confirming layout notes,
  • finding errata or footnotes,
  • checking lifecycle and availability,
  • finding alternates,
  • remembering why an earlier part was rejected,
  • preserving equations and assumptions for later review.

PDFs are the right raw source, but they are a poor working memory. They are hard to diff, hard to query across, hard to compare, and hard for future agents to use without rediscovering the same tables and caveats from scratch.

The desired artifact is not another PDF folder. It is a compiled electronics knowledge base.

Relationship to RFD 0013

0013 defines the general pattern: raw sources, compiled wiki pages, schema, ingest, query, lint, and agent-maintained loops.

This RFD specializes that pattern for electronics work.

The mapping is:

  • raw/ stores datasheets, app notes, screenshots, vendor pages, BOM exports, review notes, and test reports.
  • wiki/ stores distilled part pages, comparison pages, analysis patterns, decisions, and project usage notes.
  • AGENTS.md or an equivalent schema tells the agent how to extract, cite, validate, and lint electronics knowledge.
  • lint becomes engineering review: missing citations, stale lifecycle data, contradictory limits, unreviewed assumptions, orphaned parts, and analysis patterns without examples.

Product shape

The sibling app should be a private electronics knowledge base with a reader-first interface.

It should reuse the useful parts of the RFD app:

  • MDX rendering,
  • document shell,
  • table of contents,
  • search,
  • folder-backed assets,
  • dark technical reading environment,
  • git-backed review of agent-generated changes.

It should not inherit the RFD app's numeric-only page model as the primary product model. Electronics knowledge needs semantic routes and typed documents.

A possible route shape:

TEXT
/parts
/parts/:manufacturer/:partNumber
/comparisons/:slug
/analysis-patterns/:slug
/sources/:slug
/decisions/:slug
/projects/:slug
/questions/:slug

The first version can still be file-backed. A database should come later only when the content model proves stable.

Core page types

Part pages

A part page is the compiled working view of a component.

Recommended fields:

  • manufacturer,
  • manufacturer part number,
  • aliases and ordering codes,
  • category,
  • package and footprint assumptions,
  • lifecycle status,
  • availability notes,
  • key limits,
  • recommended operating conditions,
  • electrical characteristics that matter for selection,
  • thermal data,
  • layout guidance,
  • known caveats,
  • approved alternates,
  • rejected alternates,
  • source citations,
  • projects that use the part,
  • review status.

Part pages should cite datasheet page numbers, table names, figure names, or source paths for every extracted engineering claim.

Datasheet extract pages

Datasheet extract pages normalize the important contents of a PDF into structured, reviewable form.

Examples:

  • absolute maximum ratings,
  • recommended operating conditions,
  • electrical characteristics,
  • timing tables,
  • package and footprint notes,
  • thermal resistance and power dissipation guidance,
  • application circuits,
  • layout recommendations,
  • revision history,
  • footnotes and caveats.

The source PDF remains immutable. The extract is the compiled artifact.

Comparison pages

Comparison pages capture side-by-side selection work.

Examples:

  • buck regulator alternatives,
  • op-amp candidates for a sensor front end,
  • connector families for a harness,
  • MCU options,
  • RF amplifier or filter candidates,
  • power MOSFET substitutes,
  • passives under voltage, tolerance, or derating constraints.

A comparison should include:

  • the selection context,
  • must-have constraints,
  • nice-to-have constraints,
  • candidate table,
  • disqualifiers,
  • tradeoffs,
  • recommended choice,
  • rejected choices,
  • open questions,
  • citations.

Analysis-pattern pages

An analysis pattern is a reusable engineering check.

Examples:

  • regulator thermal margin,
  • input capacitor ripple current,
  • output capacitor stability requirements,
  • op-amp input bias current error,
  • op-amp stability with capacitive load,
  • ADC drive impedance and acquisition time,
  • RF link budget assumptions,
  • connector current derating,
  • creepage and clearance,
  • ESD protection placement,
  • power sequencing,
  • reset supervisor thresholds,
  • oscillator load capacitance,
  • pull-up resistor sizing,
  • LED resistor sizing,
  • fuse or polyfuse hold/trip margin.

A pattern page should include:

  • when to use it,
  • inputs required,
  • equations or checks,
  • assumptions,
  • pass/fail guidance,
  • worked examples,
  • common traps,
  • source citations,
  • links to parts or projects where the pattern was applied.

Design-evidence pages

Design-evidence pages explain why a part or pattern was accepted, rejected, or deferred.

They should preserve:

  • assumptions,
  • calculations,
  • screenshots,
  • calculator outputs,
  • bench measurements,
  • review comments,
  • decision records,
  • links to the source PDFs and compiled pages.

This is the bridge between a component database and engineering judgment.

File-backed first structure

Start with a file-backed repository, not a production database.

TEXT
electronics-kb/
  AGENTS.md
  raw/
    datasheets/
    app-notes/
    screenshots/
    bom-exports/
    test-reports/
  wiki/
    index.md
    log.md
    parts/
    datasheet-extracts/
    comparisons/
    analysis-patterns/
    design-evidence/
    decisions/
    projects/
    questions/
    contradictions.md
    lint.md
  schemas/
    part.schema.json
    comparison.schema.json
    analysis-pattern.schema.json

This keeps the first implementation inspectable. Agents can propose diffs. Humans can review the compiled knowledge. The app can render the files. A database can be introduced later after the schema stops changing every week.

Agent workflows

Datasheet ingest

When given a datasheet, the agent should:

  1. Save the PDF or source artifact under raw/datasheets/.
  2. Extract text and tables where possible.
  3. Create or update a datasheet extract page.
  4. Create or update the part page.
  5. Capture important caveats, footnotes, and layout notes.
  6. Cite source page numbers or table names.
  7. Update comparison pages if the part is a candidate in an active selection.
  8. Update analysis-pattern pages if the datasheet teaches a reusable check.
  9. Append the ingest to wiki/log.md.
  10. Produce a reviewable diff.

Part comparison

When comparing parts, the agent should:

  1. Read the comparison context and constraints.
  2. Identify candidate parts and raw sources.
  3. Extract normalized fields into a candidate table.
  4. Mark disqualifiers explicitly.
  5. Separate hard constraints from preferences.
  6. Recommend a choice only after citing the relevant source claims.
  7. Record rejected alternatives and why they failed.
  8. Update affected part pages and design-evidence pages.

Analysis-pattern creation

When a recurring calculation or review check appears, the agent should ask whether it belongs in wiki/analysis-patterns/.

A good analysis-pattern page should be reusable without the original chat thread. It should state inputs, equations, assumptions, pass/fail logic, examples, and traps.

Lint

Electronics knowledge lint should ask:

  • Which part pages lack source citations?
  • Which extracted limits conflict across datasheet revisions?
  • Which parts have no lifecycle or availability status?
  • Which approved parts lack project usage or design evidence?
  • Which comparison pages have stale candidate availability?
  • Which calculations lack units or assumptions?
  • Which analysis patterns have no worked example?
  • Which raw datasheets have not been compiled into extract pages?
  • Which source PDFs are superseded by newer revisions?
  • Which alternates are approved without explaining what makes them safe substitutes?

Database later

A database may eventually be useful, but not first.

Good reasons to introduce one:

  • filtering thousands of parts,
  • faceted search by electrical characteristics,
  • joining BOM exports to approved parts,
  • tracking supplier or lifecycle updates,
  • rendering comparison matrices dynamically,
  • connecting to ECAD artifacts,
  • permissioning at team, project, source, or part level.

Bad reasons to introduce one:

  • the first schema feels obvious,
  • PDFs are annoying,
  • a table UI looks more product-like,
  • the app might someday need integrations.

The first database should be downstream of reviewed files, or generated from them, until the editing and review workflow is proven.

Relationship to ECAD review

This app should eventually complement ECAD review tooling.

Possible integrations:

  • import BOMs from PCB or schematic outputs,
  • link parts to schematic symbols and footprints,
  • flag unapproved or unknown parts,
  • compare BOM values against approved part constraints,
  • surface analysis patterns relevant to a net or subsystem,
  • attach design evidence to PCB review findings,
  • detect parts whose datasheet layout guidance conflicts with board implementation.

The first implementation should not require ECAD integration. Start with datasheets, comparisons, and analysis patterns. Integrate with ECAD only after the compiled knowledge layer is useful on its own.

Security and permissions

Electronics knowledge may include proprietary designs, supplier information, customer requirements, and unreleased product details.

The sibling app should be private by default. Before sensitive material is added, it should support:

  • deny-by-default authentication,
  • organization or team membership checks,
  • source-level visibility,
  • filtered search indexes,
  • no restricted metadata leakage,
  • audit trails for reads and agent edits,
  • review gates for agent-generated changes.

Initial rollout

  1. Create a private file-backed electronics-kb repo or folder.
  2. Choose one narrow domain, such as buck regulators or op-amps.
  3. Seed it with ten or fewer datasheets and one active comparison.
  4. Define part, datasheet-extract, comparison, and analysis-pattern templates.
  5. Run manual Codex ingest on each datasheet.
  6. Review diffs as if they were code.
  7. Create two or three analysis-pattern pages from real comparison work.
  8. Build a read-only sibling app view over the files.
  9. Add lint before adding integrations.
  10. Add database-backed search only after the file-backed model proves stable.

Open questions

  • Should the first version live as a standalone private repo, inside a sibling app repo, or inside an existing electronics project repo?
  • Which first component family is most useful: regulators, op-amps, connectors, MCUs, RF parts, or power devices?
  • What is the minimum citation format for datasheet claims?
  • Should extracted tables be markdown, JSON, YAML, CSV, or generated from a richer schema?
  • Which checks should be deterministic calculators versus agent-maintained analysis-pattern pages?
  • How should approved alternates be represented so they are useful but not over-trusted?
  • When should ECAD/BOM integration begin?

Determination

Create a follow-on RFD for a private electronics knowledge-base sibling app.

The app should not start as a procurement database or a PDF viewer. It should start as a compiled knowledge system for electronics decisions: parts, datasheet extracts, comparison sets, analysis patterns, and design evidence.

Use files first. Use agents to ingest and maintain structured knowledge. Use human review for engineering claims. Add a database, supplier integrations, and ECAD integrations only after the distilled forms prove useful.

RFD 0014 · Electronics Knowledge Base Sibling App