Privacy Policy

1. Scope and purpose

SurgCore Pro is a surgical education and professional-learning product. It is not an electronic health record and must not be used to store patient-identifiable information.

2. Information on your device

Core learning state can be stored locally so study progress remains usable offline. The Surgical Logbook is designed around data minimization and is not part of Learning Cloud synchronization. Do not enter patient names, identifiers, exact dates of birth, contact details, identifiable images, or identifying free text.

3. Account, Google sign-in and cloud information

On the Web/PWA experience, Google sign-in is required for new users and existing users before entering SurgCore. Password-based public signup remains disabled. SurgCore may process the account identifier and email required for authentication and educational progress selected for cloud synchronization.

Google authentication uses PKCE. For the current session model, SurgCore keeps a short-lived access token in the current browser tab's session storage and keeps the rotating Supabase refresh credential in a Secure, HttpOnly, SameSite=Strict host cookie, outside JavaScript-readable Web storage. SurgCore does not receive or store the user's Google password.

A browser upgrading from an earlier SurgCore authentication model may temporarily retain a legacy localStorage credential record that can contain an access token and refresh token while secure broker adoption or reconciliation is still unresolved. SurgCore attempts to migrate that legacy credential into the current tab-session plus HttpOnly-cookie model; successful migration or sign-out removes the legacy localStorage record. A transient broker or identity-verification outage can delay that cleanup so an existing verified session is not destructively discarded before reconciliation.

Cloud access is protected by authenticated sessions and database row-level authorization. Public client builds use publishable credentials; privileged database credentials are not intentionally embedded in the Web or mobile client.

4. Usage, acquisition and operational signals

The Web/PWA experience performs first-touch acquisition attribution when a visit contains campaign parameters, a referral code, or an external referrer. It can store source, medium, campaign, content, referral code, and the external referrer host locally, then submit that first-touch attribution after a SurgCore Google session is verified. The server submission uses the signed-in SurgCore account so the attribution is account-linked and is used for first-party product acquisition measurement, not cross-app advertising tracking.

On the official Web/PWA service, authenticated learning analytics can record account-linked content views and learning events. The bounded event fields include the SurgCore user ID, content type and content ID, optional content/system labels, event type, timestamps, and MCQ correctness for MCQ-answer events. A retry outbox can temporarily retain up to 200 pending learning events in browser localStorage keyed to that SurgCore user when delivery fails. These signals support first-party learning/product analytics and do not intentionally include Logbook narrative, private-chat text, Copilot free text, authentication secrets, or patient-related information.

SurgCore also contains a retired aggregate telemetry implementation that can generate a random app installation identifier and coarse launch or heartbeat signals. The reviewed root/native runtime does not invoke that retired installation telemetry path, so those fields are not represented as collected by the current native binaries.

If the retired installation telemetry is reactivated in a future release, it is designed not to send your name, training level, individual questions or answers, Logbook content, private-chat text, Copilot free text, authentication tokens, stable hardware identifiers, or patient-related information, and it must undergo a fresh privacy/store review before release.

5. AI, voice, feedback and clinical information

Do not submit patient identifiers or identifiable clinical material to SurgCore Copilot, community areas, private chat, feedback, Voice Dictation, or free-text fields. SurgCore is designed for education and rehearsal, not patient-specific diagnosis or treatment.

The learner-facing flagship Surgical Copilot processes prompts locally against the in-app canonical Gold Procedure and Operative Anatomy catalog. In this reviewed release, it does not send the learner's prompt to an external AI or model service. Governed static clinical detail may be loaded before local retrieval.

Voice Dictation beta on supported Web browsers requests microphone access only after the user starts dictation. Speech recognition may be performed by the browser or operating-system speech service. SurgCore does not intentionally store a voice recording in this V1 flow; the resulting transcript is editable and screened for patient identifiers before supported case-draft processing.

6. Service providers

SurgCore Pro currently relies on Supabase for authenticated account and cloud-data capabilities and on Expo/EAS services for application deployment, hosting, and limited operational request monitoring. Optional speech recognition may additionally be provided by the user's browser or operating-system speech service.

Feedback opens WhatsApp/Meta with a prefilled template. Opening it contacts WhatsApp/Meta; no feedback message is submitted until the user chooses Send. WhatsApp/Meta may receive request or network metadata and may associate it with the user's WhatsApp identity under its terms. SurgCore does not automatically send learning, Logbook, Copilot, or patient data to WhatsApp.

7. Retention and deletion

Device-local information remains until removed through product controls, browser/application storage is cleared, or the application is removed, subject to platform backup behavior outside SurgCore's direct control.

For current Google stay-signed-in access, the short-lived access token is normally tab-scoped and the Secure HttpOnly refresh cookie remains scoped to that browser profile until sign-out, session invalidation/revocation, cookie expiry, or site data is cleared. During migration from the earlier Web auth model, the bounded legacy localStorage credential described above can remain until adoption/reconciliation succeeds or the user signs out/clears site data. Cloud information is retained as needed to provide the selected account feature and for legitimate security, integrity, backup, and incident-recovery purposes. SurgCore does not claim an unverified provider-backup erasure deadline.

Signed-in users can open the permanent account-deletion flow from Account & Sync. A public deletion resource is also available at https://surgcorepro.com/delete-account.html and canonicalizes to the official app origin. The server requires a recently authenticated account, the exact deletion confirmation, and confirmation of the signed-in email; active Academy supervision responsibilities must be transferred or closed before deletion can proceed.

The deletion workflow revokes sessions, removes mapped SurgCore account-owned application data, deletes the Supabase Auth user, and records completion or reconciliation evidence. Database and Auth deletion are a staged, resumable cross-system workflow rather than one atomic transaction. Security, deletion-request, incident-recovery, or provider-backup evidence may remain only where legitimately required; SurgCore does not promise immediate erasure of every provider backup copy.

8. Your choices

Google sign-in is required to enter the Web/PWA experience. After successful sign-in, this browser profile can remain signed in using the current HttpOnly refresh-cookie model or, during bounded migration from the earlier auth model, the legacy credential state described above until it is adopted, cleared, or signed out. Signed-in users may initiate permanent account deletion from Account & Sync or use the public deletion resource. Voice Dictation and WhatsApp feedback remain optional; no feedback message is sent unless you choose Send.

9. Security and access

SurgCore uses authenticated sessions, PKCE for Google OAuth, a current same-origin Secure HttpOnly refresh-cookie boundary, least-privilege database policies, transport encryption provided by hosting/cloud platforms, and release gates intended to prevent privileged credentials from being shipped in client builds. The earlier localStorage credential path is retained only as a bounded migration/reconciliation compatibility path and is removed after successful migration or sign-out. No security control eliminates all risk.

10. Changes to this policy

This policy is reviewed when SurgCore changes its account model, cloud synchronization, analytics, AI or speech providers, messaging, retention, or other material data flows. This operational privacy disclosure does not replace jurisdiction-specific legal advice.