An adversarial-robustness toolkit's attack classes are written for a particular input data type. What goes wrong when you point an image-oriented gradient attack class at a tabular fraud model whose features include one-hot encoded categoricals, integer counts and an account-age field the customer cannot change?

### Why nothing errors Access level fails loudly: a gradient class refused a label-only endpoint. The **data type** assumption fails silently, because a tabular row and an image batch are both float arrays. The wrapper accepts the array, the class steps it, the model returns a different label, and the toolkit reports a success rate. Every component behaved correctly. The only broken thing is the meaning of the output. ### The four assumptions an image-oriented class carries 1. **Continuity** — any coordinate can move by an arbitrarily small amount. A pixel can go from 0.412 to 0.417. A transaction count cannot go from 3 to 3.47. 2. **Independence** — coordinates move separately. A one-hot block is a *mutual* constraint: exactly one column is 1 and the rest are 0. A gradient step nudges all of them, and the block stops encoding any category. Derived columns (a total and its parts) are similarly linked. 3. **Uniform mutability** — every coordinate belongs to the attacker. In a fraud model, `amount` might; `acct_age_days`, tenure, KYC-verified attributes and anything the bank computes server-side do not. The attacker cannot age their account backwards. 4. **A meaningful norm** — small distance means imperceptible. On an image this is roughly true. Across mixed-unit standardised columns it is not: an L-infinity step of 0.1 in scaled space might be a few pence on `amount` and a whole extra dependant on a count column, and there is no perceptual system to be fooled anyway. "Imperceptible" is not even the right goal — the goal is "a change the attacker can actually make, cheaply". ### What the run costs, and what it costs you later The compute is trivial; that is part of the trap. A few hundred tabular rows through an iterative gradient class is seconds of CPU, so nobody feels a reason to think first. The real cost lands downstream: an engineer-day or two of triage on findings that turn out to be unsubmittable rows, a meeting with the fraud domain owner to discover that half the perturbed columns are server-computed, and — the expensive one — a remediation programme aimed at a threat that does not exist, because the client hardened a feature no customer controls. Defining the action space up front is typically a couple of hours with the domain owner. It is the cheapest step in the whole exercise and the one most often skipped. ### Where the number misleads The reported attack success rate has an inflated numerator. It counts every flip, including flips produced by rows that the production input path would reject outright (schema validation, range checks, integer types, categorical enums) or — worse — **silently coerce**. Coercion is the subtle case: the pipeline rounds 3.47 to 3 and argmaxes the smeared one-hot back to a single category, which destroys the exact perturbation that flipped the label. The tool's number says 82%; the number an attacker could reproduce through the real intake may be near zero, and nothing in the output distinguishes the two. The perturbation size is misleading in the same way. Reported as an L2 or L-infinity distance in standardised space, it is uninterpretable to the person who has to fix anything. "Norm 0.31" tells a fraud lead nothing; "split the payment into two transfers and declare income 4% higher" tells them everything, including whether their existing controls already catch it. ### Doing it properly, and the residual failure - **Enumerate the action space** with the domain owner: which columns are mutable, in which direction, in what step size, under what joint constraints, and what each unit of change costs the attacker. - **Constrain the search** to that space — a feature mask over immutable columns, an explicit projection back onto the feasible set after each step (round integers, re-argmax one-hot blocks, clip ranges, re-derive dependent columns), or a class built for discrete/constrained domains. - **Re-evaluate the projected row**, not the pre-projection candidate. The flip must survive projection or it is not a flip. - **Revalidate through the production input path.** A candidate that fails the real validator is not a finding. - **Report in domain units** the client can act on. Text is the identical problem in different costume: adding epsilon to an embedding yields a vector with no corresponding string, which is why text-oriented tooling such as TextAttack works through word- and character-level transformations under explicit constraints, so every candidate is a real input the target could receive. Even after all this, a masked and projected row can be **legal but implausible** — a combination no real customer generates, which downstream monitoring would flag on its own. The toolkit has no opinion about plausibility; only the domain owner can rule on it, and that judgement belongs in the finding.