What the platform sees — and structurally cannot

The platform sees model weights, training metrics, and per-site health (connected, serving version, schema validation results). It does not see rows of data, and it cannot identify your sites: every installation gets a random identifier, and the mapping to real locations exists only on your side. This is a structural property, not a policy — there is nothing on the platform to subpoena, leak, or misuse that resolves a site identity.

Can

Your model's weights; anonymous per-round metrics; a random client id per installation; how many records a client validated and which declared column names failed (never a value); byte counts for metering.

Cannot

Your records; who your users are; which installation a client id corresponds to. The client id is random and carries nothing identifying, and it is stored that way — we structurally cannot de-anonymize it. If you need to map #a3f9 back to a machine, that mapping is yours to keep.

Model IP, plainly

Your model's weights live on every client. That is how federated learning works. Treat the architecture and weights as shippable IP, like any code you distribute. We do not pretend otherwise.

The honest consequences of this design: we cannot tell you which site is misbehaving beyond its random id, model weights land on every enrolled site because that is what federated learning is, and erasure covers stored records but not weights already trained on.