Engineering and Design Thinking: Evaluating a Prototype (EMI.ED)

Every prototype passage gives you three things: a goal, a measured result, and sometimes a cost or size limit called a constraint. Judging success means lining the result up against the goal stated at the start, not against some vague sense of quality. If the goal was removing at least 95 percent of particles and the prototype hits 88 percent, it fell short by 7 percentage points. That is a fact about the gap, not a verdict on the whole project.

Here is the twist the ladder keeps testing: missing the goal does not mean the engineering failed. A test log that shows exactly which layer a particle slipped through is gold, because it tells the next designer precisely what to change. Engineering moves in iterations, and a prototype's job is often to locate the problem, not solve it outright. So a passage can call a prototype a success even while admitting it missed its target number, as long as it generated usable information for the next round.

This connects to the rest of the unit because evaluating a model works the same way: check claims against the evidence actually collected, not against outside expectations. One trap is comparing a new prototype only to an older, worse one. Beating Prototype 1 does not mean Prototype 2 solves the stated problem if it still misses the brief's actual numbers. Another wrinkle: constraints that appear after testing is finished never change what already happened. A unit tested and approved under an old size limit still counts as a pass for that round; a new housing requirement just becomes the target for the next prototype.