A team wants one classifier class per customer recipe; internal users can query it freely. What's your call?

## What is actually being proposed A foundry's inspection console classifies wafer maps by defect signature and shows per-class scores to internal users across customers. The dashboard team wants finer triage: instead of forty generic signatures, a class per customer process recipe. Several of those classes will start life with a handful of examples. This is a good product idea. It is also a privacy decision, and somebody has to own it as one. ## The mechanism, in one paragraph An adversary here needs nothing exotic: query access and the returned per-class scores. Searching for the input a class scores highest recovers that class's prototype — the model's idea of the class. For a large generic class that prototype is an average matching nobody. For a class built from twelve maps belonging to one customer, the average and its members are nearly the same object, so the prototype is that customer's proprietary signature. The label space, not the attack, is what makes those two cases different. ## Why the usual answers do not settle it **"Internal users are trusted."** This changes who, not whether. On a shared console the confidentiality obligation runs between customers; an employee legitimately viewing customer A's dashboard is not thereby authorised to reconstruct customer B's recipe signature. Staff trust does not discharge a contractual duty to a third party. **"We will meter or log the queries."** Useful, and it does not address a design where the disclosive object is a property of the trained function. Metering raises the cost of a search that should not be possible for that user at all. **"We will only return the top class, not scores."** It genuinely raises the bill — the fine-grained signal a search climbs is what you removed — but it is a cost control, not a boundary, and it takes away most of what makes the console useful. Offer it as a trade, never as a fix. **"Nobody would bother."** Perhaps. That is a statement about motivation among competitors sharing a foundry, which is exactly the population with a motive. ## The decision I would actually make Separate the classes into three buckets and decide once, in writing: 1. **Generic signatures with broad membership** — ship, no constraint. Their prototypes are averages. 2. **Narrow classes above a stated membership floor** — ship, with the floor recorded and enforced at class-creation time, and with a note that the floor is a privacy parameter, not a modelling one. 3. **Classes that are effectively one customer** — either fold into a coarser label, or scope their scores to that customer's own tenancy so the console shows them only where the data already belongs. The cost is honest and should be stated: option 3 loses triage granularity precisely where the team wanted it most, and tenancy-scoped scores mean a cross-customer analytics view the product team may have promised somebody. Naming that cost is the point of the decision, not an argument against it. ## What to put in writing - Which class definitions are permitted to be per-subject, and who approved that. - The membership floor for creating a new narrow class, and the fact that it exists for disclosure reasons so a future engineer does not tune it away as a modelling threshold. - A recurring review of the class-membership histogram, because the thin tail grows every time somebody adds a class for better triage — a launch-time check that is never repeated will be wrong within two quarters. - What the console returns, and to whom, as a product contract rather than a configuration detail. ## The framing that wins the room Do not argue that the model is insecure; argue that the label space chooses what the model can be asked to describe, and that this proposal asks it to describe individual customers. That reframes the conversation from "security is blocking a feature" to "which of these classes may exist", which is a decision the product owner can actually make and can be held to.