This guide will help you pick the right privacy mode per environment and understand what Roadie stores, redacts, and retains. Roadie is built so that sensitive prompt and response content need never be stored at all, while the metrics you bill and operate on are always kept. This guide covers choosing a mode, what is retained versus purgeable, and the deletion and export paths for data-subject requests.

​
Choose a privacy mode per environment

The privacy mode governs how much of each request’s content a log retains. It is applied in the metering worker before anything is persisted — so content a mode excludes is never written to storage in the first place. Defaults are safe: a development environment defaults to full (you want to see everything while building), and production defaults to metadata (content is not retained unless you opt in). Override per environment in the dashboard.
Redaction is a best-effort PII pass, not a compliance guarantee. For sensitive production traffic, prefer metadata or none rather than relying on redacted.
A single request may only tighten the resolved mode (via metadata.privacy), never widen it:

​
What is always kept, and for how long

  • The usage record (tokens, cost, status) is kept regardless of mode — it is what metering and billing run on. Privacy governs content, not metrics.
  • Image bytes are never logged in any mode — only the prompt, an [omitted:image] marker, and generation metadata.
  • Per-environment log_retention_days (default 30) ages out old logs automatically.

​
Erase content on request (GDPR-style)

To honor a data-subject deletion request, purge request-log content by request id, end user, or environment through the control plane (). POST /v1/projects/{projectId}/logs/purge takes exactly one selector:
This deletes request logs and their externalized payload objects and returns the deleted count. It is admin-gated (logs.purge) and deliberately never touches usage_records or the billing ledger — those are financial-grade records kept under a separate lawful basis.

​
Deleting an entire organization

An org deletion is a staged purge with a soft window:
  • The deleted org is first suspended and recoverable for 7 days — there is no immediate hard-delete path.
  • After the window, the purge hard-deletes the org’s operational data (keys, provider credentials, limit/quota/budget policies, model aliases, device attestations, end users, request logs, usage rollups, subscriptions, invoices, members, environments, projects).
  • A hard retain-list is kept past the purge under lawful basis: audit_events (the append-only security log), usage_records (the raw metering ground truth), and billable_usage (the billing ledger, retained for years). The organizations row itself is kept as a tombstone, never deleted.
The partition of every tenant table into “purge” versus “retain” is enforced by a completeness test, so a new table can never be silently orphaned by a purge.

​
Export an organization’s data

For a data-portability request, an org owner can enqueue a full export bundle (config, logs, usage):
The export runs asynchronously; poll GET /v1/orgs/{orgId}/exports/{jobId} for status, and the completed job records the bundle manifest’s object key. Export is owner-only (data.export), so it is out of reach of a management key.

Privacy modes

The four modes and how they are resolved.

Observability: logs & usage

What each mode lets you see in a log.

Tenancy & isolation

How data is isolated per org and environment.

Billing & plans

Why usage records are retained separately.