Cookie Policy (Application)

Status: DRAFT — pending licensed-attorney review. Not yet published; not yet in force. Version 1.0-draft · Grounded in docs/legal/FACT_REGISTER.md (code facts verified 2026-07-23; owner decisions D1–D14 updated 2026-08-04) Intended effective date: 2026-08-04 · Last updated: 2026-08-04 — takes effect when published, which happens only after attorney sign-off.

This is a DRAFT prepared for attorney review. It is not legal advice, and it is not yet in effect. It describes how the SingleCase.ai application (the signed-in product) uses cookies and similar browser storage as of the verification date above. It does not cover the public SingleCase.ai landing/marketing site, which has its own separate cookie notice.

Single Case Informatics, PBC (a Delaware public benefit corporation) operates SingleCase.ai. Where this policy uses "we," "us," or "SCI," it means that entity.

The short version

The SingleCase.ai application uses only the browser storage it needs to keep you securely signed in and to remember a few interface preferences. That is all.

• We set no analytics cookies, no advertising or marketing cookies, and no third-party tracking cookies or pixels. There is no Google Analytics, PostHog, Mixpanel, Segment, Plausible, Fathom, Vercel Analytics, Meta Pixel, session-recording tool, or error-tracking SDK in the application. (Verified against the codebase — see docs/legal/FACT_REGISTER.md §B, "Negatives.")
• Because we set no non-essential cookies today, no cookie-consent banner is shown and none is legally required for US visitors. If that ever changes, this policy explains below what we will do first.
• We do not sell or share your personal information for cross-context behavioral advertising.

The rest of this policy explains the details you may want anyway.

1. What cookies and browser storage are

A cookie is a small piece of data a website asks your browser to store and send back on later requests — for example, to remember that you are signed in. Local storage and session storage are related browser mechanisms that hold data on your device but, unlike cookies, are not automatically transmitted with every request; the application reads them only when it runs in your browser.

Cookies and storage can be first-party (set by SingleCase.ai) or third-party (set by another service embedded in the page). The SingleCase.ai application sets first-party storage only and embeds no third-party trackers.

Cookies are commonly grouped by purpose:

• Strictly necessary — required for the service to work (for example, authentication). In the EU/UK these are exempt from consent requirements.
• Functional — remember preferences and choices to improve your experience.
• Analytics — measure how the product is used. We use none.
• Marketing / advertising — build profiles for targeted advertising. We use none.

2. Cookies the application sets today

The application sets the following first-party cookies. There are no others, and there are no third-party cookies set at our direction.

Verified in code: authentication cookie name, flags (HttpOnly, Secure in production, SameSite=Lax, Path=/), and lifetimes in lib/auth-v2/config.ts and lib/auth-v2/token-storage.ts; the sidebar:state cookie in components/ui/sidebar.tsx.

Short-lived access token — not a persistent cookie. In addition to the refresh-token cookie above, your short-lived access token is held in memory only, per browser tab, and is discarded when you close the tab. It is not written to disk, to localStorage, or to a persistent cookie (lib/auth-v2/token-storage.ts). Authentication itself is provided by Supabase Auth, which issues the underlying session tokens (FACT_REGISTER §B).

Third-party infrastructure. The application is hosted on Vercel (FACT_REGISTER §B). A hosting/CDN provider may set its own strictly-necessary operational cookies (for example, load balancing or routing) in the ordinary course of serving the site. These are not set by our application code, are not used for analytics or advertising, and are generally exempt from consent as strictly necessary. We do not have granular control over them. is this general disclosure sufficient given SCI does not control them?

3. Local storage and session storage (not cookies)

Beyond cookies, the application uses your browser's local storage and session storage for two honest purposes: to remember interface preferences and to cache data you already have permission to see so pages load quickly and you don't lose in-progress work. This data stays on your device, is first-party, is not transmitted for analytics, and is not shared with any third party.

Representative examples (categories, described generically):

