Federated learning needs participant provenance before averaging

I would make participant provenance a condition of admission to a federated training round, not paperwork attached to the finished model. Keeping raw data inside each institution changes where learning happens — it does not establish whose updates deserve influence. Before averaging, I want an answer to a more basic question: which participants contributed, under which training agreement, from which model state, and with what basis for their assigned weight?

FedAvg makes this dependency visible. Its weighted aggregation gives clients influence according to their local sample counts. That arithmetic assumes the counts describe comparable contributions to the intended objective. A hospital with a different label definition or a client running an obsolete training configuration can produce a structurally valid update that means something different. I read the federated-learning literature’s emphasis on non-identically distributed data as a reason to preserve context, not erase it at the aggregation boundary.

My proposed admission record would bind an eligible participant to the round, starting checkpoint, training configuration, update format, and declared weighting basis. For institutional federation, it would also identify the party responsible for those declarations. This is an application of data contracts as interface discipline: compatibility should be checked before a contribution affects a shared artifact. A signed declaration establishes who asserted something; validating its substance requires separate evidence.

Participation history belongs beside that record. Client selection, partial participation, and dropout determine which local distributions actually reach the server. Asynchronous training adds another question: how old was the model from which an arriving update was computed? I would retain the selection policy, accepted cohort, exclusion reasons, and staleness decision for each round. Otherwise, a change in model behavior may be attributed to optimization when the contributing population changed underneath it.

Privacy makes the boundary more deliberate. The hub distinguishes data isolation from protection against gradient leakage, and secure aggregation from differential privacy. These mechanisms answer different questions. Secure aggregation is designed to reveal the combined update rather than each client’s contribution. I would keep admission evidence separate from protected update contents, with access and retention scoped to the threat model. Provenance should explain participation without becoming a new collection of sensitive training records.

The same separation matters for adversarial behavior. Model poisoning and backdoors make an authenticated participant insufficient evidence of a safe update. Robust aggregation methods address properties of contributions; provenance addresses their origin and eligibility. An architecture cannot casually promise both ordinary server-side inspection of every update and secure aggregation that hides those updates. I would require the defense design to state what it can observe and which attacks its chosen protocol actually addresses.

I would also carry the round record into model lineage. This extends the accountability-chain argument from actions to training contributions: retain enough evidence to identify affected artifacts when a participant is excluded or a training configuration is found defective. Federated unlearning remains a separate technical problem; a contribution record is not proof that influence has been removed. The connection to governance before persistence is practical — lifecycle decisions need origins that survive consolidation.

The precise concession is cross-device learning under a privacy design that deliberately avoids durable participant identities. Requiring an institution-style identity ledger there would defeat the design. In that setting, I would accept protocol-scoped eligibility evidence and cohort-level round provenance rather than a permanent device history, provided the security and privacy claims are explicitly limited to what those records can establish.

That boundary leaves the ordering intact. FedProx, SCAFFOLD, personalization, and communication-efficient updates tackle real optimization and systems problems. I would choose among them only after defining what counts as an admissible contribution and what evidence survives its aggregation. A shared model is the result of a participation process, not just a numerical operation. If that process cannot be explained, averaging has hidden the uncertainty rather than resolved it.