Surplus-Load Diversion¶
Diversion method — instantiates Assimilation Ceiling Guarding
Keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away.
When intake exceeds the ceiling, there are only three things you can do with the excess: force it through and damage the receiver, refuse it and lose its value, or send it somewhere else. Surplus-Load Diversion is the third path. It maintains an explicit account of the load that is beyond what the receiver can currently metabolise, and reroutes that surplus to an alternate sink with spare capacity — a queue, a buffer, a partner, a secondary path — with a way to drain it back when the receiver recovers. Its defining move is that it preserves the input's value while sparing the receiver: unlike a rate limit, which stops the surplus at the door, and unlike a gate, which holds it there, diversion gives the excess somewhere useful to go. That is also its precondition — it only works if a real alternate sink exists.
Example¶
A retailer's customer-support line is a good problem to have: more contacts means more sales and more loyal customers — right up until volume outruns the agents, hold times balloon, quality craters, and callers who could have been served well are served badly instead. Rather than let the queue collapse or simply drop calls, the ops team runs Surplus-Load Diversion. Past a watermark, contacts the model flags as deferrable or self-serviceable are peeled off the live queue: offered a scheduled callback, routed to a partner call centre under an overflow contract, or deflected into a guided self-service flow. The "surplus" is tracked as an explicit ledger — how many contacts are diverted, where, and whether they were resolved — and as agents free up, callbacks are drained back into the live queue. The thresholds are illustrative; the effect is that the core queue stays fast, the overflow is absorbed elsewhere rather than lost, and no caller's demand is simply forced through a saturated team.
How it works¶
- Classify what may be diverted. Split incoming load into must-serve-here-now and divertible; the surplus is drawn only from the divertible class.
- Keep the surplus ledger. Track what has been diverted, where it went, and its disposition — drained back, resolved elsewhere, or expired — so the excess is managed, not just displaced and forgotten.
- Route to a sink with real capacity, and drain back. Send surplus to an alternate path that genuinely has headroom, and reintroduce it as the receiver recovers, at a pace that does not re-overload it.
Tuning parameters¶
- Divert watermark — how full the receiver gets before diversion starts; low diverts prematurely and wastes the primary path, high risks overshoot before it engages.
- Divertibility policy — which classes of input are eligible; mis-classing must-serve items as divertible degrades exactly what you meant to protect.
- Sink selection and depth — where surplus goes and how much it can hold; a shallow sink just moves the cliff a few metres.
- Drain-back rate — how fast diverted load is reintroduced as capacity frees; too fast re-overloads the receiver.
- Time-to-live on the sink — how long diverted items stay valid before they are expired or dropped.
When it helps, and when it misleads¶
Its strength is that it protects the receiver without destroying the input's value: nothing is throttled off at the source or lost outright, so a beneficial surge is smoothed and captured instead of either crashing the system or being turned away. It is the archetype's pressure-relief path.
Its failure modes come from the sink and from over-reliance. The alternate sink can itself saturate or feed back, at which point diversion merely relocates or delays the overload — a shallow buffer that "moves the cliff." And because it hides the strain so well, sustained diversion becomes a crutch: a chronic capacity shortfall gets masked for months while diverted surplus quietly rots undrained. The technique is the same demand-shedding logic as load shedding[n1] in power and computing, and the discipline is the same: size and monitor the sink as seriously as the primary path, cap how long you will lean on it, and read sustained diversion as a signal to fix capacity — not as the fix itself.
How it implements the components¶
Surplus-Load Diversion fills the routing side of the archetype — the components a rerouting method operates:
surplus_load_account— it maintains the ledger of over-ceiling load: what is surplus, how much, where it went, and whether it was drained, resolved, or expired.input_diversion_path— it is the routed path to an alternate sink, plus the drain-back that returns surplus when the receiver recovers.
It does not decide *when the receiver is in trouble — that reading comes from Secondary-Resource Telemetry and the escalation tiers of Protected-Margin Escalation Rule. It caps neither the source rate (input_throttle_authority — that's Input Rate Limit) nor cumulative intake by tranche (that's Staged Absorption Gate); it handles the excess those guards produce.*
Related¶
- Instantiates: Assimilation Ceiling Guarding — diversion is the relief path for load the other guards refuse or hold.
- Consumes: Secondary-Resource Telemetry supplies the signal that intake has gone surplus.
- Sibling mechanisms: Input Rate Limit · Staged Absorption Gate · Protected-Margin Escalation Rule · Secondary-Resource Telemetry · Cleanup Capacity Reserve · Assimilation Capacity Audit
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Surplus Load Diversion is defined in the frozen evidence as: Keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away. Its operative deployed or enacted form is therefore Decision, Gate & Allocation.
Nearest alternative: Organization, Role & Governance — Organization, Role & Governance can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Routing work away from an overloaded node to alternate channels when utilization crosses a threshold is queueing and load-balancing. NIST queueing methods model finite service channels and waiting; logistics and distributed computing provide convergent diversion implementations.
Related originating lineages:
- Computer Science & Software Engineering — computer_science contributes computer science and software-engineering practice to this mechanism's defining operation—Keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away—without displacing the selected primary historical lineage.
- Disaster Management & Risk Reduction — disaster_management contributes continuity, incident recovery, readiness, and resource coordination to this mechanism's defining operation—Keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away—without displacing the selected primary historical lineage.
- Logistics & Supply Chain Management — Logistics, inventory, and supply-chain operations supplies a parallel or contributing lineage for the mechanism's defining operation: keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away.
- Mathematics — Mathematical modeling, proof, and abstract-structure practice supplies a parallel or contributing lineage for the mechanism's defining operation: keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: keeps a ledger of load beyond what the receiver can absorb and reroutes that surplus to an alternate sink, so excess is offloaded rather than forced through or thrown away.
Review resolution: The blind reviewers disagree on primary lineage (logistics_supply_chain versus operations_research). Authoritative or primary research supports operations_research as the best historical origin: Routing work away from an overloaded node to alternate channels when utilization crosses a threshold is queueing and load-balancing. NIST queueing methods model finite service channels and waiting; logistics and distributed computing provide convergent diversion implementations. The cited NIST, Quantitative Methods for Management: Queueing Theory directly supports the mechanism's defining operation. All independently supported contributing domains are retained without an arbitrary cap. origin_mode=convergent records lineage, while domain_reach=universal records later applicability separately from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Load shedding — deliberately deferring, dropping, or rerouting a portion of incoming work when demand exceeds capacity, to keep the rest of the system healthy rather than letting everything degrade together. It is standard in power systems and high-scale service engineering; diversion is the value-preserving variant that sends the shed load somewhere useful instead of discarding it. ↩