Decompose and study any physical/engineering system (SMPS, turbofan engine, ABS braking, PID controller, hydraulic press, PCB layout, etc.) from a design-thinking perspective — understanding architecture, core subsystems, design decisions, and the principles behind them. Works for electronics, mechanical, aerospace, automotive, control systems, power systems, thermal systems, and any other engineering domain. Use when the user wants to study, learn, analyze, or understand a physical system's design philosophy, or wants to know why an engineering system was designed the way it was.
Structured methodology to understand any physical/engineering system at the design level — its subsystems, why they exist in that form, the decisions behind them, and the reusable principles they embody.
Goal: Build a transferable mental model of the system's design logic, not memorization of specifications.
Applies to: Electronics, mechanical, aerospace, automotive, power systems, thermal systems, control systems, chemical processes, civil structures — any engineered physical system.
Phase 1: Problem Space → What physical problem demanded this system?
Phase 2: Architecture Map → What are the subsystems, energy/signal flows, and critical paths?
Phase 3: Design Decisions → What did they choose X over Y, and why?
Phase 4: Principle Extraction → What reusable engineering principle does this teach?
Phase 5: Validation → Can I redesign it under different constraints?
Before studying the system, understand the physical reality it was designed to conquer.
Write one sentence: what physical limitation or need triggered this system's creation?
| System | Problem Statement |
|---|---|
| SMPS (Switch-Mode Power Supply) | Linear regulators waste energy as heat proportional to voltage drop, making them impractical for large step-down ratios or battery-powered devices |
| ABS (Anti-lock Braking) | Locked wheels lose static friction and directional control — the driver cannot steer during emergency braking |
| Turbofan engine | Pure turbojets are fuel-inefficient at subsonic speeds because all thrust comes from high-velocity exhaust |
| PID controller | On-off control causes oscillation; open-loop control can't handle disturbances or plant variations |
Build a table of what came before:
| Predecessor | Strength | Where It Broke Down |
|----------------------|-----------------------------|------------------------------------------|
| [Prior system A] | [What it did well] | [Physical limit it hit] |
| [Prior system B] | [What it did well] | [Physical limit it hit] |
| [Prior system C] | [What it did well] | [Physical limit it hit] |
Example for SMPS:
| Predecessor | Strength | Where It Broke Down |
|---|---|---|
| Linear regulator (LM7805) | Simple, low noise, no switching transients | Efficiency = Vout/Vin, wastes (Vin-Vout)×I as heat; can't step up |
| Transformer + rectifier | Can step up/down, galvanic isolation | Large, heavy, only works with AC input, fixed ratio |
| Switched capacitor | No inductor needed, compact | Limited power, fixed integer ratios, poor regulation under load |
Find the specification envelope the system was designed to meet:
Map the system's architecture by identifying subsystems and tracing flows of energy, material, signal, and force — not code.
Every well-designed engineering system decomposes into a small set of functional blocks. Identify them.
For each subsystem, answer:
| Question | Purpose |
|---|---|
| What does it do? (one sentence — in terms of energy/signal/material transformation) | Understand physical function |
| Why does it exist as a separate subsystem? | Understand separation of physical concerns |
| What would break if you removed or merged it with another? | Understand physical necessity |
Example — SMPS (Buck Converter):
┌─────────┐ ┌───────────┐ ┌─────────┐ ┌──────────┐
│ Input │───▶│ Switching │───▶│ Energy │───▶│ Output │
│ Filter │ │ Stage │ │ Storage │ │ Filter │
│ (EMI) │ │ (MOSFET) │ │ (L + C) │ │ & Load │
└─────────┘ └─────┬─────┘ └─────────┘ └──────────┘
│
┌─────▼─────┐
│ Feedback │
│ & Control │
│ (PWM loop) │
└───────────┘
Map the primary flow through the system:
[Input] → [Stage 1] → [Stage 2] → [Stage 3] → [Output]
what transforms? what stores? what filters?
what is the energy form at each stage?
At each boundary, mark:
| Path Type | Definition | Design Priority |
|---|---|---|
| Critical path | The main energy/signal/material flow (power stage, load-bearing structure, signal chain) | Optimized for efficiency, speed, or strength |
| Control path | Feedback and regulation loops | Optimized for stability, accuracy, response time |
| Support path | Protection, cooling, lubrication, filtering, housekeeping | Optimized for reliability, must not interfere with critical path |
Every engineering system makes design choices across ten fundamental dimensions. For each, the goal is not to list specifications — it's to understand why the system handles this dimension the way it does, what alternatives existed, and what physics/economics forced the choice.
Design thinking anchor for all dimensions: For each, ask — "What would the simplest/cheapest/textbook approach look like, why does it fail for this application's physics or operating conditions, and what specific constraint forced a different design?"
The core of design understanding. Every well-engineered system makes 3-7 bold, non-obvious choices that define its character.
Format as "They chose X over Y". Scan all system dimensions:
| Decision Area | They Chose... | Over... | Why (physics/economics) |
|-----------------------------|-------------------------|---------------------------|-------------------------------|
| Signal representation | [chosen approach] | [rejected alternative] | [reasoning] |
| Energy conversion topology | [chosen approach] | [rejected alternative] | [reasoning] |
| Control architecture | [chosen approach] | [rejected alternative] | [reasoning] |
| Energy storage | [chosen approach] | [rejected alternative] | [reasoning] |
| Material selection | [chosen approach] | [rejected alternative] | [reasoning] |
| Communication / routing | [chosen approach] | [rejected alternative] | [reasoning] |
| Safety strategy | [chosen approach] | [rejected alternative] | [reasoning] |
| Redundancy / fault tolerance| [chosen approach] | [rejected alternative] | [reasoning] |
| Deployment / packaging | [chosen approach] | [rejected alternative] | [reasoning] |
| Recovery / maintainability | [chosen approach] | [rejected alternative] | [reasoning] |
| Monitoring / diagnostics | [chosen approach] | [rejected alternative] | [reasoning] |
Not every system has bold decisions in all areas. Focus on the 3-7 where the system made non-obvious choices. But scan all — sometimes the most interesting insight hides where you don't expect it.
For every decision:
Ask: "What if they had chosen the other option?"
"If an SMPS used a linear regulator instead of switching topology: Simpler, no EMI, no inductor needed, but at 12V→3.3V conversion the regulator dissipates 8.7V × I as heat. At 2A that's 17.4W of waste heat requiring a large heatsink, making it impractical for portable devices."
"If ABS used open-loop braking instead of wheel-speed feedback: Simpler, cheaper, fewer sensors, but cannot adapt to varying road surfaces. On ice, wheels lock instantly; on dry pavement, braking force is suboptimal. The fundamental issue is that optimal slip ratio varies with surface — you must measure to control."
Every engineering design decision ultimately traces back to a physical law or constraint that makes one option better than another:
| Decision | Governing Physics |
|---|---|
| SMPS uses switching vs linear | P_loss = (Vin-Vout) × I — thermodynamics makes linear waste inescapable |
| Turbofan has bypass ratio | Propulsive efficiency ∝ (mass flow × low velocity) vs (low mass × high velocity) — momentum equation |
| ABS modulates brake pressure | Static friction coefficient > kinetic — once the wheel locks, you lose both grip and steering |
| Heat exchanger uses counterflow | ΔT_log is higher in counterflow than parallel flow — second law of thermodynamics |
This is the deepest level of understanding: which equation made this choice inevitable?
Generalize from specific decisions to reusable engineering design principles.
| System-Specific Decision | General Engineering Principle |
|---|---|
| SMPS uses switching + inductor | Store-and-transfer beats dissipation — use energy storage elements to move energy efficiently instead of burning excess as heat |
| ABS uses wheel-speed sensors | Measure the variable you're controlling — open-loop fails when the plant varies; close the loop around the quantity that matters |
| Turbofan has high bypass ratio | Move more mass at lower velocity — for the same thrust, slower exhaust is more fuel-efficient (momentum vs kinetic energy) |
| Bridge uses arch geometry | Let geometry carry the load — shape the structure so forces flow as compression, not bending (compression is cheaper per unit strength) |
| Gear reducer trades speed for torque | Impedance matching — transform the source characteristics to match the load's needs |
Build a principle × system matrix. This is the most valuable artifact.
| Principle | System A | System B | System C |
|----------------------------------|------------|------------|------------|
| Feedback beats open-loop | How? | How? | How? |
| Impedance matching | How? | How? | How? |
| Store-and-transfer > dissipation | How? | How? | How? |
| Separate critical from support | How? | How? | How? |
| Fail to known-safe state | How? | How? | How? |
For each new principle:
**Principle:** [Name]
**Definition:** [One sentence — in terms of physics/engineering]
**Governing law:** [The equation or physical law that makes this true]
**Systems that use it:** [2-3 examples across different domains]
**When to apply:** [Conditions / problem characteristics]
**When it backfires:** [Conditions where this principle hurts]
Many engineering principles have direct analogs in software:
| Engineering Principle | Software Analog |
|---|---|
| Feedback control (PID) | Auto-scaling, adaptive rate limiting |
| Impedance matching | API design, protocol bridging, buffer sizing |
| Fail-safe state | Circuit breaker pattern, graceful degradation |
| Redundancy (N+1) | Replica sets, leader election |
| Filtering (EMI, noise) | Input validation, rate limiting, debouncing |
| Thermal management | Back-pressure, load shedding |
| Modular replacement | Microservices, plug-in architecture |
| Predictive maintenance | Health checks, anomaly detection |
If the user studies both software and physical systems, this cross-domain mapping builds the deepest design intuition.
Change one constraint and redesign:
Which subsystems change? Which stay? What new tradeoffs appear?
Write a one-page document as if you were the original designer proposing this system:
## Context
[What physical problem we face and operating constraints]
## Decision
[What architecture we chose and the key subsystem choices]
## Governing Physics
[The 2-3 physical laws/equations that make this architecture the right one]
## Consequences
### Positive
- [What we gain in performance, efficiency, reliability, cost]
### Negative
- [What we give up or make harder]
### Risks
- [What operating assumptions must hold]
If you can write a convincing EDR, you understand the system.
Produce a 5-minute explanation:
Use the template in study-template.md to produce structured study notes.
For curated starting resources organized by engineering domain, see resource-guide.md.
Week 1: Problem Space (Phase 1)
├── Day 1-2: Origin story — why was this invented, what came before
├── Day 3-4: Study 2-3 predecessor systems and their physical limitations
└── Day 5: Write problem statement + design targets + governing equations
Week 2: Architecture (Phase 2)
├── Day 1-2: Study block diagrams from textbooks, app notes, patents
├── Day 3-4: Draw subsystem diagram from memory, verify against sources
└── Day 5: Trace energy/signal flow end-to-end, mark every domain crossing
Week 3: Design Decisions (Phase 3)
├── Day 1-2: List all major "chose X over Y" decisions
├── Day 3: Tradeoff analysis — identify governing physics for each
└── Day 4-5: Extract principles, update cross-system table
Week 4: Validate (Phases 4-5)
├── Day 1-2: Redesign under altered physical constraints
├── Day 3: Write the EDR
└── Day 4-5: Explain it to someone or write a blog post
Stop asking: "What are the specifications of this system?"
Ask instead:
Explain the physics and reasoning in depth before listing specifications. Help build understanding, intuition, and cross-domain design thinking — not memorization of part numbers and datasheets.