Skip to content

Target-Update Rate Limiter

Target-stabilization protocol — instantiates Moving-Target Tracking

Throttles the size and frequency of discretionary target revisions to what the tracking loop can actually absorb, converting jittery goal-chasing into changes the system can follow without churn.

A target revised faster than the system can follow doesn't get tracked better by being revised more — it just churns. Target-Update Rate Limiter is the continuous, always-on throttle that keeps discretionary target motion within what the loop can absorb: it caps how large and how frequent a revision may be, and adds a hysteresis deadband that simply ignores wobble below a threshold, so sub-noise fidgeting isn't chased as if it were signal. Both throttles are sized against the loop's actual tracking bandwidth — how much change per unit time it can follow. Its distinguishing idea is a smooth, magnitude-and-frequency throttle applied to the discretionary part of target motion — as opposed to a binary freeze tied to phases (the freeze window) or the identity governance of what the target is (the change log). It answers one complaint: the target is being moved faster than we can keep up.

Example

A central bank rarely jumps its policy rate to wherever conditions imply in one move, even when that implied target has shifted a lot. It moves in small increments — conventionally on the order of ≈25 basis points per meeting — so the vast web of downstream actors (banks, mortgage markets, corporate planners) can re-adjust without whiplash, and it holds when the implied change is within the noise of the data. That gradualism is a rate limiter in action.

Walk the arc: the implied target lurches on a surprising data print; the limiter permits only a bounded step this period rather than the full jump; a smaller, ambiguous wobble arrives next and the hysteresis band holds — no move at all. Downstream tracking stays coherent because the target's discretionary motion is paced to what everyone can follow. Move the full distance every time and the changes amplify into churn as they propagate outward.[1]

How it works

  • Two throttles. A rate limit caps the maximum change per period (and maximum step size); a hysteresis deadband suppresses changes below a threshold. Together they smooth both frequency and magnitude.
  • Sized to bandwidth. Both thresholds are set from a model of the loop's tracking bandwidth — the throttle exists to keep the target's speed within the speed the system can follow.
  • Discretionary only. The limiter governs governable revisions. Exogenous change is explicitly out of scope — it must be absorbed, hedged, or escalated, never merely denied.

Tuning parameters

  • Rate limit / max step — how much change is permitted per period. Tight yields very smooth downstream behavior but is slow to reach a target that has genuinely moved; loose tracks faster but risks churn. Set it from the bandwidth model.
  • Hysteresis width — how large the ignore-it deadband is. Wider rejects more noise but also delays reacting to a real small move; this is the noise-versus-lag trade.
  • Discretionary scope — what counts as governable versus exogenous. Mis-scoping this is the central failure.
  • Override path — how a large, legitimate exogenous move bypasses the limit rather than being throttled into lag.
  • Asymmetry — whether tightening and loosening are allowed at different rates.

When it helps, and when it misleads

Its strength is enforcing churn discipline: when much of the target's motion is discretionary jitter and the downstream loop thrashes under frequent full-size revisions, the limiter keeps the target's effective speed within the loop's tracking bandwidth, so lag stays bounded instead of oscillating. It is the mechanism that makes a busy, opinionated target followable.

Its failure modes flip on the discretionary-versus-exogenous distinction. Throttle change that is actually exogenous and real and the system falls behind a genuinely fast target — then blames the limiter for the lag it created. Set the deadband too wide and it misses real small moves. The classic misuse is using the throttle to suppress legitimate necessary corrections — slow-walking a real change, or damping accountability, under cover of "avoiding churn." The discipline, which is also the archetype's own rule, is to rate-limit discretionary revisions only: genuinely exogenous change must be absorbed, hedged, or escalated rather than denied, because a limiter pointed at the wrong kind of motion manufactures lag and hides infeasibility.

How it implements the components

Target-Update Rate Limiter realizes the archetype's continuous target-stabilization machinery — the components that pace change to capacity:

  • target_change_rate_limit — its core dial: the cap on how large and how frequent a discretionary target revision may be.
  • hysteresis_band — the deadband that holds steady through sub-threshold wobble, so noise isn't tracked as signal.
  • tracking_bandwidth_model — the model of how much change the loop can absorb, against which both throttles are sized.

It does not carve out phase-linked freeze windows (target_freeze_window, protected_invariant) — that is Target Freeze or Change Window; nor record the authorized version of the target (objective_version_and_authority_register) — that is Objective Versioning and Change Log; nor estimate the current state (actual_state_estimate) — that is State-Estimation Filter.

Notes

The limiter governs only the discretionary component of target motion. Pointed at genuinely exogenous change, it doesn't create stability — it manufactures lag and quietly hides infeasibility behind a smooth-looking target. Distinguishing discretionary motion from exogenous motion is therefore not a detail but the precondition for using this mechanism at all.

References

[1] The bullwhip effect is the documented tendency of variability to amplify as it propagates through a chain of dependent actors — small, frequent upstream changes become large downstream swings. Over-frequent, full-size target revisions do the same thing to a tracking loop, which is exactly the churn a rate limiter is meant to damp. ↩