Capacity Expansion Trigger¶

Expansion trigger rule — instantiates Saturation Avoidance

Fires a pre-authorized expansion of staffing, tooling, or bandwidth when saturation persists past a threshold and the demand is worth serving rather than shedding.

Most saturation responses shrink the input; this one grows the channel. Capacity Expansion Trigger is the rule that says: when a channel has been saturated past a set threshold for long enough, and the demand hitting it is legitimate rather than junk, add capacity — more staff, more compute, more bandwidth, more lanes — instead of continuing to cap, queue, or reroute. Its defining move is that expansion is pre-authorized and condition-fired, not negotiated from scratch during every crunch: the threshold, the persistence test, and the expansion increment are decided in advance so the response is fast and disciplined. The persistence test is the crux — a momentary spike should be absorbed (that is what buffers and burst budgets are for); only sustained saturation of demand worth serving justifies paying to grow the channel.

Example¶

A national tax agency's phone and correspondence centre is comfortable most of the year and slammed for the ten weeks around the filing deadline. A Capacity Expansion Trigger turns that predictable saturation into a pre-agreed response. The rule watches the saturation signal — hold times, abandoned calls, correspondence-aging past target — and when those sit above the threshold for more than a defined window (say, five consecutive business days, not one bad Monday), it fires the pre-authorized expansion: activate the trained seasonal roster, extend hours, and stand up the overflow tooling that was provisioned but idle.

Because the increment and the funding were authorized ahead of time, the centre expands in days rather than the weeks a fresh approval would take — and because the trigger is tied to persistence, it doesn't over-hire for a single noisy afternoon. When the season passes and the signal falls back under threshold for the defined window, the same rule stands the surge capacity back down.

How it works¶

Pre-authorize the increment. The expansion option — a seasonal roster, an autoscaling group, a standby vendor — is provisioned and funded before the crunch, so firing is fast, not a fresh fight.
Require persistence, not a spike. The trigger fires only when saturation holds above threshold across a defined window, so buffers absorb transients and expansion answers sustained load.
Test that the demand is worth serving. Expansion is gated on the load being legitimate; junk or malformed demand should be governed at the source, not met with more capacity.
Wire the stand-down. The same rule releases the added capacity when the signal recedes, so the surge doesn't quietly become permanent cost.

Tuning parameters¶

Persistence window — how long saturation must hold before expansion fires. Longer avoids over-reacting to spikes but leaves the channel saturated longer; shorter reacts fast but over-provisions on noise.
Expansion increment — how much capacity each firing adds. Large steps clear saturation decisively but risk overshoot and cost; small steps track demand closely but may lag a fast climb.
Stand-down hysteresis — how far below threshold, and for how long, before capacity is released. Wide hysteresis avoids thrashing on and off; tight release recovers cost faster but risks flapping.
Demand-legitimacy gate — how strictly load is vetted before expansion answers it. Strict gating prevents feeding runaway or abusive demand; loose gating expands to serve anything.

When it helps, and when it misleads¶

Its strength is a fast, disciplined "grow the channel" response for demand genuinely worth serving — turning a predictable or persistent crunch into a pre-planned expansion instead of an every-time emergency, and standing the capacity back down when the need passes.

Its central trap is being the only response to a demand problem. Expanding a channel whose demand is ungoverned can induce more demand — the newly freed capacity is consumed as fast as it is added, and the channel saturates again at a higher cost base.^[1] Expansion is also slow and lumpy for truly bursty load (you can't hire for an afternoon), and a surge left un-stood-down silently becomes permanent overhead. The discipline is to pair expansion with demand governance (caps, prioritization) so growth serves real need rather than feeding an appetite, to reserve buffers for transients, and to honour the stand-down.

How it implements the components¶

Capacity Expansion Trigger fills the archetype's grow-the-channel components:

capacity_expansion_option — it owns the provisioned, pre-authorized means of adding capacity (staffing, tooling, bandwidth, process).
capacity_threshold — it fires against a defined saturation threshold, expanding when load holds above it.
saturation_signal — its firing condition reads the persistent saturation signal that ordinary buffering has failed to clear.

It does not reduce or ration demand — that is Frequency Cap's and Queue Admission Limit's — nor divert it (Alternate Pathway Routing). It answers saturation by adding supply, and works best paired with a demand-side sibling.

Instantiates: Saturation Avoidance — resolves persistent saturation by pre-authorized capacity growth.
Consumes: Channel Capacity Management supplies the threshold and channel model the trigger fires against.
Sibling mechanisms: Alternate Pathway Routing · Queue Admission Limit · Channel Capacity Management · Saturation Dashboard · Frequency Cap · Worker Caseload Limit · Overflow Queue · Graceful Degradation Mode · Attention Cap Management · Ad Frequency Cap

References¶

[1] Induced demand (the Jevons-paradox pattern): making a constrained resource more available often raises its consumption, so added capacity is absorbed rather than relieving pressure. It is why capacity expansion divorced from demand governance can re-saturate a channel at a higher cost base. ↩