Privacy Policy
Effective April 6, 2026. This page describes the current CalmCheck product as it exists in this codebase. It explains what data the app collects, where it is stored, who receives it, and what protections are actually implemented today.
Information CalmCheck collects
- Symptom text you type into the check form.
- Context selections such as stressed, poor sleep, and unusual food.
- Generated check results, including verdict, explanation, steps, and safety flags.
- Consent records when the app records that you accepted in-app terms.
- Google account profile data if you sign in: name, email, profile image, and Google account identifier.
- First-party product analytics events such as page views, CTA clicks, sign-in events, reminder opt-ins, and check completions.
- Operational security data for protected routes, including hashed session tokens, hashed IP addresses in audit and rate-limit records, and hashed user-agent values in audit and session records.
What CalmCheck does not collect
The current app code does not ask for contacts, precise location, photos, microphone recordings, ad identifiers, or payment card information. CalmCheck also does not receive your Google password.
How CalmCheck uses your data
- To authenticate your account and keep you signed in using server-side sessions.
- To process symptom checks and return CalmCheck responses.
- To block obvious emergency-pattern inputs before the AI path is used.
- To maintain your check history, Calm Score, export, and delete features if you use an account.
- To measure product usage and funnel performance using first-party analytics events that do not include raw symptom text.
- To defend the service with CSRF checks, rate limiting, and audit logging on sensitive actions.
Where your data goes
- Google receives sign-in data as part of Google Identity Services if you choose Google sign-in.
- OpenAI receives non-emergency symptom-check prompts when live AI is enabled.
- ElevenLabs receives narration text if you choose the optional voice summary feature.
- CalmCheck's database and hosting providers receive the data needed to run the product and store account-backed history.
- First-party analytics events are stored in CalmCheck's own backend database when server-side analytics storage is enabled.
AI processing and safety-gate behavior
Non-emergency checks may be sent to an AI provider for response generation. Emergency-pattern inputs are intercepted by the Safety Gate before the AI path is used.
If the AI provider is unavailable, CalmCheck can return a local fallback response instead of a live AI result. That means your symptom text may be processed either by the configured AI provider or by the local fallback engine, depending on service availability.
Where CalmCheck stores data
- If you use CalmCheck as a guest and guest mode is enabled, your local consent and guest history are stored in your browser using localStorage.
- If you sign in, CalmCheck stores your account, consent, session records, and synced check history in its backend database.
- Signed-in check content is encrypted at the application layer when PHI_ENCRYPTION_KEY is configured.
- Audit logs and rate-limit records are stored server-side so CalmCheck can monitor sensitive operations and abuse controls.
- Analytics events are stored server-side with page path, referrer, attribution parameters, anonymous identifier, and event metadata such as CTA clicks or completed checks.
- Launch data passed from the public answer pages into the app uses browser sessionStorage instead of URL query parameters.
How CalmCheck protects data
- Session cookies are HttpOnly and SameSite=Lax; in production they are also marked Secure.
- State-changing API routes require a CSRF token and same-origin checks.
- Request bodies are size-limited and validated on the server.
- Rate limiting is applied to sensitive routes such as sign-in and symptom checks.
- Session tokens are stored as hashes in the database instead of plain text.
- In HIPAA mode, guest PHI storage is disabled and the app requires signed-in use before checks can run.
- In HIPAA mode, analytics ingestion, narration, voice chat, and browser notification nudges are disabled.
These protections reduce risk, but no internet-connected service can promise absolute security.
Retention and deletion
The current product supports signed-in account export and account deletion. Guest-mode browser data remains on the device until you clear site storage. The backend also supports configurable automatic retention sweeps for sessions, checks, audit logs, analytics events, and rate-limit records. The exact retention periods depend on deployment configuration.
Cookies and browser storage
CalmCheck currently uses session cookies, a CSRF cookie, browser storage for guest-mode data when guest mode is available, and first-party analytics requests to its own backend. The current code does not include advertising trackers, remarketing pixels, or third-party analytics SDKs.
HIPAA-regulated use
CalmCheck can be configured with additional controls for HIPAA-regulated workflows, including authenticated-only checks, application-layer encryption for stored check content, and audit logging. That does not by itself make any deployment legally HIPAA compliant. Business Associate Agreements and organizational controls are also required.
Your choices
- You can sign in with Google or, when guest mode is enabled, use CalmCheck without an account.
- You can sign out of CalmCheck.
- You can export signed-in account data from the profile area.
- You can delete your signed-in account from the profile area.
- You can clear guest-mode data by clearing browser storage for the site.