Code RoomPrivacy guarantee across pipeline
FrontierPrep Room Coding #4978

Privacy guarantee across pipeline

System designDistributed systemsSenior–Staff~80 min

One customer asks a plain question: what does your system guarantee about their data. You have to answer in one sentence, and the sentence has to survive a lawyer reading it next to your architecture diagram.

The pipeline is what shipped, not what you would draw now. A base model you did not train. A fine tune on customer text with a per example privacy guarantee and a stated epsilon. A preference tuning stage over human comparisons, where the humans read real customer text in order to compare. A distillation into a smaller serving model, prompted with sampled production traffic. A retrieval store over the same customer text, which is the product and is not going away. Caches at two layers.

Exactly one of those stages has a formal analysis, and it is at the wrong unit. The guarantee is per example. The customer is a person, with an unknown number of records, spread across stages, and the record count per person is itself sensitive. The remaining stages have no analysis at all.

Rebuilding the pipeline so every stage is a mechanism with a proof is off the table, because the base model and the preference comparisons already exist and cannot be regenerated. Answering with the smallest epsilon in the chain is off the table, since composition does not work that way and your reviewer knows it. So is any sentence implying you do not use customer data, if you do. This is not a request for a per record membership verdict.

Design where the privacy barrier sits in this pipeline, what each stage is permitted to see, and what the system can then honestly emit. Hand in the accounting object, the example to person conversion including your treatment of the unknown record count, what you substitute for the unanalysed stages and what that substitute is worth, an audit producing an empirical lower bound end to end plus the reason such lower bounds stay loose, and the customer sentence itself with a note on what it deliberately does not claim. Ties break toward the weaker sentence you can defend.

What a strong answer looks like

Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.

Clarify9:00 left
Estimate9:00 planned
Design26:30 planned
Deep dive21:30 planned
Failure14:00 planned
0:00
Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.