Foundations Control Theory

---
name: foundations-control-theory
description: PID/MPC/Kalman/anti-windup control primitives for feedback loops. Use when an autoscaler flaps, a controller overshoots after saturation, or budget pacing overspends at peak.
compatibility: Portable core only.
version: "1.4"
last_validated: 2026-09-17
---

# Control Theory Foundations

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

## Contents

- [Quick Reference](#quick-reference)
- [Formal Supporting Theory](#formal-supporting-theory)
- [Anti-Patterns](#anti-patterns)
- [Misuse Boundaries](#misuse-boundaries)
- [Expert Judgment](#expert-judgment)
- [Decision Checklist](#decision-checklist)
- [Composition Recipes](#composition-recipes)
- [Workflow](#workflow)
- [ASCII Flow](#ascii-flow)
- [Navigation](#navigation)

---

## Quick Reference

| Primitive | Problem It Solves | Key Parameters |
|-----------|------------------|----------------|
| [PID Control](assets/templates/control-theory/01-pid-control.md) | Drive output to setpoint despite steady-state error and disturbances | Kp, Ki, Kd; tune from plant response and validate margins |
| [Feedback vs. Feedforward](assets/templates/control-theory/02-feedback-vs-feedforward.md) | Reactive-only loops ignore predictable disturbances | Plant model accuracy; disturbance measurability |
| [Observability & Controllability](assets/templates/control-theory/03-observability-controllability.md) | States you cannot see or reach make the loop fail silently | Controllability matrix rank; observability matrix rank |
| [Lyapunov Stability](assets/templates/control-theory/04-lyapunov-stability.md) | No proof that a loop converges; may oscillate or diverge | Lyapunov function V(x); dV/dt < 0 condition |
| [MPC](assets/templates/control-theory/05-mpc.md) | One-step control ignores future constraints and couplings | Horizon N; cost matrices Q, R; constraint bounds |
| [Kalman Filter](assets/templates/control-theory/06-kalman-filter.md) | Noisy measurements degrade controller and monitoring accuracy | Process noise Q; measurement noise R; model (A, B, C) |
| [Dead-Time Compensation](assets/templates/control-theory/07-dead-time-compensation.md) | Transport lag causes oscillation or instability | Dead time L; plant model (delay-free) |
| [Anti-Windup](assets/templates/control-theory/08-anti-windup.md) | Integrator saturates during limit-clamping → overshoot on release | Actuator min/max; tracking constant T_t |
| [Gain Scheduling](assets/templates/control-theory/09-gain-scheduling.md) | Single fixed-gain controller fails across operating regimes | Scheduling variable σ; per-regime gain tables |
| [Circuit Breaker & Backpressure](assets/templates/control-theory/10-circuit-breaker-backpressure.md) | Cascading failure; unbounded queue growth | Failure threshold; timeout; half-open probe logic |
| [Rate Limiting / Token Bucket](assets/templates/control-theory/11-rate-limiting-token-bucket.md) | Bursts and retry storms overload downstream; 429s cascade | Fill rate r; burst capacity b; per-request cost s |
| [DeePC / Behavioral Systems](assets/templates/control-theory/12-deepc-behavioral.md) | 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 desired settling time — assess achievable bandwidth and margins; 30% is a diagnostic heuristic, 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](references/primitives-overview.md) and covered by standalone playbooks under [assets/templates/control-theory/](assets/templates/control-theory/). Use [references/formal-theory-map.md](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) |
| 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 |

---

## 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 instead refers to a setpoint step differentiated through derivative-on-error.
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; empirically this beat reactive HPA/KEDA by roughly 6–20x median 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: a ratio `dead_time / desired_settling_time > ~0.5` is an illustrative warning to investigate achievable bandwidth, not a universal cutoff; or 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 (30% 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](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) 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](assets/templates/control-theory/12-deepc-behavioral.md)).

For discrete units, output mapping, an illustrative latency example, and the replay helper, load [references/discrete-controller-contract.md](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](https://arxiv.org/abs/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). Empirical: 37% throughput gain, 10× failure reduction vs. HPA.
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) achieve 26 ms median latency vs. 154 ms for KEDA and 522 ms for HPA under a steady ramp load on Node.js/Kubernetes. 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 over 4 days with Qwen 2.5 7B Instruct; 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](#decision-checklist) to map failure mode → primitive.
3. Open [references/primitives-overview.md](references/primitives-overview.md) for definitions, failure modes, and source anchors.
4. For multi-failure scenarios, use the [Composition Recipes](#composition-recipes) and [references/patterns-scenarios-traps.md](references/patterns-scenarios-traps.md) to stack primitives.
5. Check the [Anti-Patterns](#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`](data/sources.json) and the reference files before deploying at scale.

---

## ASCII Flow

```text
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](references/discrete-controller-contract.md)
- Formal theory map: [references/formal-theory-map.md](references/formal-theory-map.md)
- Patterns, scenarios, and traps: [references/patterns-scenarios-traps.md](references/patterns-scenarios-traps.md)
- Primitives overview and domain anti-patterns: [references/primitives-overview.md](references/primitives-overview.md)
- Per-primitive playbooks: [assets/templates/control-theory/README.md](assets/templates/control-theory/README.md)
- Sources: [`data/sources.json`](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.