Privacy, in plain language.

Information Diravia handles

• Your email address and authentication session, processed through Supabase Auth.
• The Plays, targets, signals, outcomes, and lessons you choose to enter.
• Limited operational metadata such as request outcome, duration, release identifier, and error category.
• When you deliberately request AI analysis, the selected signal and a bounded summary of its relevant Play context.

Where workspace data is kept

The browser keeps a local workspace copy so the product can recover from temporary network problems. Signed-in workspaces are stored in private, per-user cloud records. During Diravia's staged storage migration, the authoritative record may be in Vercel Blob or Supabase Postgres, and a legacy or rollback copy may temporarily be kept in the other service. That secondary copy is checked for migration safety but may lag after Postgres becomes authoritative. Signing out does not automatically clear the browser copy; use the workspace data controls before leaving a shared device.

Optional AI analysis

AI analysis is off unless Diravia enables the feature and you request it for a signal. Diravia sends only bounded relevant context to OpenAI, requests no model tools, and uses store: false. That setting prevents stateful Responses API storage, but is not a promise of Zero Data Retention. Do not enter secrets or unnecessary personal information in analysis text.

How information is used and shared

Diravia uses information to authenticate you, save and synchronize your workspace, provide requested analysis, prevent abuse, and diagnose service failures. It is shared only with infrastructure providers needed for those functions. Diravia does not sell workspace data or use it for advertising.

Retention and your choices

Workspace controls can clear only the current workspace. The signed-in account menu also provides self-service account deletion. After you confirm the signed-in email address and verify a fresh one-time code, Diravia records a private deletion marker that locks workspace changes, hard-deletes the Supabase identity, and then removes active Supabase and legacy Blob workspace records plus account-linked abuse counters. A daily cleanup retries any incomplete removal and keeps only minimal path metadata until it verifies that those active objects are absent and pre-deletion requests have drained. Account-scoped device recovery copies are cleared by that browser after the server confirms deletion; an unassigned legacy browser copy may remain until that browser safely attributes or clears it. Network-only abuse counters cannot identify an account. They enter the deletion queue after 24 hours, and the daily sweep targets removal by 48 hours while emitting a failing operational signal if that target is missed. Infrastructure backup copies may remain for each provider's limited disaster-recovery period before expiring.

Requesting a first email code may provision an unconfirmed Supabase identity before sign-in finishes. Diravia removes an abandoned identity only after it has remained unconfirmed and unused for at least 30 days. The cleanup excludes any identity with a confirmation, sign-in, invitation, phone, SSO, MFA, session, refresh token, linked provider, custom account metadata, or application workspace state, and rechecks those protections atomically when it deletes.

If self-service deletion cannot complete, contact jqh64@yahoo.com or use the recovery guidance on the status page.

Security and changes

Diravia uses authenticated per-user storage, bounded validation, encrypted transport, and conflict-aware writes. No service can promise perfect security. Material changes to this notice will be dated here before they take effect.