AION change note: correcting soft-pressure fan-out handling
A historical event-bus change note, with the observed symptom, reported adjustment and evidence boundary separated.
The recorded failure
The October 3 change history reported that a threshold mismatch caused a soft-pressure condition to park fan-out even while workers were ready. That is a scheduling policy problem: a soft resource warning should not silently become the same hard stop used for an unsafe or exhausted system.
The published brief recorded a fan-out budget of zero, ready workers and a mismatch between the threshold and the intended behavior. This article expands the original note to explain the failure category, not to claim a new incident reproduction.
The change described in the historical record
The history states that the canonical HIGH threshold and the bounded throttling behavior were aligned. The distinction matters because throttling should constrain concurrency or load within a defined envelope while preserving the ability to do eligible work. Hard blocking should be reserved for a truly binding limit or an independent safety constraint.
The original note described a retest in which ID/State and IS work resumed through the normal route. This should be read as a historical assertion from the dated changelog, not as evidence that all current workers, leases or channels are healthy today.
How to inspect a comparable repair
A meaningful retest would retain the pre-change threshold, the observed fan-out budget, worker readiness, the applied bounded behavior and a second readback. It should verify both the positive case (eligible work proceeds) and negative cases (hard limits still deny). Simply changing a status label from BLOCKED to READY would not be sufficient.
The AION verification guide explains how to keep the input, decision, execution and observed output in one evidence chain. Current operational status needs fresh receipts rather than extrapolation from the October 3 note.