• Interface preferences — sidebar collapsed/expanded state, pinned workspaces, graph zoom level, statistics/decimal display settings, color theme, and a one-time marker recording that you have seen the first-run orientation.
• Performance caches — your lists of studies, workspaces, and members, and dashboard view parameters, cached so navigation is fast. These caches are scoped to your account and are cleared when the signed-in user changes or you log out.
• Work in progress — locally saved report drafts and setup autosave snapshots that live only in your browser until you save or discard them.

Local-storage entries generally persist until the application or you clear them; session-storage entries are cleared automatically when you close the browser tab. None of this storage is used to profile you or to track you across other websites.

Legacy note. An earlier version of the app stored session tokens in localStorage (auth_token / refresh_token). The current app has moved to the cookie + in-memory model described above and clears these legacy values when it finds them (lib/auth-v2/token-storage.ts). You can also remove any remnants yourself using the steps in Section 6. or is it immaterial for a cookie policy?

4. What we do NOT use

We want to be explicit, because for our university and research audience this is a trust matter. In the SingleCase.ai application there is (verified — FACT_REGISTER §B):

• No analytics — no Google Analytics, PostHog, Mixpanel, Segment, Plausible, Fathom, or Vercel Analytics.
• No error-tracking / session-recording — no Sentry or similar client SDK.
• No advertising or marketing cookies or pixels — no Meta Pixel, no ad tags, no retargeting.
• No third-party trackers embedded in the application.
• No sale or sharing of personal information for cross-context behavioral advertising, and no cookie-based profiling.

5. Consent — how it would work if we ever add non-essential cookies

Today the application sets only strictly-necessary and functional first-party storage and no analytics, marketing, or other non-essential cookies. For that reason no consent banner is displayed, and none is required for US visitors under CCPA/CPRA and comparable state laws.

This is framed as future-conditional. If we ever introduce any non-essential cookie or client-side tracker (for example, product analytics), then before it is set we will:

1. Update this policy to name the tool, what it collects, how long it retains data, and what cookie(s) it sets;
2. Add a consent mechanism so that non-essential cookies do not fire until you have made a choice, with an easy way to withdraw consent later; and
3. For visitors in the EU/UK, present a GDPR / ePrivacy opt-in consent banner — non-essential cookies must not be set before affirmative consent, and Accept/Reject must be equally available.

An internal design specification for such a banner exists, but it is not implemented and no banner is live in the application today. Do not interpret this section as describing an existing feature.

Consistent with our US-primary posture (FACT_REGISTER §A, D3), the full EU consent-banner apparatus is deferred until non-essential cookies actually exist or EU/institutional demand requires it.

functional cookie plus the functional localStorage preferences are correctly treated as consent-exempt / not requiring a banner for our current US-primary launch — and whether any of the functional items should instead be classified as non-essential under EU ePrivacy if we begin targeting EU visitors.

6. How to see, control, or clear cookies and storage

You are always in control of cookies and storage through your browser:

• Clear site data — In your browser settings, clear cookies and site data for the SingleCase.ai application domain. This removes both cookies and local/session storage for the site.
• Private / incognito mode — Storage created in a private window is discarded when you close it.
• Block cookies/storage for this site — Your browser can block cookies or storage per site.

Please note the trade-offs:

• Blocking or clearing the authentication cookie will sign you out, and blocking it entirely will prevent you from logging in — it is strictly necessary for the service.
• Clearing functional storage will reset interface preferences (such as sidebar state) and may discard locally saved report drafts or setup autosave snapshots that have not yet been saved to your account.

Logging out clears the authentication cookie for you.

Most browsers document these controls here: Chrome, Firefox, Safari, Edge. these should be described generically without outbound links.

7. Changes to this policy

We may update this Cookie Policy as the application changes. If we introduce any non-essential cookie or tracker, we will update this policy and stand up the consent mechanism described in Section 5 before the change takes effect. Material changes will be dated in the header.

8. More information and contact

This Cookie Policy is a companion to our Privacy Policy, which describes what personal information the application collects, who processes it (our subprocessors), and the rights you have in it. (Final published URL to be set at publish-wiring.)

Questions about this policy or our cookie practices:

Single Case Informatics, PBC (a Delaware public benefit corporation) [email protected] State College, PA 16803, United States