Capacity Trigger Revision¶
Resource-management rule — instantiates Adaptive Threshold Recalibration
Resets the load level at which a system starts shedding, scaling, escalating, or diverting so it matches today's demand pattern, not last year's.
Capacity Trigger Revision resets a boundary that is defined in units of load — occupancy, backlog, latency, utilization — and wired to an automatic operational action: scale out, staff up, reserve, divert, or shed. What makes it its own mechanism is why the boundary drifts: not because detection accuracy fell, but because the demand baseline moved underneath a trigger that was calibrated to a world that no longer exists. The number is unchanged; the traffic it was meant to describe has changed. Recalibration here is an act of re-fitting an actuation threshold to the current load profile so the action still fires at the right moment.
Example¶
A hospital emergency department has a rule: when bed occupancy crosses 90%, go on ambulance diversion. That trigger was set when the average patient cleared the department in four hours. Two years on, boarding admitted patients has pushed the average dwell far longer, so the same 90% now describes a department already in gridlock — diversion fires too late to help. Capacity Trigger Revision re-derives the trigger from the current flow: occupancy relates to arrival rate and length of stay,[1] and with stays this long the safe divert point is nearer 80%. They add a hysteresis band (divert at 80%, resume below 72%) so the ED doesn't flap on and off diversion every twenty minutes, and they map the downstream effect — diverting earlier here shifts ambulances to neighboring hospitals, whose capacity has to hold.
How it works¶
The distinctive step is re-deriving the trigger from a current baseline of demand and service, not from the historical setpoint. Because the action is automatic and often destabilizing, the rule is set with hysteresis (separate fire and clear levels) and a smoothing window so transient bursts don't actuate. And because capacity actions cascade — shedding here loads the neighbor there — the revision explicitly traces the propagation before the new level goes live.
Tuning parameters¶
- Trigger level — the load value that fires the action; set against the current baseline, not the legacy one.
- Hysteresis band — the gap between fire and clear points; wider stops flapping but leaves the system in the actuated state longer.
- Smoothing / lead window — how much the load signal is averaged or forecast before firing; longer avoids twitchiness but reacts later.
- Action severity — whether crossing triggers a soft action (reserve, page) or a hard one (divert, shed); harder actions demand more margin.
- Scope — per-unit versus system-wide triggers; local scope fits each node but can push load onto neighbors.
When it helps, and when it misleads¶
Its strength is keeping automatic load actions matched to real demand, so scaling and diversion fire when they actually help rather than when an obsolete number says so. Its classic misuse is nudging the trigger to flatter a utilization KPI — raising the divert point so the department "runs hot" on paper while the floor is genuinely unsafe. The failure hides inside a metric that looks efficient. The discipline is to re-derive the trigger from the load–service relationship and to keep the downstream cascade in view, so the number stays accountable to safety and to neighbors rather than to a utilization target.
How it implements the components¶
baseline_context_model— it rebuilds the current demand and service profile the trigger must be re-fitted against; this is the component that catches the drift.current_threshold_rule— it documents and resets the load level and the automatic action attached to crossing it.downstream_effect_map— it traces the operational cascade a moved capacity trigger sets off across neighbors and responders.
It does not weigh detection error costs (false_positive_false_negative_review) — that is Precision / Recall Tradeoff Review — nor does it record the change for audit (audit_trail_and_rationale), which Threshold Versioning Register owns.
Related¶
- Instantiates: Adaptive Threshold Recalibration — it is the resource-side instance: refitting a load-actuation threshold to a shifted demand baseline.
- Sibling mechanisms: Alert Threshold Tuning · Threshold Versioning Register · Staged Threshold Rollout · Precision / Recall Tradeoff Review · Policy Threshold Update
References¶
[1] Little's Law — in a stable queue, the average number in the system equals arrival rate times average time in system (L = λW). It is why a longer length of stay makes the same occupancy far more dangerous, and why a capacity trigger set to an occupancy number must be re-derived when service time drifts. ↩