Skip to content

Defect-Population Limit Protocol

Policy — instantiates Mobile-Defect Reconfiguration

Caps how many mobile defects may be in flight at once and gates their introduction, bounding concurrent disruption to what can be verified and recovered.

Defect-Population Limit Protocol governs how many transitions may be in motion at the same time. It sets a hard ceiling on the number of mobile defects in flight and enforces it at the introduction gate — the point where a new defect is admitted to the substrate — admitting the next only when a slot frees. Its defining trait is that it manages concurrency, not the individual move: it does not care how any single defect glides or hands off, only that the total number moving at once stays within the bound the system can verify, contain, and recover if several go wrong together. It is the throttle that keeps many small changes from becoming one uncontrolled global one.

Example

A state DOT maintains a busy corridor by moving crews through it — each active work zone is a mobile "defect" that pinches traffic where it sits. Left ungoverned, districts would open work zones wherever convenient and the corridor would seize. The Defect-Population Limit Protocol caps concurrent closures: no more than, say, two active mobile work zones on the corridor at once, and none within a set distance of another. New closures are admitted only through a permitting gate that checks the current count and spacing before issuing. When a crew finishes and reopens its lanes, a slot frees and the next permitted zone may open. The cap is set to what the corridor can absorb and what incident-response can cover if two zones have trouble at once — not to how fast the districts would like to work.

How it works

  • Set the concurrency cap. A hard limit on simultaneous in-flight defects, chosen against verification and recovery capacity — not throughput appetite.
  • Gate every introduction. New defects enter only through a single admission point that checks the live count (and any spacing or exclusion rules) before admitting.
  • Admit on release. When an in-flight defect reaches its sink or is otherwise retired, a slot opens and the next waiting defect is admitted.
  • Hold the queue. Demand above the cap waits rather than being forced in, so concurrency never exceeds the bound under pressure.

Tuning parameters

  • Cap size — the maximum concurrent defects. Higher throughput versus a larger combined blast radius if several fail at once.
  • Admission rule — beyond a raw count: spacing, exclusion zones, or class-based sub-limits at the gate.
  • Queue discipline — how waiting defects are ordered (priority, first-in-first-out, deadline) when demand exceeds the cap.
  • Elasticity — whether the cap flexes with conditions (tighter at peak load, looser in quiet windows) or stays fixed.

When it helps, and when it misleads

Its strength is that it bounds combined blast radius. The failure a system must survive is several in-flight changes going wrong together, and a concurrency cap is what keeps that worst case within recovery capacity. It is the mobile-defect form of a work-in-progress limit: cap the number of things in motion so the system can actually finish and verify each.[1]

A cap set by gut is either so tight it needlessly stalls throughput or so loose it doesn't actually bound the worst case — and a limit routinely waived under schedule pressure is no limit at all. It also governs only quantity: it says nothing about whether any individual move is safe, so a small population of badly-behaved defects can still do damage. The discipline is to tie the cap to genuine verification-and-recovery capacity rather than to demand, and to make the gate the one true entry point so the limit can't be bypassed.

How it implements the components

  • defect_population_control — the hard cap on how many mobile defects are in flight simultaneously.
  • defect_introduction_gate — the single admission point that enforces the cap, admitting a new defect only when a slot and the spacing rules allow.

It bounds quantity but not per-move safety: the legality of an individual move belongs to Adjacent-Swap Sequence, and the safety of an individual boundary crossing belongs to Canary Handoff Sequence.

References

[1] A work-in-progress (WIP) limit — from Kanban and lean flow, and mirrored in mechanisms like a rolling update's maxUnavailable — caps how many items may be in progress at once so that flow, verification, and recovery keep pace rather than drowning under everything started at once. ↩