Search the feasible region without drifting out of it

For an infinity-ball image threat, the feasible coordinate interval is the intersection of the original pixel’s epsilon interval with the legal image box. Clip each proposed iterate to those fixed bounds. Clipping only into [0,1] enforces image validity but allows repeated steps to exceed the total threat budget. Clipping around the previous iterate enforces a per-step budget and has the same drift problem. The clean original tensor must remain available and unchanged throughout the run.

Euclidean projection uses a radial rescaling for a norm ball, whereas an additional box intersection needs care. A sequential ball projection and box clipping can produce a feasible point for a box containing the original image, but should not be described automatically as the exact Euclidean projection onto the intersection. The optimization method and any approximation should be stated. Feasibility and exact projection optimality are different properties, and only the former is required to validate a found counterexample.

Initialize each restart using a documented distribution over feasible points, and record its seed. Uniform sampling in an infinity box is straightforward before accounting for clipping at the image boundary; clipping a larger random box does not generally yield a uniform sample from the final intersection. Uniformity is not required for a valid attack, but the actual initialization law should be described accurately. Include the clean start as a useful reference when comparing restart policies.

Track the strongest relevant candidate across every iterate and restart. For deterministic untargeted classification, once a valid candidate is misclassified, preserve that success even if later steps return to the correct class. A maximum-loss candidate and a successful candidate need not be identical when a surrogate ranks them differently. Reevaluate saved candidates through the final wrapper. Adding restarts should not increase reported survival when earlier candidates and the same success definition are retained.

Sweep step size, iteration count, loss formulation, and restart count on development examples while keeping the final evaluation protocol fixed. A large step may bounce across a narrow useful region; a tiny step may barely move within the allowed runtime. Plot best-so-far loss and cumulative valid failures rather than only final loss. Flat curves can indicate convergence, poor gradients, numerical saturation, or a broken constraint implementation, so they are not independently a robustness argument.

Budget comparisons should count actual model evaluations and backward passes, not only an iteration label. A restart with many gradient samples per step costs more than a deterministic single-gradient run. Report wall time and hardware as additional practical measurements. Retain per-example traces or sufficient summaries to inspect a sudden increase in survival after a code change. A seemingly stronger configuration that finds fewer failures deserves investigation before its result becomes a claimed defense improvement.