A corrective action needs a mechanism and an observable invariant

If unbounded concurrent inference requests retain activations until a shared GPU exhausts memory, an admission limit must act before those allocations occur. A metric added after allocation may improve detection but does not enforce the bound. A timeout also fails to release memory if cancellation never reaches the worker. Map each proposed action to the exact boundary it changes: prevent admission, bound retained work, release state, reduce propagation, detect failure, or accelerate recovery. State what remains possible after the action.

For every control, identify scope and bypass paths. A limit of ten in each of three independent dispatchers is not a global limit of ten on one shared device. Work started by background jobs or old binaries can escape a newly added frontend check. Likewise, limiting request count does not prove a byte bound when requests have very different shapes. A useful review asks whether the mechanism's assumptions match the real resource and whether the implementation owns all relevant admission and release paths.

A concurrency fix can assert that outstanding allocations remain within the scoped budget while requests are admitted, canceled, timed out, and retried. Test the old failure fixture as a positive control for the oracle, then verify the changed behavior and useful service. An error-message check alone can miss a leak that no longer emits the same message. Also test release on exceptional paths: a control that blocks overload but never returns permits can eventually make every request wait forever.

Record the action's owner, rollout target, verification artifact, and operating assumptions. Separate implementation completion from verified deployment, especially when old workers can remain active. Include a measurable follow-up for operational controls whose effect appears only under sustained conditions. Avoid treating every action as equally valuable because it fits a checklist; prioritize by the mechanism it interrupts and the evidence available to show improvement. The goal is a testable change in system behavior, not a polished list of generic lessons learned.

A strict cap can prevent one failure while producing unacceptable queueing or unfairness. Define how excess work is rejected or delayed, what clients should do, and whether deadlines propagate. Verify correctness and legitimate throughput as well as the resource invariant. If a client retries immediately after rejection, the control can shift pressure elsewhere. Corrective design therefore includes interactions with callers and dependencies, rather than assuming one local bound settles the entire availability objective.

The queue lab is a fixed-rate work illustration, not an admission limiter. Reset, set both λ=3 and μ=2, predict growing backlog from four items, then Play or Step. Reset and set both λ=2,μ=3 for a separate comparison. Editing preserves elapsed time and recomputes from the initial four. No finite queue, memory allocation, fairness policy, or cancellation path is implemented. Use the visual to ask whether the real action changes admitted work, completed work, or neither, and verify that change with the actual oracle.