Open loop, and when it is the right answer
Where feedback is not worth its cost or its complexity.
Open loop control, applying a fixed, pre-decided action without ever checking what actually happened as a result, is the right answer whenever a system's behaviour is already predictable enough that measuring it adds cost and complexity without buying any real improvement in the outcome, which is a genuinely common situation despite how much of the attention in this set has gone to closed-loop feedback control instead.
Introduction and overview
Every control loop covered so far in this collection, from the shower tap through the thermostat to the slow sensor examined earlier in this very set, has depended on the same three-step pattern, measuring, comparing and correcting, and that pattern buys real value precisely because it lets a system react to whatever is actually happening rather than to what was merely predicted in advance. That value is not free, however, since a sensor has to be bought, wired, and kept working, a measurement has to be interpreted correctly, and a whole extra category of failure, a broken or slowly drifting sensor quietly feeding the controller bad information, becomes possible the moment feedback enters the picture at all. Open loop control skips all of that, simply applying a predetermined action and trusting that the relationship between the action and its outcome is well enough understood, and consistent enough in ordinary practice, that checking the actual result afterward would not meaningfully change what gets done next anyway.
The boiled-egg comparison
Boiling an egg for exactly six minutes using a kitchen timer, rather than continuously checking the egg's actual internal temperature or texture throughout, is open loop control performed at the breakfast table. Nobody opens the pot every thirty seconds to measure doneness and adjust the boiling time accordingly, because the relationship between boiling time and how done an egg of a given size turns out is well understood and consistent enough that a fixed six minutes reliably produces the intended result without any checking at all. Building genuine feedback into the process, a sensor probing the yolk's actual internal temperature and adjusting the boiling time in real time, would technically produce a more precisely controlled result on a difficult or unusual egg, but it would add real cost and real complexity to solve a problem the simple timer was already solving perfectly well, which is exactly the trade-off open loop control asks anyone using it to weigh honestly.
Where a stepper motor makes the same trade-off
A stepper motor is a common engineering example of exactly this same choice. Told to advance a fixed number of steps, it does so by simply energising its coils in the correct sequence, with no sensor confirming that each individual step actually landed where it was commanded, trusting that the motor's own design reliably delivers each step correctly as long as it is not asked to move faster or against more resistance than it can actually handle. This works remarkably well in practice specifically because a stepper motor's step-by-step behaviour is unusually predictable and repeatable by design, and adding a position sensor and a full feedback loop on top of that would mostly be paying for insurance against a failure mode, a missed step, that a properly specified stepper motor rarely experiences under its intended working conditions in the first place.
One figure worth keeping in mind
Adding a sensor, the wiring and interpretation it needs, and the extra logic a feedback loop requires can meaningfully increase both the manufacturing cost and the number of things that can fail in an otherwise simple mechanism, sometimes by a proportion far larger than the improvement in accuracy or reliability that feedback actually buys for a task whose open-loop behaviour was already trustworthy, a trade that only makes sense once the specific benefit feedback would add has been weighed honestly against everything it costs to obtain.
Where open loop stops being the right answer
Open loop control's whole justification rests on the relationship between action and outcome staying predictable, and the moment that predictability breaks down, the case for open loop breaks down with it. A stepper motor pushed harder than its rated torque can genuinely miss a step without any way of knowing it happened, silently drifting out of position while continuing to report, in effect, that everything is fine, since nothing in an open loop system is actually checking. An egg boiled at high altitude, where water boils at a lower temperature, needs longer than six minutes to reach the same doneness a sea-level timer assumes, and the fixed timer, blind to that change, simply gets the wrong answer with complete confidence. Both failures point at the same underlying weakness, an open loop system has no way of noticing when its own quiet assumption about the relationship between action and outcome has stopped holding true, which is precisely the weakness a closed loop, at real and sometimes considerable cost, exists specifically to cover.
Why this matters in practice
Choosing between open loop and closed loop control is not a question of which one is technically more sophisticated, since open loop control is not a lesser, incomplete version of feedback control, it is the correct choice whenever a system's behaviour is already predictable enough that the extra measurement, cost and failure modes feedback introduces are not worth what they buy. Recognising this turns tuning, and control system design more broadly, into an honest cost-benefit judgement rather than a reflex to add feedback everywhere simply because feedback is the more celebrated half of the subject, closing out this set on the same practical note nearly every article in it has returned to, that a control system is only as good as it needs to be for the job actually in front of it, and no better, once every extra measurement has been paid for in cost and complexity rather than simply assumed to be free.