Documento legal
Offboarding and data export
Última atualização: . Escrito em inglês.
Adapted from the Basecamp open-source policies (https://github.com/basecamp/policies, commit 05fb1f9ddaaf604fc5816990fa66f3ffd7f0a462) / CC BY 4.0. Source file: until-the-end-of-the-internet/index.md. See Changes from the template.
Services disappear, and clinics change suppliers. Your clinic's data should not be stuck with us when either happens. This page says what you can take with you, what we delete, where, and how long it takes.
True today, and what applies to real clinics
No clinic has left, because no real clinic has joined. Customer call-download controls and endpoints have been removed. The on-request data provision described below and full clinic offboarding are manual processes and have not been run end to end. Where a step is missing or unverified, this page says so.
Our promise, sized to a proof of concept
We do not promise to run the Service forever. We promise that:
- you can export your call data while your account is open and during the offboarding period
- when you leave, we delete your clinic's data at every provider and send you a written confirmation
- if we stop the Service, we give every clinic [SHUTDOWN NOTICE] notice and the same export and deletion (open item L17)
- if the business is sold, we tell you before your data moves, and the new owner must keep this page's commitments or let you leave with your data
What you can export
| Data | Format | Where | Status |
|---|---|---|---|
| Call list | On request; format agreed for the request | Assisted data request | No customer dashboard download; manual provision remains unverified |
| One call's transcript | On request; format agreed for the request | Assisted data request | In-app reading remains; no customer transcript download |
| Clinic call recordings | Dashboard playback; no download/export action | Private Supabase Storage, recorded by LiveKit Egress | Playback is available to an authorized clinic member for a valid recording. The dashboard has no recording download/export action |
| Bookings | Cal.com's own export, or on request from us | Your Cal.com calendars | No export in our dashboard |
| Messages and change requests | On request | Our database | No export in our dashboard |
| Clinic knowledge versions | On request | Our database | No export in our dashboard |
The dashboard has no call-list, transcript or recording download feature. Authorized clinic members can read retained transcripts and play an available patient-call recording in its detail. Assisted data requests remain separate from dashboard features and must contain only the clinic's data, without provider keys. The current source keeps patient call records and recordings for 6 months and then deletes them. A recording the caller refused is deleted at once. This is built in the source, not yet observed in Production: cleanup and physical deletion have not been verified (open item L25).
What is kept where, and for how long
| Data | Where | Kept for | Source |
|---|---|---|---|
| Current call records and transcripts | Supabase database | 6 months after the call, then deleted by a daily job. Built in the source, not yet observed in Production: row deletion and read-back are unverified (L25) | Clinic voice runtime; src/features/calls/livekit-settlement.ts |
| Current patient-call audio | Private Supabase Storage, captured by LiveKit Egress | 6 months after the call, then deleted. A recording the caller refused is deleted at once. Dashboard playback is available while the recording is valid. Built in the source, not yet observed in Production: physical deletion and read-back are unverified (L25) | Clinic voice runtime; src/features/calls/recording-maintenance.ts |
| Historical call records and recordings, if any | ElevenLabs | Former-runtime artifacts are separate from current calls. The prior per-agent 30-day setting was read back; deletion of individual artifacts and any remaining copies are unverified (L25) | ADR 0026; docs/providers/elevenlabs.md, "Live findings" |
| Messages (recados), booking intents and changes, appointment requests | Our database (Supabase) | 12 months (for a booking, 12 months after the slot), then deleted by a daily job. Built in the source, not yet observed in Production (L25) | DPA section 9; src/shared/retention.ts |
| Clinic knowledge, notification settings, message opt-outs | Our database (Supabase) | While the clinic exists | DPA section 9 |
| Notification outbox, SMS send reservations, rehearsal results, call metadata, voice session content, call receipts | Our database (Supabase) | 6 months, then deleted by a daily job. Built in the source, not yet observed in Production (L25) | src/shared/retention.ts |
| Invitations | Our database (Supabase) | The plain address is cleared 7 days after the invitation expires. The row is deleted 12 months after it ends | src/shared/retention.ts |
| Membership audit log and operator audit log | Our database (Supabase) | 12 months, then deleted. The logs hold user ids and masked addresses | src/shared/retention.ts |
| AI usage ledger | Our database (Supabase) | 24 months, then deleted | src/shared/retention.ts |
| Billing usage ledger | Our database (Supabase) | The tax period our accountant confirms. No deletion job | none |
| Bookings | Cal.com | Until deleted. What Cal.com keeps after deletion is unverified | docs/providers/calcom.md |
| Call detail records | Telnyx | Unverified | docs/providers/telnyx.md section 7 |
| Redacted telemetry | Better Stack | Logs and traces 3 days, errors 90 days, on the free plan | docs/providers/betterstack.md section 4 |
| Request logs | Vercel | Unverified | none |
| Database backups | Supabase | [BACKUP RETENTION DAYS] (L16) | none |
What the source code actually deletes for each kind of data, and what it never deletes, is listed in retention as built. The periods above are the owner's decision of 3 November 2026: every real record is kept at least 6 months. They are built in the source and not yet observed in Production.
What happens when you leave
The steps follow the offboarding section of onboarding-offboarding-checklist.md. The checklist is the operator's working copy. This page is what we commit to the clinic.
- Request. The clinic owner asks in writing. We confirm the request with the owner before we act.
- Stop new AI calls. Confirm the clinic's ordinary reception route is available and that the change will not create a forwarding loop. Stop new AI admissions and record the effective offboarding time. Already-admitted calls finish within their existing limit. Expiry alone does not delete appointments, data or dashboard/export access.
- Export. We send the exports above, plus messages, change requests and knowledge versions on request, as a download. The download is available for [EXPORT WINDOW DAYS] days (L17).
- Phone number. A clinic has no assistant number of its own, so there is nothing to hold or release. Every clinic forwards its own public number to the one shared assistant number. The clinic removes that forwarding at its operator once its ordinary reception route works, and we confirm it before we call the offboarding complete. Porting the clinic's own public number stays with its operator and the provider's applicable rules.
- Delete at the providers:
- LiveKit. End any remaining clinic sessions and Egress activity. The shared inbound trunk and dispatch rule serve every clinic, so one clinic's offboarding does not retire them.
- Telnyx. The shared assistant number, its connection and the outbound profile serve every clinic, so none is released for one clinic's offboarding. Remove a connection or outbound profile only after proving no other clinic or retained service uses it.
- Cal.com. Close or hand over the practitioner accounts, remove webhooks and revoke API keys. The clinic decides whether its calendars and bookings move to its own Cal.com account or are deleted.
- Supabase. Delete the clinic's operational clinic and patient-data rows, except legal and append-only audit records retained under their applicable rules; delete its private recording objects and staff accounts that belong to no other clinic. A row expiry or revoked playback access is not proof that the audio object was physically deleted.
- Historical ElevenLabs artifacts. If the clinic has conversations from the former runtime, delete the matching conversations and confirm transcript and audio removal. Delete legacy knowledge documents, agents or phone entries only when they are clinic-specific and no longer shared.
- Better Stack. No action. Events carry ids, not patient content, and expire on the schedule above.
- Rotate shared keys that the clinic's staff could have seen.
- Check. A query for the clinic's id returns no rows in operational clinic and patient-data tables. Explicitly retained legal records and append-only audit rows are accounted for separately under their applicable retention rules. No related LiveKit session or Egress remains, and a scoped Supabase Storage inventory shows no clinic recording objects or multipart uploads. For historical calls from the former runtime, also confirm no matching ElevenLabs conversations remain.
- Confirm. We send a written deletion confirmation within [DELETION DAYS] days (L17), saying what was deleted, where, when and by whom, and how long backups keep copies.
- Keep only what the law requires. We keep billing records for the period tax law requires, and the deletion confirmation.
Known gaps
- Current call records and patient recordings are kept 6 months in the source. Source maintenance includes a LiveKit-session route, but its production invocation and removal read-back for call rows, transcripts, Egress and Supabase Storage objects have not been verified (L25).
- The former ElevenLabs cleanup path applies only to historical conversations. Provider-side removal of a transcript and recording has not been verified on a real conversation (L25).
- Full clinic offboarding remains a manual process and has not been run end to end.
- Backup retention at Supabase is unknown (L16).
- Recordings can be played in the dashboard by an authorized clinic member while valid; the dashboard has no recording download/export action today.
Changes and questions
We tell clinics about changes to this page as described in Policy updates. Questions go to support@transversal.io (open item L3: the address is set).
Changes from the template
- Replaced the promise to support products "until the end of the Internet" with smaller promises a proof of concept can keep: export, deletion with confirmation, notice before shutdown, and protection on a sale.
- Removed the legacy product history and the "life's work" text.
- Added the export table, the retention table per provider and the offboarding steps, mapped to our operations checklist.
- Added a known gaps section.
- Updated implementation facts after removal of customer call downloads; assisted data-request and offboarding commitments remain separate from dashboard features.
- Kept the template's rule that we tell clients about significant changes, now through our policy updates page.
Adaptado das políticas open source da Basecamp, sob licença CC BY 4.0. Cada documento indica as alterações que fizemos.