Before you publish a robustness number from a wrapped model, how do you verify that the gradient surface your wrapper exposes really is the gradient of the model's loss with respect to its input?

### Why this check exists at all The gradient surface of an estimator wrapper — `loss_gradient(x, y)` in Adversarial Robustness Toolbox, the framework-native backward pass behind a Foolbox model — is the one component that can be completely wrong while looking completely fine. Shapes match, dtypes match, no exception is raised, and the attack runs to completion. Every way it fails pushes the result in the same direction: the attack gets weaker, so the model looks more robust, so nobody investigates. That asymmetry is the reason the check has to be explicit and automated rather than a thing someone did once in a notebook. ### The core test: central finite differences through `predict` only Pick an input, pick a coordinate, nudge it up by a step and down by the same step, evaluate the loss both times **using only the prediction surface**, and compare the central difference against that coordinate of the returned gradient: ``` fd_i = ( L(predict(x + h*e_i)) - L(predict(x - h*e_i)) ) / (2h) compare fd_i against loss_gradient(x, y)[i] ``` The whole value of the test is that the left side never touches the gradient code path. Agreement is therefore real evidence that the two surfaces describe the same function. Practical settings: sample a dozen coordinates on three or four inputs rather than sweeping the tensor; compare on relative error rather than absolute; and choose `h` deliberately — too small and float32 cancellation dominates the numerator, too large and curvature does. A mismatch that appears only at extreme step sizes is usually a bad `h`, not a bad surface. ### Cheap sanity checks that catch different bugs - **All zeros** — a detached or `no_grad` preprocessing step, an untracked input leaf, or a saturated softmax on a fully confident model. - **NaN or inf** — a log of zero in the loss, or a division by a zero scale in normalisation. - **Wrong shape or transposed layout** — wrapper and model disagree about channel ordering, so every perturbation lands in the wrong place while the array still looks plausible. - **Sign** — one small step along the negative gradient should lower the loss on most inputs. If it consistently raises it, the exposed surface's sign convention is inverted and your attack is a determined defence. - **Batch reduction** — this one is the classic. If the wrapper's loss is constructed with mean reduction over the batch, the per-sample gradient it returns is scaled by 1/N. Difference a single sample and you will see a discrepancy of exactly the batch size. Read as a "failure" it sends people hunting for a graph bug that is not there; read correctly it is a one-line reduction fix. Run all of these on both a correctly classified and a misclassified input, since some bugs only appear on one branch. ### What it costs Almost nothing, which is why there is no excuse. Twelve coordinates on four inputs is 96 extra forward passes plus one backward — seconds. The run it protects is a full attack sweep: iterative attacks at tens of iterations over hundreds or thousands of examples, plus the engineer-days of triage and write-up that follow. The real cost is the one you avoid: re-doing an engagement after the client's own team reproduces your evaluation and gets a different answer. ### Where this check misleads A passing finite-difference test proves **internal consistency between two surfaces of the same object**. It does not prove that object is the deployed system. All of the following pass the check with flying colours and still produce a worthless number: a wrapper built on last month's checkpoint while the service serves this month's; a full-precision local copy while the endpoint runs a quantised export; a wrapper whose preprocessing chain omits a resize the service performs; and a loss that is internally consistent but is not the objective the attack's threat model assumes. Fidelity to production is a separate check with a separate method — compare clean predictions between the wrapper and the live service on the same inputs — and finite differences will never surface it. The second misread is treating a localised disagreement as proof of a bug. ReLU kinks, clipping boundaries and max-pool ties are genuinely non-smooth points; the two-sided difference straddles a discontinuity and disagrees legitimately. Retest those coordinates at a different step, or on a different input, before concluding anything. ### Where it belongs In the harness, as a test that runs whenever the wrapper, the checkpoint, or the preprocessing changes — not as a one-off. Wrappers rot: somebody adds a resize, somebody swaps a normalisation constant, somebody upgrades the framework and an in-place operation starts breaking the tape. The failure is always silent and always flattering, so the only defence is a check that fails loudly on its own schedule.