Skip to content

Support Load Quota

Protocol — instantiates Donor-Coupled Capacity Governance

Caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased.

A Support Load Quota is an enforced ceiling on how much subsidy a single donor will carry — a standing rule that stops the flow from growing past a set share, rather than merely measuring or warning about it. Its defining feature is the release valve: the cap is not permanent but conditional. Once the recipient has diversified its sources, agreed to reprice the support toward reciprocity, or reached a capacity milestone that lowers its need, the quota loosens. Until then, additional demand above the ceiling is refused, throttled, or bounced back to the requester. Where a stress test derives a safe ceiling and a dashboard watches the share against it, the quota is the operating protocol that acts on the boundary — it is the mechanism through which "the donor should not carry more than X" becomes an actual limit that new load hits and cannot pass.

Example

A developer maintains a popular open-source data library in her spare time. A fast-growing analytics company has built its product on the library and now files a stream of urgent issues, expects rapid fixes, and treats her free labor as a de facto support contract — a hidden subsidy flowing from one unpaid person to a funded business. Rather than quit or burn out, she institutes a Support Load Quota.

The protocol sets a ceiling: unpaid priority support is capped at a fixed number of hours per month per commercial user. Above the cap, requests don't vanish — they hit a reciprocity rule: a company wanting priority beyond the free tier must either sponsor the project at a set monthly amount (repricing the subsidy toward exchange) or contribute maintainer time back. The quota also names its release conditions as capacity milestones: if the company's own engineers land three accepted fixes and pass the contributor onboarding, its team is credited as co-maintainers and its effective quota rises, because it now adds capacity instead of only consuming it. The result is that her hidden subsidy stops silently expanding: it is bounded, it can be bought out fairly, and it shrinks as the recipient builds its own capacity — exactly the three exits the archetype wants for an over-loaded donor.

How it works

The distinguishing move is a conditional, enforced ceiling with named release valves, not a passive limit:

  • Set the load ceiling as an operating rule. Fix the maximum subsidy share or obligation the donor will carry, and wire it so requests above it are actually refused, queued, or downgraded — enforcement, not advice.
  • Route overflow to reciprocity. Demand above the cap is not simply denied; it is offered a priced or reciprocal path, so legitimate need can still be met by turning subsidy into exchange.
  • Attach release conditions. The quota loosens only on specified events — a second source secured, a repricing accepted, a capacity milestone met — so relief is earned, not assumed.
  • Re-evaluate on trigger. When a release condition fires, the ceiling is recomputed; otherwise it holds, so the cap tracks the recipient's real progress toward needing less.

Tuning parameters

  • Ceiling level — how high the cap sits. A generous ceiling avoids choking legitimate support; a tight one protects the donor sooner but can strand a recipient with nowhere else to turn.
  • Enforcement hardness — whether the cap is a hard refusal or a soft throttle. Hard caps protect the donor absolutely but can cause abrupt harm; soft throttles bend under genuine emergency but leak.
  • Release stringency — how demanding the diversify/reprice/capacity conditions are. Strict conditions keep the cap meaningful; lax ones let it dissolve back into open-ended subsidy.
  • Overflow pricing — how the reciprocal path above the cap is priced. Too high blocks access; too low fails to shift the load off the donor.

When it helps, and when it misleads

Its strength is that it is the one mechanism here that bounds an over-extending subsidy in real time and gives the excess a fair off-ramp instead of a wall. It directly answers the archetype's "protect the source" invariant and its "moral hazard" symptom — the recipient that keeps consuming because the support is indefinite and free.

Its failure mode is that a shared donor resource under open demand is a commons, and a quota that is set too loosely or unenforced invites the tragedy of the commons — each requester rationally consuming more of the free support until the donor is exhausted.[n1] Conversely, a rigid cap can inflict real harm when a genuine emergency exceeds the ceiling and the soft-throttle escape was designed out. The classic misuse is a quota used as a pretext to starve a legitimate obligation — pointing at "the cap" to refuse support that fairness actually requires. The guarding discipline is to pair the ceiling with a genuine reciprocal off-ramp and an emergency exception, so the quota reshapes the load rather than simply denying need.

How it implements the components

  • support_load_limit — it is the enforced ceiling: the operating cap on how much subsidy the donor carries.
  • reciprocity_or_obligation_rule — overflow above the cap is routed to a priced or reciprocal path, converting excess subsidy into governed exchange.
  • local_capacity_milestone — the quota's release conditions are tied to recipient capacity gains, so the cap loosens as the recipient builds its own capacity.

It does not test whether the donor can survive a shock, nor stage a fallback — donor_resilience_guardrail and fallback_support_source belong to Donor Stress Test, its nearest source-protecting sibling. The stress test finds the ceiling the donor can bear; this protocol is the standing rule that enforces one.

Editorial Notes

Form Classification

Form family: Control, Automation & Runtime

Rationale: Support Load Quota is defined in the frozen evidence as: Caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased. Its operative deployed or enacted form is therefore Control, Automation & Runtime.

Nearest alternative: Assessment, Review & Assurance — Assessment, Review & Assurance 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: Economics & Finance

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Universal

Rationale: Capping support demand per actor or period allocates a scarce service resource and prices or constrains externalized load. NIST queueing theory grounds the relationship between arrival demand, finite service capacity, utilization, and delay; economics supplies quota allocation and incentives.

Related originating lineages:

  • Law & Governance — Legal doctrine, regulatory governance, and procedural accountability supplies a parallel or contributing lineage for the mechanism's defining operation: caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased.
  • Logistics & Supply Chain Management — logistics_supply_chain contributes logistics, inventory, and supply-chain operations to this mechanism's defining operation—Caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased—without displacing the selected primary historical lineage.
  • Operations Research — operations_research contributes operations research, optimization, and queueing analysis to this mechanism's defining operation—Caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased—without displacing the selected primary historical lineage.
  • Organizational & Management Science — Workload quotas protect service capacity.
  • Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: caps donor obligation or hidden subsidy share until support is diversified, repriced, or capacity is increased.

Review resolution: The blind reviewers disagree on primary lineage (economics_finance versus organizational_management). Authoritative or primary research supports economics_finance as the best historical origin: Capping support demand per actor or period allocates a scarce service resource and prices or constrains externalized load. NIST queueing theory grounds the relationship between arrival demand, finite service capacity, utilization, and delay; economics supplies quota allocation and incentives. 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=cross_disciplinary_synthesis 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] Tragedy of the commons — Garrett Hardin's account of how a shared, unpriced resource is over-consumed when each user's incentive is to take more while the cost of depletion is spread across all. An unbounded donor's free support is exactly such a commons.