How does the number of training records behind a class change what score-driven reconstruction exposes?

## The axis that decides everything An adversary with query access who maximizes a classifier's score for a chosen class recovers a prototype: the model's own idea of that class. The interesting question is not whether they can do it but **how specific the result is**, and that is set by one quantity — how many training records were pooled into the class. Think of it as a continuum rather than a threshold: | Records behind the class | What the best-scoring input is | |---|---| | Thousands | An average that matches no individual; low disclosure | | Dozens | A recognisable class type, individuals still blurred | | A handful | Close to a member; subgroup-level disclosure | | One | That record, up to what the model retained of it | The attack machinery is identical across every row. What changed is what the average of the class *is*. ## Why this is a per-class property, not a per-model one This is the part candidates miss. Model-level statistics are the wrong unit. A wafer-map defect classifier at a foundry may be fitted on two million inspection maps across forty defect signatures — and still have three classes that exist because one customer's process recipe produces a signature nobody else produces, with a dozen examples each. Those three classes carry a prototype that is that customer's proprietary signature. The other thirty-seven carry nothing anyone would care about. So the audit is a histogram, not a headline: sort the classes by membership count and look at the tail. And the tail **grows over time** — every new narrow class added for finer triage lands there, thin, before it accumulates examples. ## The design that creates the exposure A class becomes disclosive when the labelling scheme makes it nearly co-extensive with one subject. The recognisable dangerous patterns are the same shape everywhere: - one class per person (an identity-style label space), - one class per customer, tenant or account, - one class per device, serial number or site, - a rare-condition class that only a few subjects instantiate. None of those are attacks. They are ordinary product decisions made for triage granularity, personalization or reporting, and they are what converts a harmless prototype into somebody's data. ## What does not change with class size The adversary's cost barely moves. Their limit is optimisation steps and restarts against the returned score surface, and a three-member class is not measurably harder to hill-climb toward than a three-thousand-member one — arguably it is easier, because a sharper class has a sharper score peak. That asymmetry is why this risk cannot be managed by making the attack expensive: the same effort buys an anonymous average in one class and a proprietary signature in another. The variable is on the defender's side of the ledger. ## What follows for a reviewer Three questions settle almost every case: 1. **How many records are behind the smallest classes, and what does membership in those classes mean about a subject?** A three-member class of a public defect type is uninteresting; a three-member class that exists because of one customer's recipe is not. 2. **Is the class label itself the sensitive fact?** Sometimes the reconstruction is beside the point and the mere existence of a per-customer class in a shared console is the disclosure. 3. **Does the coarser labelling that removes the exposure cost the product something real?** Usually yes — that is why the thin classes were created — and that trade is a decision, not a finding. A related caution on the reporting side: because a small class's average is close to its members, a reconstruction from a thin class will *look* convincing, and that appearance is not by itself evidence that a specific record was recovered. The class-size argument tells you where to look; it does not substitute for a baseline comparison when you write the finding up.