Skip to main content
Operation ADH · privacy

Privacy & data

What this launch candidate stores, how it limits sensitive data, and when deletion is available.

Patient information is prohibited

Do not enter patient-identifying or patient-specific information. Operation ADH uses constrained fields, input screening, output checks, and release review intended to block PHI and patient-specific requests. Those are risk controls, not a guarantee that every submission will be detected. This is an education product, not a patient record or clinical system.

Released cases may be synthetic educational cases or may be derived from material separately cleared for public educational use and de-identified before release. A source file or case being present in the private corpus does not by itself authorize public or learner-facing use.

What an account stores

  • Your account email for authentication, invitation and access binding, checkout and billing linkage, and required account or service communications once those paths are configured. Those uses are separate from optional marketing consent.
  • Your authentication record. Credentials are handled by the configured identity provider; the local development backend stores a one-way password hash rather than the password text.
  • Your subscription status and billing identifiers needed to reconcile Stripe checkout, entitlement, and the customer portal.
  • Usage counters — how many assistant uses you've run this period (for fair-use caps).
  • Your learning record, including preferences, case attempts, answer/reveal outcomes, spaced-review state, saved teaching points, and bounded rep telemetry.
  • An account-bound Ask session currently retains the question, generated reply, cited sources, and timestamps so that session can be resumed, closed, or used by the local content-pack workflow.

Outside that explicit Ask-session store, the candidate's learning telemetry and funnel analytics are designed to retain allowlisted metadata rather than learner free text. Inputs are still processed to generate a response and may be sent to configured AI-model and evidence-retrieval services. Production processor review, retention limits, and deletion coverage remain launch gates.

Product analytics and browser storage

Operation ADH records coarse first-party funnel and page events so we can find broken steps in the learning and signup journey. These events may include an allowlisted page, released case ID, learning-focus category, or completion status. The event schema does not accept learner free text, account email, clinical prose, payment payloads, or patient-specific fields.

  • Your browser keeps at most the latest 100 coarse events in localStorage for first-party continuity. You can remove them by clearing this site's browser data.
  • The first-party server store uses the server receipt time and purges funnel events after 90 days.
  • Successful account creation and paid activation are counted only after the corresponding server-side action succeeds; a browser URL or client clock is not treated as proof.
  • The optional external analytics provider is off by default and remains off for this launch configuration. Enabling it requires a separate governed configuration; even then, the code permits only the same coarse metadata.

Deleting your account

Self-serve deletion becomes available from your account page only after the app can verify that no checkout authorization, billing-provider identity, or subscription relationship remains. Canceling a subscription, finishing paid access, and deleting an account are separate steps.

Once those relationships are resolved, the current deletion route is designed to remove the core identity, profile, learning, cohort-intake, usage, and billing-mirror records and to retain only a minimal anonymous deletion-outcome event. Ask-session deletion and processor-side reconciliation are not yet complete or production-proved, so live enrollment remains blocked until that coverage is closed.

Payments

Card entry is routed to Stripe-hosted pages; Operation ADH is designed not to receive full card numbers. Checkout sends Stripe the account email plus internal user, reservation, and offer identifiers needed to reconcile payment and access. Operation ADH stores or mirrors subscription status and billing identifiers needed for entitlement and the self-serve billing portal.

Processors and communications — launch candidate

The planned launch architecture uses an identity/database provider for account and learning state, Stripe for hosted subscription billing, a configured AI-model provider for generated teaching, and literature/evidence services for source retrieval. An education query may be sent to the configured model and evidence services to produce a response. Exact production configuration, seller identity, processor terms, data locations, retention obligations, and the final subprocessor disclosure still require owner/counsel review before live enrollment.

Account email use for authentication, invitation/access, billing linkage, and required security, purchase, cancellation, refund, or service messages is not marketing consent. Creating an account must not silently add the email to a CRM marketing sequence. CRM marketing and transactional email are not active in this candidate; any successor must keep required service messages separate from optional marketing opt-in and provide tested preference and suppression controls.

Current legal and support status

The Terms are an owner/counsel-gated launch candidate, not approved live terms. The public support, refund-intake, password-recovery, and transactional-email paths are not active. Review the current boundaries on the Help page.

Privacy · Operation ADH