1. Retention principle
Str8n should keep information only for the account, newsroom, security, billing, legal, correction, or audit purpose that justifies it, then delete, de-identify, or restrict it. This draft distinguishes controls that exist in code from schedules that still need production approval.
An expiry field is not the same as verified deletion. Str8n will not promise automatic erasure on a date until a purge job, backup behavior, and provider deletion path are tested end to end.
2. Account and preference records
—
Email, profile, Free or Pro entitlement, preferences, saved dossiers, tags, and notes are designed to remain while the account is active or until the user changes or deletes them.
—
Web authentication tokens are stored in browser local storage; native tokens use the device secure store. Signing out clears the local session through the authentication client, subject to the device or browser succeeding.
—
No separate production inactivity-deletion interval has been approved. A final policy must set one or state why account records remain until user deletion.
3. Lens and conversation records
—
Plaintext cited-conversation questions and answers stay in temporary component state under the current design and are cleared on account, dossier, access, or component lifecycle changes.
—
The signed conversation continuation token has a two-hour expiry and contains bounded prior claims plus account, dossier, source-packet, prompt, model, and question-hash bindings. It is not written to the Str8n database by the current conversation path.
—
Non-conversation analysis capsules are marked to expire 30 days after creation. Current read paths ignore expired rows, but an automatic database purge has not been verified, so this draft does not claim they are deleted at day 30.
—
Lens access logs record the account, dossier revision, timestamp, and cache-hit state for rate limiting. No non-account deletion interval is currently encoded; account deletion is designed to remove these rows.
4. Voice data
Str8n requests microphone and speech-recognition permission only after a user starts voice input. Recording persistence is disabled, and the current app creates no audio file. Interim and final transcript text is bounded to 500 characters, remains editable in temporary app state, and reaches Lens only after the user presses Ask.
The operating system or browser recognition service may process audio online under its own settings and policy. Its provider-side retention is not controlled by Str8n and must be disclosed for the final supported platforms.
5. Billing records
When web billing is enabled, Str8n stores Stripe customer and subscription references, status, reconciliation events, and related timestamps. Stripe separately handles payment and may retain transaction records under its own obligations.
The deletion design blocks a new checkout while deletion owns the account guard, requires supported billing relationships to be cleaned up before local removal, deletes account-linked billing rows, and retains one-way subject digests to stop later billing events from recreating the deleted relationship. Production deployment and race testing are required before this becomes a promise.
6. Newsroom evidence and public dossiers
Newsroom evidence, source receipts, corrections, location receipts, and published dossiers are not account-owned data. Their retention depends on source rights, takedown state, correction history, public-interest use, security, and audit needs. A source removal flag prevents removed material from remaining eligible as current evidence.
Public-source provenance is not permission to retain or republish full content. The production schedule must map each acquisition mode and rights policy to permitted fields, display use, model use, retention, correction, and deletion behavior before broad ingestion is treated as complete.
7. Secure account deletion
The current flow requires a recent interactive sign-in and the exact phrase DELETE MY ACCOUNT. It is designed to stop safely if a checkout, unsupported billing relationship, storage object, or unfinished upload cannot be cleaned up.
The planned launch configuration keeps end-user Storage writes disabled because Str8n has no user-upload feature. Known historical objects and multipart uploads are still cleaned through the Storage API. Supabase documents automatic abort of incomplete multipart uploads after 24 hours; that hosted behavior and the deletion wording must be reverified before uploads are ever enabled.
After provider and storage cleanup, the server design removes account-owned profiles, preferences, saves, Lens access logs, entitlements, account billing rows, and the authentication user. Public newsroom dossiers remain, while account identifiers and private account notes are removed from retained newsroom records.
Deletion from provider backups, infrastructure logs, and disaster-recovery copies has not been documented. The final policy must state any delayed deletion, isolation, legal hold, or restore behavior instead of implying immediate erasure everywhere.
8. Decisions required before launch
—
Set and implement purge schedules for expired AI capsules, rate-limit logs, security logs, support mail, inactive accounts, source material, corrections, and failed billing events.
—
Document production backup frequency, backup expiry, restore controls, hosted authentication logs, and every provider-side deletion or retention rule.
—
Test account deletion against the deployed database, Edge Function, Storage, Stripe test mode, signed-out sessions, concurrent checkout, retries, and provider failure paths.
—
Publish a verified request process at contact@str8shift.com and add any legally required contact address or response timing only after owner and counsel approval.