Control Theory Foundations

Use the primitive table to diagnose delay, noise, saturation, and conflicting actuator commands before choosing gains.

Contents

• Quick Reference
• Formal Supporting Theory
• Anti-Patterns
• Misuse Boundaries
• Expert Judgment
• Decision Checklist
• Composition Recipes
• Workflow
• ASCII Flow
• Navigation

---

Quick Reference

Primitive	Problem It Solves	Key Parameters
PID Control	Drive output to setpoint despite steady-state error and disturbances	Kp, Ki, Kd; tune from plant response and validate margins
Feedback vs. Feedforward	Reactive-only loops ignore predictable disturbances	Plant model accuracy; disturbance measurability
Observability & Controllability	States you cannot see or reach make the loop fail silently	Controllability matrix rank; observability matrix rank
Lyapunov Stability	No proof that a loop converges; may oscillate or diverge	Lyapunov function V(x); dV/dt < 0 condition
MPC	One-step control ignores future constraints and couplings	Horizon N; cost matrices Q, R; constraint bounds
Kalman Filter	Noisy measurements degrade controller and monitoring accuracy	Process noise Q; measurement noise R; model (A, B, C)
Dead-Time Compensation	Transport lag causes oscillation or instability	Dead time L; plant model (delay-free)
Anti-Windup	Integrator saturates during limit-clamping → overshoot on release	Actuator min/max; tracking constant T_t
Gain Scheduling	Single fixed-gain controller fails across operating regimes	Scheduling variable σ; per-regime gain tables
Circuit Breaker & Backpressure	Cascading failure; unbounded queue growth	Failure threshold; timeout; half-open probe logic
Rate Limiting / Token Bucket	Bursts and retry storms overload downstream; 429s cascade	Fill rate r; burst capacity b; per-request cost s
DeePC / Behavioral Systems	MPC without a plant model — unknown dynamics make model-based prediction impossible	Hankel matrix T (data length); regularization λ_g, λ_y; persistency-of-excitation order

---

When to Apply

Apply control-theory when:

• A measurable variable must track a setpoint over time (autoscaler latency target, rate limiter throughput, retry pacing)
• Feedback loop with measurable lag — current state shapes the next action
• Oscillation or overshoot is observed (system swings around target instead of settling)
• Anti-windup needed — integral term must be clamped during saturation
• Plant has dead-time or transport delay; measure startup and propagation time on the target workload

Skip and use simpler alternatives when:

• One-shot decision, no feedback, no setpoint — use foundations-decision-theory
• Static threshold rule that doesn't need to adapt — a constant or hysteresis band is simpler
• Capacity sizing question, not feedback question — use foundations-queueing-theory
• Plant model is unknown and you can't measure error reliably — fix observability first
• Large dead-time relative to the dominant time constant (L/T above ~0.3, a diagnostic heuristic) — assess achievable bandwidth and margins; it is not proof PID is insufficient
• System is unstable open-loop and you don't know why — diagnose root cause before adding feedback

---

Each primitive above is expanded in references/primitives-overview.md and covered by standalone playbooks under assets/templates/control-theory/. Use references/formal-theory-map.md when the task needs stability assumptions, state-space reasoning, or robustness boundaries.

---

Formal Supporting Theory

Theory Area	Use When	Applied Primitives It Grounds
State-space systems	Need A/B/C/D models, poles, modes, controllability, observability	#3, #4, #5, #6
Classical feedback	Need loop shaping, root locus, Bode/Nyquist, margins, PID tuning	#1, #2, #7, #8
Stability theory	Need Lyapunov, input-to-state stability, passivity, bounded-input bounded-output	#4, #10, #11
Optimal control	Need LQR/LQG, dynamic programming, constrained optimization, MPC	#5, #6
Robust control	Need uncertainty margins, H-infinity, mu-synthesis, delay robustness	#4, #7, #9
Adaptive/nonlinear control	Need parameter drift, operating regimes, saturation, nonlinear dynamics	#8, #9
Stochastic estimation	Need Kalman assumptions, noise covariance, filtering vs smoothing	#6
Networked/distributed control	Need queueing, backpressure, admission control, cascading-failure boundaries	#10, #11
Behavioral systems / Willems' Fundamental Lemma	Need MPC without a parametric model; replace explicit prediction with data-driven Hankel matrix; unknown or nonlinear plant	#12 (DeePC)
Advanced regulatory control (ARC)	Need to decompose a multi-loop or multi-agent system into scoped elements with deterministic conflict resolution (selectors, split-range) rather than negotiation	#4, #5, #9

