Skip to content

Exposure Cap Policy

Governing policy — instantiates Tail-Dominance Modeling and Control

Caps how much any single source can put at risk, and pre-wires throttles and stop-loss triggers, so one tail realization cannot consume the whole system.

In a tail-dominated system the danger is that one realization — one position, one counterparty, one tenant — grows large enough to sink the whole. The Exposure Cap Policy is the governing rule that forbids that by construction: concentration limits and hard ceilings cap how much any single source can contribute to the aggregate, and a pre-authorized response layer — throttles, stop-losses, kill switches, load-shedding — fires automatically when a limit is approached or breached. Its defining move is that the worst case is bounded in advance rather than predicted: you need not foresee the exact tail event, only cap what any one source can cost and decide the response before the moment arrives. This is the limit side of tail control — preventing the exposure from getting large — as distinct from holding reserves to absorb a loss after it lands.

Example

A SaaS platform runs shared infrastructure for thousands of tenants, and its load is heavy-tailed: most tenants are quiet, but occasionally one runaway job or abusive client consumes most of a shared pool and degrades everyone. The team sets an Exposure Cap Policy. Each tenant gets a rate limit and a concurrency ceiling — no single tenant may exceed ≈5% of a shared pool — plus a response ladder: cross the soft limit and requests are throttled; hit the hard limit and a circuit breaker sheds the excess.

When a customer's misconfigured batch job floods the API, the throttle engages at the soft cap and the breaker sheds load at the hard cap. The blast radius is contained to that one tenant instead of taking down the fleet — the cap bounded the damage and the wired-in response executed at machine speed, with no incident call required to decide what to do.

How it works

Two layers work together. A cap bounds maximum exposure per source and per concentration — a position limit, quota, or ceiling — sized from the tail model's consequence budget so no single realization can exceed tolerance. A response layer of pre-agreed automatic actions then fires as limits are neared or crossed: throttle, stop-loss, kill switch, shed load. Deciding those responses in advance is the crux — they trigger unemotionally during the tail event, rather than being argued over by a committee while the loss compounds.

Tuning parameters

  • Cap tightness — how far below normal use the ceiling sits. Tight caps contain tails hard but throttle legitimate spikes; loose caps rarely bite but let concentration build.
  • Limit granularity — per-position vs per-counterparty vs aggregate/sector concentration. Fine limits stop single blow-ups; aggregate limits stop correlated ones; tail-dominated systems usually need both.
  • Response ladder — how many rungs sit between "slow down" (throttle) and "cut off" (stop/kill). More rungs give graceful degradation at the cost of complexity.
  • Trigger automation — fully automatic vs human-in-the-loop. Automatic is fast and beats discretion in a panic but can misfire on a false signal; a manual gate is safer but slow when the tail is fast.
  • Reset / release rule — how a throttled or stopped source is brought back. Re-enable too eagerly and you re-expose yourself; too slowly and you punish a recovered source.

When it helps, and when it misleads

Its strength is that the worst case becomes bounded by design, and the automatic response removes the human hesitation that turns a contained loss into a catastrophe — it is the stop you actually honour because it fires without you.[1] It converts a modeled tail into bright-line rules that bind before the loss.

It misleads when the cap is sized from a thin-tailed picture of "normal" — then the limit is breached far more often than expected, because the limit itself must be drawn from the tail, not the average. Caps also invite gaming (split one position into many to dodge a per-position limit — which is why aggregate limits exist), and a stop can cause harm: a stop-loss tripped by a transient spike locks in a loss, and a synchronized fleet-wide shed can cascade. The classic misuse is raising the cap whenever it is inconveniently breached — running the limit backwards to permit an exposure someone already wants — until it no longer binds. The discipline is to size caps from the tail model and consequence budget, treat every breach as signal, and change a limit through governance rather than in the heat of the event.

How it implements the components

  • exposure_cap_or_buffer — it supplies the cap half of this component: the concentration limits, ceilings, and quotas that bound how much any one source can put at risk.
  • tail_response_layer — the throttles, stop-losses, kill switches, and load-shedding rules are the pre-wired responses that execute when a tail event pushes against a limit.

It does not size the consequence budget its caps defend (tail_consequence_budget — Heavy-Tail Simulation Scenario Set), hold the reserves that absorb a breach that gets through (the *buffer reading of exposure_cap_or_buffer — Reserve Buffer Policy), or measure realized tail severity (decision_metric_replacement, tail_drift_monitor — Expected Shortfall Dashboard).*

Notes

A cap and a buffer are complements, not substitutes. The cap bounds how large one source can get; the buffer absorbs the loss that gets through anyway. Caps alone leave you open to correlated breaches no single limit anticipated; buffers alone let concentration build until the reserve is overwhelmed. An honest tail-control design carries both, sized from the same tail model.

References

[1] The circuit breaker and bulkhead patterns from resilience engineering: partition a system so a failure in one compartment trips a breaker and is isolated rather than flooding the whole. An Exposure Cap Policy is the governing analogue — bulkheads on exposure, with breakers wired to the limits. ↩