Data and privacy
What data the platform holds, how products are kept apart, and how you export, retain and delete it.
This page describes what data the platform holds, how it is kept apart between products, and what you can do with it — export it, delete it, and answer a request from one of your own users.
What data the platform holds
Two different populations, kept apart:
- Your team. The people who work in your organization: their accounts, their membership and role in the organization and in each product, and their sign-in sessions.
- Your end users. The people who use the product you build: their accounts in your product’s own user directory, their identifiers, the metadata you attach to them, waitlist signups, consent decisions, and visitor profiles with their event history.
Alongside those, the platform keeps operational records: logs of the requests your product makes, records of automated runs, and audit records of who did what.
Data classes
Every piece of data falls into one of three classes, and the class is what the platform’s egress rules are decided on:
| Class | Definition |
|---|---|
| PII | Personal data — email, phone, address, names tied to identifiers. |
| Sensitive | Commercially sensitive data — finance, contracts, internal documents. |
| Non-PII | Data without personal identifiers. |
Sending PII to a language model is denied by default. Where it is allowed, it requires an approval and the data is redacted first.
Separation between products
The product is the hard data boundary. Nothing crosses it implicitly.
- Every read, update and delete is filtered by the product it belongs to.
- A request for a resource that belongs to another product returns 404, not 403 — the difference would itself reveal that the resource exists.
- The product is taken from the validated request context. A product identifier sent by a client is never trusted on its own.
- Analytics queries are rewritten server-side to read only your product’s rows, so a generated query cannot widen its own scope.
- Being an owner or admin of the organization does not create a hidden path across products. Access to a product is always a concrete membership row on that product.
A product’s region is chosen when the product is created and cannot be changed afterwards. To run in a different region, create another product. The default posture is EU-first: compute is region-aware.
Protection
- Encrypted at rest with AES-256.
- Encrypted in transit with TLS 1.3 everywhere.
- Access to stored data is constrained at the database layer as well as at the application layer, so a product boundary is enforced in more than one place.
- Actions in the system produce audit records: who did what, and when.
Retention
This is the full retention table. No other period applies.
| Data type | Retention | Deletion |
|---|---|---|
| User data (PII) | Until a deletion request | 30 days after the request |
| Operational logs | 90 days | Automatic purge |
| AI request logs | 90 days | Automatic purge |
| Automated run logs | 30 days | Automatic purge |
| Audit records | 2 years | Automatic purge |
| Backups | 30 days | Automatic purge |
How a run is classified: if it calls a language model, its prompt and response are classified as AI request logs and kept for 90 days. If it runs without any model call — a schedule or an automation — it is classified as an automated run log and kept for 30 days. Stored conversation archives contain model dialogue and are classified as AI request logs.
Audit records are the one exception to erasure. They are kept for the full two years even after a deletion request, and they are not anonymized. The legal basis is GDPR Art. 17(3)(e): they are evidence for establishing, exercising and defending legal claims, and they are required for incident investigation and compliance audits. They contain a user id, an action and a timestamp — not personal content. Personal data itself is still deleted within 30 days. Audit records are internal today and are not exposed as a surface you browse.
Exporting data
- Your organization’s data. Export is self-service, in Settings.
- Your end users. Export the product’s user directory as pages of full records — profile, identifiers and metadata. Password hashes are never included, neither the platform’s own nor one imported from elsewhere. Every export is audited, with the filter used and the number of rows, so it is not a silent read. Use it for migrations, backups and subject-access requests.
- A single visitor’s journey. Export one profile as JSON: the profile, its identity signals and its full event history. The history is capped at 50,000 events; beyond that the export is flagged as truncated.
- Consent records. Export the product’s consent decisions as CSV. For an Art. 15 access request, filter the export by the record id from the visitor’s consent cookie to get that one visitor’s full decision chain.
Deleting data
Deletion comes in two strengths. Choose deliberately — one is reversible and one is not.
Soft delete keeps the record and marks it deleted. It disappears from default listings, and it can still be fetched by id. Nothing is purged. This is not erasure and does not satisfy a right-to-erasure request.
Erasure is permanent and irreversible:
- For an end user, the identifiers and identity rows are deleted, the profile fields are nulled and the metadata is emptied. What survives is a tombstone — the id and the time of erasure — so that anything still holding that id resolves instead of breaking. An event is emitted so that other consumers purge their own copies. The email address is freed: registering it again creates a new user with a new id. The operation is idempotent. The audit trail is kept but pseudonymized — a security log that erasure can rewrite would not be a security log.
- For a waitlist signup, the entry with its attribution and consent proof is deleted and the directory row is erased; the id survives as a tombstone, the personal data does not. Erasure by email is available as well: it hard-deletes the signup and its invite tokens, replaces the raw email in the consent ledger with a keyed hash, and adds the address to the do-not-contact suppression list. Routine cleanup of stale pending entries happens on its own through the retention sweep.
- For a visitor profile, the person and their events are permanently deleted and the erasure request is recorded. Events that have already been archived are flagged as a deletion gap rather than silently left behind.
Deletion of personal data completes within 30 days of the request, and the cleanup is automatic.
Consent
Consent is collected from your visitors through a cookie banner and the acceptance of your privacy policy. Each decision is stored as a record, and a later decision links back to the one it replaces, so a visitor’s full decision chain can be reconstructed. Records can be exported for a product-wide review or narrowed to one visitor for an access request.
Incident response
If data is exposed, the process is: detection, triage, containment, investigation, resolution, a post-mortem within 48 hours, and — in the case of a data breach — notification to affected customers.
Next steps
- Add a cookie consent banner: collect the consent decisions this page describes.
- Ask questions about your product’s data: the query path that the product boundary rewrites.
- Review who can reach a product: access is always a concrete membership row.