A shared detector's model card lists a clip norm and noise multiplier — what do you check before telling contributors their records are bounded?

## The chair you are sitting in Several organisations pooled connection-flow records to train a shared intrusion detector, and the weights are about to go out to every member. Any member who receives them holds the parameters and the published configuration, and one of them may want to know whether a particular flow — from a particular contributor's network — was in the training data. Your job is to say what the published configuration actually buys those contributors before you let anyone tell them their records are bounded. ## Check one: what was the clip applied to This is the line that decides whether there is anything to discuss. Two operations share the word *clipping*: - **Global norm over the summed mini-batch gradient.** A stability control. It caps the size of the step. One influential record can still be most of what is inside that cap, so it bounds nothing about a single contributed flow. - **Per-example clipping.** Each example's own gradient is measured and rescaled to a fixed bound *before* the examples are summed, so the presence or absence of any one record changes the summed update by at most that bound. Only the second is the sensitivity bound the rest of the argument rests on, and the distinction is invisible if you only read the number. A card that says "gradients clipped to 1.0" has told you a number and not an operation. Ask which vector. The direction of this check matters: an absent per-record clip is not a weakness to be compensated for elsewhere. Sensitivity is either bounded or it is not, and no amount of noise or accounting downstream creates a bound that the training step never imposed. ## Check two: what the noise is relative to, and where it went A noise standard deviation quoted on its own is not interpretable. The privacy-relevant quantity is its size **relative to the clip bound**, so you want the multiplier, or both numbers with an explicit statement of which is which. Then confirm placement: the noise must be added to the aggregated clipped gradients inside each training step. Noise applied to the model's predictions, or once to the final weights, is a different construction and does not stand in for it — and against a member who holds the weights, output perturbation is not even in the path. ## Check three: does the accounting's premise match the run Privacy accounting for this kind of training normally assumes a specific sampling scheme for forming batches, and it derives part of its strength from the fact that any given record participates only in a small random fraction of steps. If the run actually used fixed shuffled epochs while the reported figure was computed under a sampling assumption, the premise of the accounting does not hold and the reported number is not the number for this run. This is a question about whether the arithmetic describes the pipeline, not a question about what the reported parameter means once it is correct — that is a separate conversation. ## Check four: the cost tells you whether it happened The cheapest verification is not in the document. Per-example gradients are a quantity ordinary training deliberately never materialises, and computing them costs additional time and memory over a comparable non-private run. If the training logs show a run whose step time and memory footprint look like the standard pipeline, that is meaningful evidence the per-example operation was never performed, whatever the card says. Ask for the two runs side by side. ## What you can honestly tell contributors If the checks pass, the statement is narrow and worth making: the training procedure limited how much any single contributed record could change the released weights, and added randomness calibrated to that limit, so a member holding the weights gains only a bounded amount toward deciding whether a given record was included — and this holds against attacks that have not been published, because the bound is over records and not over attack strategies. If the clipping line turns out to be the batch-level kind, say so plainly and do not soften it: the run has a stability control and some added noise, and no record-level claim can be made. Two further questions then remain open regardless — what unit the bound is stated over, when one contributor supplied many flows, and what the reported parameter itself promises. Both are worth asking, but neither is worth asking until the first check has passed. ## The failure mode this catches The common path to a false claim is not dishonesty. It is a team that had global-norm clipping in their loop already for convergence reasons, added noise because the mechanism they read about mentioned noise, and reported a figure from a library that assumed the per-example operation had been performed. Every individual step looks familiar; the composition is not the mechanism. Reading the clipping line as an *operation* rather than a *number* is what separates a reviewer who can sign the claim from one who is repeating it.