# Privacy & retention

Make retention a visible product choice.

Status: Draft operational policy · Final terms required before customer launch

## Data locations
The service design includes account and billing metadata, customer workspace storage, short-lived access credentials and operational audit records. Customer file contents should not enter application logs. Screenshots and session recordings are separate data classes with separate controls.

## Proposed retention boundaries
| Data | Proposed handling |
|---|---|
| Persistent customer workspace | Kept during the paid allocation; explicit export/deletion terms before launch |
| Ephemeral task scratch | Discarded after the task under the selected policy |
| Routine screenshots | No archival by default; authenticated short-lived delivery |
| Opt-in recordings and backups | A published duration and deletion controls |
| Billing/security metadata | Minimum documented business/legal period; no file contents |
| Evidence under a valid preservation hold | Restricted access and a documented release process |

## Tenant controls
Customers should be able to see selected storage mode, used quota, backup scope and deletion state. “Deletion requested” and “cleanup verified” are different statuses. Deleted data must not silently return when an old backup is restored.

## Launch requirements
Publish the legal operator, support and abuse contacts, processing locations, subprocessors, retention durations and rights-request process before accepting customer data. This page is a product-policy draft, not an assertion of certification or a completed legal privacy notice.