← Docs

1 min read

Documentation
On this page
  1. Consent, and the training switch
  2. GDPR: erasure

Consent and erasure

You are the data controller. We ship software in a processor-like pattern; we do not know your users, their jurisdiction, or your UX, so we cannot own your consent flow.

What we give you is a switch, so doing the right thing is one line:

curl -s localhost:8080/participation -X PUT \
  -H 'Content-Type: application/json' -d '{"participating": false}'

An opted-out client still serves predictions. It just sits out training rounds, and it stops counting toward the minimum-clients gate.

GDPR: erasure

The ingest buffer is your data, on your machine. The platform never sees its contents. Deletion duties are yours; the tooling is ours.

# one data subject's records
curl -s "localhost:8080/ingest?subject_id=user-123" -X DELETE
# {"deleted": 4}

# everything
curl -s localhost:8080/ingest -X DELETE

Two things to be clear about, because they are easy to get wrong:

  1. Tagging is what makes targeted erasure possible. Records ingested without a subject_id can only be removed by a full wipe, or by ageing out of the retention window.
  2. Erasure covers stored records. Data already consumed by a past training round persists only as model weights — the standard federated-learning story. If that matters for your DPIA, say so before you train.

Uninstall wipes everything: docker compose down -v removes the volumes, including the buffer and its encryption key.