← All work
Lab & experimentHighlighted LabElectronics · Computer architecture · Simulation R&DDocumentation foundation complete2026–Present

EEE Simulator

A decision-complete product and architecture foundation for a local-first virtual electronics laboratory that can grow from component-level evidence to educational computer systems without making infeasible full-transistor claims.

An open, browser-based electronics and computer simulation platform planned around explicit fidelity—from realistic component and circuit behavior to logic, processors, and educational computers.

Review source ↗

Project brief

The product context, ownership, and current evidence.

Target users

Electronics learners and educators, circuit and embedded engineers, component-model authors, and researchers exploring logic, processors, memory, and computer architecture.

Intended buyer outcome

A decision-complete product and architecture foundation for a local-first virtual electronics laboratory that can grow from component-level evidence to educational computer systems without making infeasible full-transistor claims.

Owned scope

Product research · Systems architecture · Simulation platform planning · Open-source delivery design

Evidence status

Product scope, architecture, 38 requirements, 10 accepted ADRs, a 162-family and 502-variant component baseline, release gates, validation strategy, and 3,090 atomic tasks are documented; runtime implementation has not started.

Problem

Electronics tools usually specialize in one layer: circuit solving, interactive education, digital logic, RTL, or architecture. Connecting those layers in one browser product requires explicit fidelity, deterministic co-simulation, bounded computation, validated models, and a staged release path that does not pretend a modern processor can run transistor-by-transistor in one tab.

Approach

Defined a hierarchical multi-fidelity product, a realistic-electronics-first roadmap, a Next.js and TypeScript browser shell, a Rust/WebAssembly simulation core, Worker-isolated execution, a versioned .eesim format, local/cloud workload boundaries, and traceable component, validation, security, accessibility, and licensing contracts.

Current outcome

The public repository has a complete documentation baseline and an implementation-ready task system. It does not yet contain application code, runtime configuration, a deployed simulator, or numerical validation evidence; the first Ready task establishes the repository layout before editor and solver work begins.

Maturity & lifecycle

What is complete, active, and still planned.

Product scope, architecture, 38 requirements, 10 accepted ADRs, a 162-family and 502-variant component baseline, release gates, validation strategy, and 3,090 atomic tasks are documented; runtime implementation has not started.

Evidence reviewed

  1. Discovery

    Complete

    The audience, cross-layer simulation problem, feasibility limits, fidelity model, and realistic-electronics-first product sequence were researched and documented.

  2. Scope & architecture

    Complete

    Normative requirements, ADRs, system boundaries, file and worker contracts, component taxonomy, release gates, risks, and validation strategy are defined.

  3. Design & prototype

    Planned

    The accessible schematic editor, physical component views, project format, local persistence, and first linear-circuit prototypes follow the repository-foundation task.

  4. Build & integrate

    Planned

    The React editor, Rust/WASM solver, deterministic digital scheduler, multi-fidelity adapters, instruments, and isolated cloud workers remain roadmap work.

  5. Verify & launch

    Planned

    Numerical, deterministic, thermal, failure, performance, accessibility, browser, security, and golden-circuit evidence must pass staged release gates before launch.

  6. Handover & iterate

    Planned

    Open-source contribution, hosted collaboration, educational CPU, RTL, architecture, and GPU research expand only after prerequisite gates pass.

System map

How the product boundary fits together.

  1. 01

    Browser laboratory

    Next.js, React, TypeScript, Canvas/WebGL rendering, accessible controls, local project editing, instruments, and explanatory visualization.

  2. 02

    Simulation core

    A Rust/WebAssembly analog core and deterministic digital engine run outside the main UI thread with bounded waveform processing.

  3. 03

    Fidelity scheduler

    Timestamped adapters coordinate circuit, logic, thermal, RTL, architecture, and external engines without silently lowering fidelity.

  4. 04

    Cloud and evidence

    Heavy or untrusted jobs use isolated workers, immutable inputs, streamed progress, reproducible results, and traceable validation evidence.

Claim boundary

Constraints and unresolved risks

  • The repository currently contains documentation only; there is no application code, runtime configuration, migration, deployment, or working simulator to present as delivered.
  • No numerical accuracy, circuit result, solver convergence, performance, accessibility, browser compatibility, or security claim has current runtime evidence.
  • CPU, GPU, full-computer, cloud collaboration, and advanced research capabilities are intentionally gated behind the Realistic Electronics MVP.
  • The 162-family and 502-variant catalog is a versioned family/preset baseline, not every manufacturer SKU or a claim that models are already released.

Public evidence

What supports this case study

Public source repository

The Apache-2.0 repository exposes the product charter, requirements, accepted decisions, architecture, catalog contracts, roadmap, task system, validation strategy, and explicit current-status boundary.

Verified Open evidence ↗

Normative product and architecture baseline

The repository records 38 stable product requirements and 10 accepted architecture decisions covering fidelity, browser and Worker boundaries, storage, co-simulation, rendering, isolation, collaboration, and licensing.

Verified Open evidence ↗

Catalog and delivery traceability

