The composed privacy budget for a daily-retrained model runs out next quarter — what do you propose?

## Why this lands on a lead's desk A composed privacy budget running out is not a bug and it is not a capacity problem. It is the arithmetic working correctly: every release about a record adds to what an adversary watching the stream could learn about that record, and a system that retrains on a schedule generates releases forever. Somebody has to decide what promise the organisation is willing to make and what it will pay to keep making it. That decision cannot be delegated to the accounting tool, because the tool has no view on how fresh the model needs to be or who is told the number. ## The levers, and who pays for each | Lever | What it buys | Who absorbs the cost | |---|---|---| | Refresh less often | Fewer releases over the same records | The product: a staler model, worse on anything that shifts quickly | | Shrink the retention window | Old records leave, so new releases stop composing with old ones for them | Model quality on long-horizon patterns and rare behaviour | | Spend more per refresh | Keeps the cadence | Every individual release, which becomes weaker | | Freeze the current model | Costs nothing; serving a release is post-processing | The product entirely, since the model stops improving | | Raise the published total | Keeps everything | Whoever relies on the published number, who must be told | Notice that four of the five are product decisions wearing a privacy costume. That is the point to make in the room: the budget converts a privacy promise into a freshness bill, and only the owner of the product can decide how to pay it. ## The option to refuse, and the one that looks like it The tempting move is to reset the accountant at the start of a new period. It is trivially available, nobody outside notices, and the number goes back to something comfortable. It is also false. The bound exists because an adversary can watch every release; that adversary does not discard last quarter's observations because your fiscal year turned over. A number published after such a reset would describe a system nobody is running. There is a legitimate reset, and knowing the difference is what separates a good answer from a slogan: a budget may honestly restart for records that have genuinely left — deleted from the training corpus and never used again. Then future releases are computed over a disjoint set of records, parallel composition applies for them, and the old ledger describes an old population. This is exactly why shrinking the retention window is a real lever and a calendar boundary is not. ## What you bring to the meeting Make the tradeoff legible rather than technical: - The **composed** pair over the retention lifetime, with the accounting method named and the number of releases it covers, so nobody is reading a per-refresh number by mistake. - A short forecast: at this cadence and this window, here is the total in one quarter and in four. - Two or three concrete packages — for example, weekly refreshes at the current per-release strength, or daily refreshes at a stated weaker one — each with its measured accuracy and its resulting published number. - A clear statement of what the guarantee has never covered, so the owner is not surprised later: it bounds what one record contributes to what is released, and it says nothing about the accuracy cost, which does not land evenly. ## The disclosure question The last part is not technical at all. If the published figure changes, who is told — the customers, the regulator, the internal risk function, the enterprise buyers whose contracts quoted it? A lead should have an answer before the number moves, because the alternative is discovering the answer after somebody else finds the discrepancy. A guarantee that quietly weakens over time while the marketing sentence stays fixed is the failure mode this whole area exists to prevent, and it is an organisational failure rather than a mathematical one. ## The direction of the claim Running out of budget does not mean the model started leaking on a particular Tuesday. It means the strength of the statement you can defend has been declining continuously since the first refresh, and the ledger is the only thing that was tracking it. The response is to choose a sustainable operating point and publish the number that goes with it, not to find an accounting posture that makes the old sentence survive.