Open-Loop vs Closed-Loop Systems
A closed-loop system continuously observes actual state and feeds the error back into the controller (xettel). An open-loop system acts without re-checking — it assumes its action was sufficient or that no external actor will change the state.
Key trade-off
Closed-loop systems are robust to drift and external disturbance but add complexity: the system must observe, compare, and handle instabilities like oscillation (see hysteresis). Open-loop systems are simpler but break when assumptions are violated.
In desired state systems
Desired state systems can be either (Jenco):
- Open-loop — React assumes sole ownership of the DOM. It does not re-read actual DOM state; if another script mutates the DOM, React will not detect or fix it.
- Closed-loop — Terraform checks actual infrastructure against the saved plan, detecting drift caused by manual changes or other tools.
- Closed-loop, continuous — Kubernetes runs reconciliation controllers in a permanent loop. Delete a pod and the controller immediately recreates it (xettel, K8s docs).
In management
Goal-setting frameworks vary in loop frequency: OKR checks quarterly (xettel), Scrum inspects every sprint (xettel), Kanban operates as continuous flow (xettel). A quarterly OKR is effectively a thermostat that reads the thermometer once a season.
Closed-loop systems must also address stability: overshoot, oscillation, and settling time. The standard solution is PID control, which balances responsiveness against these risks.