Differentially private training needs accounting lineage across runs

Differentially private training needs accounting lineage across runs. An epsilon reported at the end of one successful job is not a durable privacy claim when the same population has already passed through aborted experiments, resumed checkpoints, hyperparameter searches, and later fine-tunes. The guarantee composes across access, not across whichever run produced the model we kept.

DP-SGD creates the core mechanism by clipping per-sample gradients and adding Gaussian noise. The privacy accountant turns the sampling rate, noise multiplier, step count, and delta into a cumulative bound. That calculation is meaningful only if its inputs are tied to the actual training history. If an operator restarts from a checkpoint but resets the accountant, the model state carries earlier learning while the ledger pretends the spend began again.

I therefore treat the accountant state as part of the checkpoint contract. A resumable artifact should include the model and optimizer state, accountant mechanism and version, clipping policy, noise schedule, sampling scheme, completed steps, dataset identity, and protected population definition. Restoring one without the others is not recovery. It is a fork in the privacy claim.

Dataset lineage is equally important because composition follows people and records, not job names. Two fine-tunes over overlapping snapshots may spend against the same protected population even when they run in separate projects. Poisson subsampling can amplify privacy, but its benefit depends on the actual sampling procedure. Virtual batches, gradient accumulation, and distributed execution must preserve the intended effective batch and sampling semantics; configuration drift can change the accountant’s inputs without changing the training code’s headline algorithm.

The run ledger should record every attempt that touched protected data, including failures whose outputs were discarded. It should link the source snapshot and consent scope to the clipping norm, adaptive-clipping behavior, optimizer, trainable parameter set, seed policy, and emitted artifacts. DP-LoRA may reduce the number of trainable parameters and make private fine-tuning practical, but it does not create a separate privacy universe. The spend still belongs to the people represented in the data.

This lineage changes release governance. A model card can state a privacy budget only by referencing the ledger that authorized it. Retraining, merging adapters, publishing checkpoints, or deriving another model should preserve that parentage. Privacy budgets belong in data-product contracts; the training ledger is how a model release proves which part of that contract it consumed. Data rights must travel through lineage for the same reason: downstream artifacts inherit obligations from their inputs.

Empirical privacy auditing belongs beside, not instead of, formal accounting. Membership-inference methods can expose implementation errors and establish lower bounds on leakage. They cannot retroactively reconstruct an incomplete run history or replace the upper-bound guarantee provided by a correctly implemented mechanism. I want both records linked to the release: formal spend and empirical challenge evidence.

There is one precise concession: independent training over provably disjoint populations can be accounted separately. That boundary must be demonstrated through stable population identity and lineage, not inferred from separate files, teams, or cloud jobs. If overlap is unknown, separate ledgers are an organizational convenience rather than a privacy argument.

The operational rule is simple: no private-data run starts without a budget allocation, no checkpoint omits accountant state, and no model ships without a composable path back through every attempt that spent privacy. Differential privacy is mathematical, but maintaining its promise is data engineering—identity, lineage, versioning, and recovery applied to the training process itself.