Overflow Redirection¶

Workflow — instantiates Net-Additive Contribution Intake

Sends offers the system can't absorb right now to a later window, a partner program, or an external recipient — so surplus help is placed rather than dropped or hoarded.

Overflow Redirection is the workflow that handles good offers arriving beyond current capacity — not by refusing them, but by placing them somewhere else. Its defining move is to preserve the contribution's value while changing its destination: when intake hits its capacity limit, the offer is routed to a later intake window, a partner program, or an external recipient who can actually use it. This is what separates it from its neighbours. A pause stops the flow and a rejection notice ends the offer; redirection keeps the offer alive and simply sends it where there is room. It exists because the alternative to redirecting surplus is worse for everyone: either the system hoards offers it can't process, or it wastes willing help that some other recipient would have welcomed.

Example¶

A regional food bank is offered a farmer's surplus — three pallets of ripe tomatoes — on a week when its own cold storage and volunteer sorting are already maxed. Accepting would mean the tomatoes rot in a corner before anyone can handle them; a flat "no thanks" wastes good food a hungry pantry could use today. Instead the food bank runs its Overflow Redirection workflow: it recognizes it is over its intake capacity for perishables this week, consults its directory of partner pantries and their current needs, and warm-hands the donation to two nearby pantries with the fridge space to take it — connecting the farmer directly and confirming the handoff.

The tomatoes reach people instead of a dumpster, the food bank protects its own strained operation, and the farmer's goodwill is met with a real placement rather than a rejection. Nothing additive was thrown away; it was simply routed to where the capacity was.

How it works¶

What distinguishes redirection from either refusing or accepting is that it relocates value:

Detect the overflow. Compare current inflow against the intake capacity limit; redirection engages precisely when a good offer exceeds what the system can absorb now.
Consult the alternates. Draw on a maintained directory of later windows, partner programs, and external recipients, with a live sense of who currently has room.
Place and hand off. Route the offer to the best available alternate and complete a real handoff, so the contribution lands somewhere rather than being merely deflected.

Tuning parameters¶

Capacity-limit strictness — how full the system must be before overflow engages. A tight limit redirects early and protects core capacity; a loose one absorbs more but risks the pile-up redirection is meant to prevent.
Directory breadth and freshness — how many alternates exist and how current their capacity is known to be. A rich, live directory places offers well; a stale one redirects into dead ends that quietly become rejections.
Defer vs. hand off — whether to hold an offer for a later window or send it externally now. Deferral keeps the contribution in-house if timing is the only constraint; external handoff frees the system entirely.
Handoff warmth — a warm introduction versus a bare pointer. A warm handoff lands the offer reliably and honors the partner relationship; a pointer is cheaper but more likely to drop.

When it helps, and when it misleads¶

Its strength is that it wastes neither the help nor the system: willing contributions still reach a recipient, and core capacity is protected, without the relational cost of a flat refusal. In a network of aligned recipients it turns one organization's overflow into another's supply.

It misleads when the directory it depends on is stale — a redirect to a partner who is themselves swamped or defunct is a rejection dressed up as a placement, and often a worse one because it looks like help. Its classic misuse is burden-shifting: redirecting freely, including offers of little value, so that saying no is never necessary and partners become a dumping ground.^[1] The discipline that guards against both is to keep the alternate directory genuinely live and to redirect only offers a receiving partner would actually want.

How it implements the components¶

Overflow Redirection realizes the capacity-and-alternates components:

intake_capacity_limit — it operates against an explicit limit; the limit is the line that defines when an offer is "overflow" to be redirected.
alternate_recipient_directory — it maintains and draws on the directory of later windows, partner programs, and external recipients that redirection routes toward.

It does not judge whether an offer is net-additive in the first place (that is contribution_net_value_review), and it does not stop the inflow outright — a full halt is Intake Pause.

Instantiates: Net-Additive Contribution Intake — redirection is the pressure-relief path for offers beyond capacity.
Consumes: a read of current load against capacity (from the intake demand signal) to know when overflow has begun.
Sibling mechanisms: Intake Pause · Clean Rejection Notice · Alternate Recipient Directory · Side-Channel Redirect Notice · Material Donation Acceptance List

References¶

[1] Load shedding — the deliberate redirection or dropping of load to protect a system's core function, as when a power grid sheds demand to avoid collapse. Done well it is protective; done indiscriminately it just moves the overload onto whoever is downstream, which is why redirection must be selective about what it passes along. ↩