The documented baseline tracks 162 component families, 502 meaningful variants or presets, 38 reusable package templates, 54 golden validation tasks, and 3,090 atomic implementation tasks.

Verified Open evidence ↗

Honest implementation boundary

The repository README states that the documentation foundation is complete while application code, runtime configuration, migrations, and deployment assets are not yet present.

Verified Open evidence ↗

Engineering highlights

  • ✓Hierarchical F0–F5 fidelity model spanning connectivity, equations, digital timing, compact models, electrothermal behavior, and physical research
  • ✓Realistic Electronics MVP gated before educational CPU, RTL, full-computer, cloud, architecture, and GPU expansion
  • ✓Local-first Next.js and TypeScript product with a Rust/WASM core and off-main-thread simulation workers
  • ✓Deterministic timestamped coordination across analog, digital, thermal, RTL, and external simulation engines
  • ✓Versioned .eesim project format, Git-friendly representation, offline persistence, and explicit migration contracts
  • ✓Frozen documentation baseline of 162 component families and 502 meaningful variants or presets
  • ✓Original schematic and physical representation contracts with reusable IC package definitions and pin-map validation
  • ✓Traceable requirements, risks, release gates, golden circuits, validation tasks, and atomic implementation backlog

Technology and domains

Electronics simulationComputer architectureNext.jsTypeScriptRustWebAssemblyLocal-firstOpen source

01 / Feasibility boundary

One project can connect simulation layers without treating every scale as the same physics problem.

The central product decision is to expose the right fidelity for the question and make substitutions, assumptions, provenance, and limits visible.

  1. 01.1F0 through F5 distinguish schematic connectivity, ideal equations, behavioral timing, compact models, electrothermal behavior, and physical-device research.
  2. 01.2Detailed electrical models serve small circuits and selected blocks; event, RTL, architecture, and ISA models serve larger systems.
  3. 01.3A global integer-time scheduler coordinates analog steps, digital events, thermal updates, and external-engine boundaries deterministically.
  4. 01.4The product explicitly rejects full-transistor simulation of modern CPUs, GPUs, or gigabyte-scale memory in a browser.

02 / First production gate

Realistic electronics must work before the roadmap advances to computers.

The first production target connects a visual editor, non-ideal circuit behavior, measurement, waveforms, thermal and failure evidence, logic, and Worker execution.

  1. 02.1Canonical demonstrations cover LED and RC circuits, transistor switching, CMOS, oscillation, logic gates, latches, memory, and adders.
  2. 02.2Models must declare tolerance, leakage, parasitics, ratings, thermal behavior, failures, supported analyses, provenance, and limitations.
  3. 02.3Golden circuits, differential references, deterministic seeds, and explicit error envelopes replace visually plausible but unverified results.
  4. 02.4CPU and GPU features remain gated until this evidence-backed electronics foundation passes.

03 / Product architecture

Local interaction, isolated heavy computation, and immutable evidence have separate responsibilities.

The architecture keeps eligible small simulations responsive in the browser while moving oversized or untrusted work through controlled server boundaries.

  1. 03.1The browser owns interaction and local drafts; numerical solvers and waveform processing run in Workers rather than on the UI thread.
  2. 03.2The engine-neutral project model generates private netlists and execution plans for the selected simulation engines.
  3. 03.3Heavy jobs use validated requests, immutable inputs, bounded workers, checkpoints, cancellation, streamed progress, and checksum-verified results.
  4. 03.4External engines retain license and process-isolation boundaries instead of becoming unsafe linked dependencies of the open core.

04 / Delivery evidence

A large vision is decomposed into reviewable gates and atomic work.

The documentation foundation turns the platform into a staged program with stable identifiers, dependencies, allowed files, tests, and completion evidence.

  1. 04.1Thirty-eight requirements trace into accepted decisions, release gates, epics, atomic tasks, validation work, and acceptance checklists.
  2. 04.2The task index contains 400 platform tasks, 2,636 component/package tasks, and 54 golden validation tasks.
  3. 04.3Only one initial task is Ready: establish repository layout and ownership boundaries before editor or solver implementation.
  4. 04.4A component cannot be called Released until its symbols, connectivity, models, validation, provenance, documentation, and synchronized records pass.

Client relevance

What this evidence can support in a product engagement.

These applications reflect demonstrated product reasoning and the stated maturity boundary—not an unsupported production or client-result claim.

Explore Connected & IoT Product Prototyping ↗
  • Decompose a technically ambitious engineering product into feasible fidelity levels, release gates, and verifiable vertical slices.
  • Design a browser product that combines responsive interaction with Rust/WebAssembly and isolated computational workers.
  • Define simulation, digital-twin, scientific, or hardware-tooling contracts around deterministic data, provenance, limits, and validation evidence.
  • Plan a component or model catalog with stable identifiers, lifecycle states, import boundaries, package mappings, and quality traceability.
  • Turn research requirements into an open-source architecture, dependency-aware backlog, release evidence, and contribution workflow.

Have a related product problem?

Define the smallest useful next step.

Book a free consultation ↗Send a project brief