How we handle your data

Controls in place today

• Client-side processing and PII minimization. CSV and POS input is parsed in the browser. Recognized identifying columns are removed; column statistics, computed cohort counts and sanitized sample rows are sent for analysis. The original file is not uploaded. Heuristic redaction may miss identifiers in unfamiliar columns or free text; review inputs before analysis.
• Anonymous-first identity. The platform is fully usable with no account. An anonymous session identifier, not a person, is the default unit of record; signing in is optional and exists only so you can retrieve your own saved work.
• Tenant isolation at the database layer. Schema scripts enable row-level security. Server-side service-role requests bypass RLS, so account routes also scope their queries to the authenticated user.
• Least-privilege service credentials. Privileged keys exist only server-side and are never exposed to the browser; the client holds only a public, restricted key.
• Rate limiting and abuse control. Generation and segmentation apply in-memory limits when a session identifier is supplied. The public benchmark API has a separate limit. These controls are not a comprehensive abuse-prevention guarantee.
• Transparent disclosure. The interface states in plain language, at the point of upload, exactly what is processed locally, what is transmitted, and what is retained.
• No training on your data. We do not run a training or fine-tuning pipeline on uploads. Analysis is sent to configured third-party inference services; their handling is governed by applicable service terms and account settings.
• Data export and deletion. Export covers your profile, linked sessions, campaigns and segments. Deletion removes these records but does not delete the authentication account or promise erasure of every log or backup.