---

Anti-Patterns

Anti-Pattern	Control Theory Diagnosis	Fix
P-only autoscaler oscillates around target	Gain, delay, sampling, or saturation may be producing an underdamped loop	Identify the plant and total delay first; reduce gain or add phase lead/filtered derivative only if the response supports it (#1, #7, #8)
Integrator windup at actuator limit	Integral accumulates during saturation; releases as large overshoot	Anti-windup on every PID with bounded actuator (#8) — this is always required
Reactive controller ignores predictable patterns (load spikes, business hours)	Feedback-only; no model of known disturbances	Add feedforward schedule component (#2)
Observability gap: slow-changing state invisible to aggregate metric	Unobservable state mode in measurement design	Observability rank test (#3); add direct sensor or redesign C matrix
MPC tuned on stale system model	Model–reality mismatch degrades constraint handling and prediction	Retrain model online; add Kalman filter for state estimation (#6)
Dead time treated as additional plant gain	Transport lag misidentified → wrong tuning; oscillation	Smith Predictor (#7); estimate L via step test; never increase Kp to compensate
Retry storm after circuit re-closes	All blocked callers retry simultaneously; re-triggers failure	Token bucket with jitter (#11); stagger retries; half-open probe first (#10)
Agent loop with no convergence proof	No potential function that decreases per step	Define Lyapunov potential (e.g., remaining uncertainty); add hard step limit as fallback (#4)
Run-to-run divergence, a claim of "chaos", or an early-warning alert request	Lyapunov exponent (perturbation growth) is not the Lyapunov function (#4); noise sources and false alarms are unmeasured	Load references/nonlinear-dynamics-checks.md before measuring or alerting
Gain scheduled without bumpless transfer	Abrupt gain switch causes transient at boundary	Interpolate gains smoothly (#9); transfer integral state during switch
Backpressure signal not honored by producer	Queue grows despite signal	Enforce at ingress; drop or block if producer ignores signal (#10)
Multi-agent system resolves constraint conflicts by LLM negotiation	Conflict resolution delegated to a stochastic component; no deterministic priority order	Structural priority: MIN/MAX selectors for competing controlled variables, split-range for competing actuators; orchestrator resolves deterministically regardless of model output (#4, #5)
Retries amplify a partial failure into a full outage	Retry-driven positive feedback pushes loop gain above 1 (metastable failure)	Not owned here — see qa-resilience/references/cascading-failure-prevention.md (metastable failures) for the shedding response; pair with #10/#11 for the admission-side control

---

Misuse Boundaries

Misuse	Why It Is Wrong	Required Correction
Tuning PID by folklore constants	Ziegler-Nichols is an aggressive historical starting point, not a diagnosis or guarantee	Identify response, sample rate, delay, noise, and saturation; test gain/phase margins and re-tune on the actual plant
Ignoring actuator saturation	Integral windup creates overshoot and instability	Add anti-windup to bounded actuators
Treating delay as lower gain	Dead time changes phase and can destabilize loops	Estimate delay and use compensation or lower bandwidth
Claiming Kalman optimality outside assumptions	Kalman is optimal for linear Gaussian systems	Use EKF/UKF/particle filters with caveats
Applying MPC without model validation	Bad model makes constrained optimization confidently wrong	Validate model error and add robust margins. When plant model is unknown: use DeePC (#12) for a model-free alternative, a formulation with verified terminal, feasibility and model-error conditions if a stability certificate is required (Schimperna et al. 2025), or physics-informed sysid if partial domain knowledge exists (Sivaranjani et al. 2025, arXiv:2512.06315).
Using circuit breakers without backpressure	Fail-fast alone can shift overload elsewhere	Pair breakers with queues, rate limits, and admission control
Calling an agent loop stable because it has max steps	Max steps bound cost, not convergence	Define a potential function or monotone progress metric. For self-correction loops, iterate only while the error-correction rate over the error-introduction rate exceeds Acc/(1−Acc) (Liu & Meng 2026, arXiv:2604.22273; single preprint, treat as a heuristic)

---

Expert Judgment

Recognizing an unstable loop before it visibly oscillates

Visible oscillation is the late symptom. By the time replica count or bid multiplier is swinging, margin was gone cycles earlier. Earlier signals, roughly in order of how early they appear:

• Growing control-signal variance at constant error variance. If u (replicas added/removed, bid delta) is getting noisier while the error it's responding to is not, gain margin is shrinking — the loop is amplifying noise it used to damp. This shows up in stddev(Δu) well before it shows up in the tracked metric.
• Settling time creeping up release over release. Each correction takes a bit longer to return to setpoint than the previous one. A single slow cycle is noise; a multi-week upward trend is phase margin eroding, usually from an added dependency, a slower downstream, or a metrics pipeline that got an extra aggregation stage.
• Widening lag between command and effect. Cross-correlate the actuator command timestamp against the measured-effect timestamp on a rolling window. Dead time is supposed to be a constant you compensate for once; if the cross-correlation lag is trending up, something upstream (queueing, batching, an added retry layer) is adding delay the control loop was never tuned against.
• Two independently-stable loops sharing an actuator or measurement surface. An autoscaler and a load balancer's outlier-ejection logic both write to "how many pods serve traffic." Each can pass isolated load-testing and still destabilize the composite system, because neither loop's model includes the other's action. Before declaring a loop stable, ask what else reads or writes the same actuator and measurement.
• The absence of a plant model is itself a signal. If nobody on the team can say "here is the transfer function, or here is the step response we measured," any stability claim is a guess. Silence on this question is the earliest warning of all — it means the loop was tuned by trial and error under one traffic pattern and has no basis for extrapolation to another.

Measurement-delay traps

Dead time is not just physical (network RTT, pod boot, replication lag). The measurement pipeline adds its own, and it is the one teams forget to model:

• A rolling average over a W-second window adds roughly W/2 seconds of effective dead time on top of the true delay — a 60 s Prometheus rate() window plus a 30 s scrape interval can add 45–60 s of lag the PID was never told about.
• Dashboards built for humans (5-minute buckets, smoothed lines) are the wrong signal to feed a controller — they look clean specifically because they've been low-pass filtered, which is delay in another form.
• Symptom of this trap: a loop tuned against historical/backtested data (already aggregated, already lagged) oscillates in production against the live, less-delayed-but-noisier raw signal, or vice versa — tuned against raw data and unstable once someone "cleans it up" with a wider aggregation window.
• Fix: state the total loop dead time as one number — scrape interval + aggregation window + decision latency + actuation latency + propagation time — and compensate (or gain-reduce) against that total, not the physical component alone.

Why most software "controllers" fail

It is rarely bad arithmetic. Nearly every production PID-like autoscaler, pacer, or admission controller that misbehaves is missing one or more of three universal preconditions, and most are missing all three at once:

1. Delay (dead time) is not modeled — see above.
2. Noise is fed to the controller raw — an unfiltered P99 or a jittery per-second rate drives derivative noise amplification and actuator chatter. Derivative kick is a separate defect: a setpoint step makes derivative-on-error spike the output. Apply the derivative term to the measurement, not the error, so a setpoint step does not spike the output (Åström & Murray, https://fbsbook.org).
3. Actuator saturation has no anti-windup — the moment the loop hits a hard limit (max replicas, bid cap, rate-limit ceiling), the integral term keeps accumulating against a wall, then overshoots on release.

The fix for each is well-known (Kalman/low-pass filtering, Smith Predictor, anti-windup) and documented in this skill — the expert judgment is diagnosing which of the three is actually dominant before reaching for a fix, since applying the wrong one (e.g., adding derivative gain to a problem that is really unmodeled dead time) makes the loop worse.

When open-loop beats closed-loop

Closed-loop control is not free — it costs a measurement, a delay, and a risk of instability. Prefer open-loop (feedforward-only, or a scheduled/static policy) when:

• The dominant disturbance is fully predictable (diurnal traffic, a scheduled batch job) and dead time is a large fraction of the desired response time — feedback correction physically cannot arrive before the disturbance has already passed. See the Predictive Autoscaler recipe below; a predictive feedforward autoscaler beat reactive HPA/KEDA on latency in one measured case (Tymoshenko, Maraschi & Collina 2026, arXiv:2604.19705 — Node.js/Kubernetes-specific, not verified to generalize).
• The measurement itself is slow, expensive, or destabilizing — e.g., a business metric only available T+1 day, or a metric whose own collection changes the system being measured. Closed-loop control against a badly-delayed proxy signal can be strictly worse than a static policy tuned offline from historical data.
• The actuator is high-consequence and effectively irreversible on the timescale of one control cycle (a schema migration, a pricing change, a one-way data deletion). "Act, observe, correct" is not a viable strategy when the correction cannot undo the action — get it right open-loop, using simulation and backtesting, not live feedback.
• As a rule of thumb: L/T (dead time over dominant time constant, the same ratio as the 0.3 diagnostic above) above ~0.5 is where dead-time compensation or feedforward-first is worth the cost (template 07); it is an illustrative threshold, not a universal cutoff. If the disturbance is highly predictable and the loop's only job is to react to something already known in advance, feedback control is fighting a battle it starts already behind. Feedforward-first, feedback-as-trim is the correct architecture, not "add more gain."

---

Decision Checklist

• Setpoint tracking: System must reach and hold a target value under disturbances? → PID (#1)
• Predictable disturbances: Known patterns (time of day, schedule, traffic shape) available? → Feedforward (#2)
• State visibility: Can all relevant states be inferred from available sensors? → Observability rank test (#3)
• Actuator reachability: Can all target states be reached by available actuators? → Controllability rank test (#3)
• Convergence proof required: Must prove loop terminates or converges by design? → Lyapunov function (#4)
• Constraints exist: Actuator limits, safety bounds, or resource caps that must never be violated? → MPC (#5) or anti-windup (#8) in PID
• Noisy measurements: Sensor output too noisy for direct use in controller? → Kalman filter (#6)
• Transport lag: Material action-to-effect delay relative to plant dynamics (L/T above ~0.3 is a diagnostic heuristic)? → Dead-time compensation (#7)
• Bounded actuator: Control output has hard min/max? → Anti-windup (#8) — include by default
• Regime variation: System dynamics differ significantly across load or operating conditions? → Gain scheduling (#9)
• External service dependency: Calling a downstream service that can fail? → Circuit breaker (#10)
• Producer-consumer queue: Queue can grow unboundedly under sustained load? → Backpressure (#10)
• Bursty arrivals or retry risk: Traffic or retries can spike beyond downstream capacity? → Token bucket (#11)
• Unknown plant + MPC desired: Need MPC-level constraint handling but have no plant model and system identification is impractical? → DeePC (#12) — collect persistently-exciting offline data first
• Predictable load pattern + dominant startup lag: Load is forecastable and startup delay dominates latency? → Feedforward-dominant (predictive autoscaling) before PID
• Competing objectives across agents or loops: Several controllers contend for one actuator, or one objective is served by several actuators? → ARC decomposition with MIN/MAX selectors and split-range, not negotiation (#4, #5)

---

Composition Recipes

Use these stacks as starting designs. Validate the plant model, sensor quality, actuator bounds, and disturbance profile before production deployment.

Autoscaler That Does Not Oscillate

Failure: HPA oscillates — adds pods, overshoots, removes pods, undershoots.

The Kubernetes HPA itself is not a PID controller: it applies a ratio rule, desiredReplicas = ceil(currentReplicas × currentMetricValue / desiredMetricValue), skips scaling when the ratio is within a tolerance of 1.0, and damps scale-down with a stabilization window that selects the highest recent desired-replica recommendation. It has no integral term, so there is no HPA windup to fix. Tune an HPA through its tolerance, stabilization windows, and scaling policies; check the kubernetes.io HPA page for current defaults. The PID stack below is for a custom controller that replaces or drives the HPA.

• PID (#1): CPU utilization error → replica delta
• Anti-windup (#8): block integral accumulation only when it drives further into saturation; permit unwinding
• Dead-time compensation (#7): Smith Predictor for pod startup lag
• Gain scheduling (#9): separate gains for low/mid/high load regimes

Data-driven variant (no plant model): DeePC (#12) or Koopman-MPC (kEDMD) can replace model-based MPC (#5) when system dynamics are unknown but input-output data is available. The exact DeePC LTI theorem requires input excitation of order T_ini+N+n and T_ini at least system lag; Koopman learning has its own representation/data/error assumptions. Compare tracking and smoothness locally; a stability certificate requires verified terminal/robustness conditions, not a method preference (see 12-deepc-behavioral.md).

For discrete units, output mapping, an illustrative latency example, and the replay helper, load references/discrete-controller-contract.md.

Stable Agent Loop with Budget Control

Failure: Agentic loop runs tool calls without bounded cost or convergence guarantee.

• Token bucket (#11): admission control on tool calls per step
• Circuit breaker (#10): isolate failing tools; fail fast instead of waiting
• Lyapunov analysis (#4): define a positive potential and verify decrease conditions for the actual dynamics; a budget countdown alone does not prove task convergence
• MPC planning (#5): plan token allocation across remaining steps before executing the current one

Finite action catalogs alone do not prove stability. Prinos et al. (arXiv:2605.03034) certify ISS for a specific cyber-defense architecture using its dynamics, observer, tools, and Lyapunov assumptions; verify analogous conditions for another loop.

LLM Inference Autoscaler Without Oscillation

Failure: Kubernetes HPA oscillates or lags — scales on CPU/memory while the actual bottleneck is KV-cache saturation and queue depth.

• Backpressure (#10): use KV-cache utilization as the backpressure signal (not CPU); scale when cache approaches saturation threshold
• Token bucket (#11): admission control at ingress; shed load before queue depth triggers failure cascade
• MPC (#5): receding-horizon planning across replica variants (prefill vs. decode disaggregated scaling) — preferentially add cheap variants, remove expensive ones
• Dead-time compensation (#7): account for measured model-loading and pod startup latency when projecting replica count forward

Reference implementation: WVA (Malvankar et al. 2026, arXiv:2603.09730). The paper reports gains over HPA; figures are in data/sources.json (single preprint, direction only). Choose metrics that observe the identified bottleneck. KV-cache and queue depth can reveal inference saturation that CPU utilization misses; verify their relationship to the workload SLO.

Predictive (Feedforward-Dominant) Autoscaler

Failure: Reactive HPA/KEDA lags behind demand — startup latency means pods arrive after the load spike, causing transient latency degradation.

When to prefer over PID-dominant autoscaling: Load pattern is predictable (periodic, trending) AND startup lag is the dominant latency contributor. If the load is unpredictable or bursty, fall back to the PID-dominant recipe above.

• Kalman filter (#6): smooth noisy request-rate time series; produce a filtered load estimate
• Feedforward (#2): forecast load trajectory; scale proactively before demand arrives; evaluate forecast error and remaining startup lag
• Dead-time compensation (#7): encode pod startup time L in the forecast horizon (scale N steps ahead where N ≥ L / sample_period)
• Anti-windup (#8): block integral accumulation only toward deeper saturation; permit unwinding

Contrast with PID-dominant recipe: PID-dominant is feedback-corrective (best for unpredictable disturbances); feedforward-dominant is anticipatory (best when load pattern is predictable and startup lag dominates the error budget).

Empirical reference: Tymoshenko, Maraschi & Collina (2026, arXiv:2604.19705) report lower median latency than KEDA and HPA under a steady ramp load on Node.js/Kubernetes (figures in data/sources.json). Rule: with predictable load and startup lag as the main error, feed forward. Caveat: Node.js-specific; generalizability to other runtimes unverified.

Multi-Agent System with Deterministic Constraint Arbitration

Failure: Several agents each defend a different objective (cost, latency, safety, quota) and conflicts are resolved by letting the models negotiate — so the resolution is nondeterministic, unauditable, and changes with prompt or temperature.

The advanced-regulatory-control (ARC) decomposition replaces negotiation with structure. Each feedback loop becomes one scoped agent carrying its own control-theoretic context (controlled variable, setpoint, chain priority, selector kind); an orchestrator encodes the priority order and resolves every conflict deterministically, outside the model.

• Scoped loops (#4): one agent per controlled variable; no agent may write another's actuator
• MIN/MAX selectors: arbitrate when several controlled variables compete for one actuator — select the limiting command in the safe direction for that plant; justify priorities and selector signs
• Split-range logic: arbitrate when one controlled variable is served by several actuators of differing cost, engaging them in a fixed order
• Circuit breaker (#10) and token bucket (#11): unchanged, still applied per tool

Key insight: the safety property comes from the arbitration topology, not from the model. Constraint conflicts resolve identically regardless of what any agent outputs, which is what makes the trajectory auditable.

Reference: Nogueira & Skogestad (2026, arXiv:2606.30877). Evaluated on a dairy-barn ventilation loop with a small open-weight LLM; contribution is the architecture and auditable trajectories, not a benchmark win.

Budget Pacing Without Windup or Oscillation

Failure: Ad spend oscillates — underspends overnight, overspends at peak, jams at bid cap.

• PID (#1): spend rate error → bid multiplier
• Anti-windup (#8): bid multiplier clamped at platform min/max; block integration toward deeper saturation while permitting unwinding
• Feedforward (#2): time-of-day schedule pre-adjusts bid before measurement confirms error
• Kalman filter (#6): smooth noisy CPM/spend signals before feeding to PID

---

Workflow

1. Identify the feedback failure mode in your system (oscillation, windup, dead time, unobservable state, no convergence proof, cascading failure, overload).
2. Use the Decision Checklist to map failure mode → primitive.
3. Open references/primitives-overview.md for definitions, failure modes, and source anchors.
4. For multi-failure scenarios, use the Composition Recipes and references/patterns-scenarios-traps.md to stack primitives.
5. Check the Anti-Patterns table before finalizing the design — most common mistakes are listed there.
6. Verify numeric thresholds (gains, dead-time estimates, bucket sizes) against the primary sources in data/sources.json and the reference files before deploying at scale. Stability-margin targets, sampling-rate rules and Smith-predictor limits are not stated here; take them from Åström & Murray (https://fbsbook.org), not from memory.

---

ASCII Flow

Feedback system failure
  -> Classify symptom: oscillation, windup, delay, overload, cascade, unobserved state
  -> Map symptom to control primitive
  -> Model loop, signal, actuator, delay, and constraint
  -> Choose controller or protection pattern
     +-- unstable or unobservable -> add measurement or redesign loop
     +-- stable enough -> tune and simulate
  -> Deploy with monitored thresholds and rollback criteria

---

Navigation

• Discrete implementation contract and reproducible simulation
• Formal theory map: references/formal-theory-map.md
• Patterns, scenarios, and traps: references/patterns-scenarios-traps.md
• Primitives overview and domain anti-patterns: references/primitives-overview.md
• Run-to-run divergence, early-warning signals, heavy-tail claims: references/nonlinear-dynamics-checks.md
• Per-primitive playbooks: assets/templates/control-theory/README.md
• Sources: data/sources.json

Learnings Loop

When prior decisions or pitfalls are relevant, consult learnings.consolidated.md if present; use learnings.md only for needed history or as the available fallback. Otherwise skip both.

After applying it, if you encountered a pattern worth remembering, a mistake worth preventing, or a domain fact that surprised you, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.