Circuit Analysis and Design

Proof required

Submit your analysis showing: (1) the circuit schematic (hand-drawn or drawn in KiCad Schematic Editor free, or Falstad export) with all component values labelled; (2) the full analysis calculation set — clearly stating the method used, every equation written out, and all intermediate values with units; (3) a KVL and KCL verification table confirming closure; (4) a simulation screenshot (LTspice or Falstad) showing voltages and/or currents as a numerical check.

What gets checked

• Analysis method is explicitly stated before any equations are written — node voltage method, mesh current method, or phasor analysis — and applied consistently; switching method mid-calculation without explanation is an error
• KVL and KCL closure check is presented as a numerical table, not a verbal statement — e.g. 'Sum of voltages around loop 1: 12V − 3.2V − 4.8V − 4.0V = 0V ✓'
• Units are carried through every intermediate step — a current calculated in mA that is later used in a power calculation must remain in mA (or be explicitly converted) — unitless intermediate values fail the engineering standard

Common mistakes

• Using simulation output as the primary analysis rather than as a verification check — submitting an LTspice screenshot with no hand calculation is an AI-fakeable proof that demonstrates no circuit analysis skill
• Applying superposition or Thevenin/Norton reduction without showing that the prerequisite conditions are met (linearity, bilateral sources) — method selection must be justified

Resources

What a verifier looks for

• Engineering Design Triad: M1 produces an analysis artifact (calculation set + KVL/KCL verification table) and a design artifact (labelled schematic). Both must be present.
• Hand calculation must be present and complete — a simulation screenshot alone does not meet the analysis artifact requirement.
• KVL and KCL closure must be demonstrated numerically — a verbal claim that 'the analysis is correct' without the closure check is insufficient.
• Reviewer must be an electrical or electronics engineer with circuit analysis experience — general engineering knowledge cannot verify the correctness of node voltage or phasor analysis methods.
• The Proof Accessibility Rule applies — Falstad, LTspice, and KiCad are all free; no proprietary EDA software is required.

Proof required

Submit: (1) the performance specification (given or self-defined — must be quantitative: a target voltage, frequency, gain, or current figure with tolerance); (2) your design derivation — the equations and component value selection with E-series rounding justified; (3) the circuit schematic with all component values annotated; (4) simulation results showing the measured performance parameter vs. the specification (screenshot or exported data table).

What gets checked

• Component values use standard E-series values — a design that specifies 1.73 kΩ without selecting the nearest E12 value (1.8 kΩ) and rechecking the performance has not completed the design step
• Simulation result is compared to the specification with a margin statement — 'measured −3 dB at 1.08 kHz vs. specification of 1 kHz, within 10% tolerance' not just a screenshot
• Design derivation shows the tradeoff between the standard component value and the ideal value — if E-series rounding changes the performance by more than the tolerance, the design must address this

Common mistakes

• Using ideal component values throughout and never selecting E-series values — real circuit design always uses standard values; a design that ignores this is an incomplete engineering exercise
• Simulating without first completing the analytical design — simulation-first design (tune until it works) produces no transferable design skill and is AI-fakeable; the analytical design must precede simulation

Resources

What a verifier looks for

• Design derivation must show analytical equations before simulation — check that component values are derived from equations, not tuned in simulation.
• E-series component values must be used and the performance recheck must appear — check that the submission addresses the rounding from ideal to standard values.
• Simulation result must be compared to the specification numerically — a passing screenshot without a margin statement is insufficient.
• Reviewer must be an electrical or electronics engineer with circuit design experience — the reviewer needs to evaluate whether the design derivation method is correct for the circuit type.

Proof required

Submit: (1) your circuit design specification document (all sections above, 600–900 words total); (2) a written record of the reviewer's technical challenge and your response (150 words minimum, attributing reviewer by role and domain experience).

What gets checked

• Failure mode or operating limit is specific and quantified — 'supply voltage must not exceed 15V or the transistor's V_CE(max) of 40V is approached under load' not 'don't exceed the voltage rating'
• Proposed improvement is technically specific — 'adding a bypass capacitor across the emitter resistor would extend the −3 dB bandwidth from the current 1 kHz to approximately 10 kHz' not 'the design could be improved'
• Reviewer challenge record shows a substantive technical exchange — the reviewer questioned a specific design decision (e.g. biasing point choice, component tolerance effect) and the student's response addressed the engineering rationale

Common mistakes

• Writing a design specification that describes the circuit rather than specifying it — a specification states what the circuit must do and what the performance limits are; a description says what it does
• Presenting to a reviewer who is not an electrical engineer — a general engineer or computer scientist without circuit design experience cannot meaningfully evaluate the design decisions

Resources

What a verifier looks for

• Engineering Design Triad check: M1–M3 together produce a design artifact (schematic + component list), an analysis artifact (calculation set + simulation results), and a documentation artifact (design specification document) — confirm all three are present.
• Failure mode must be specific and quantified — a generic safety warning is not an engineering failure mode analysis.
• Reviewer challenge record must show a genuine technical exchange — not just the reviewer's overall assessment.
• Reviewer must be an electrical or electronics engineer with circuit design experience — the domain expertise check is mandatory; a general science background is insufficient.
• The Proof Accessibility Rule applies — Falstad, LTspice, and KiCad are all free.