Privacy Policy

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.

1. Who we are and how to reach us

SingleCase.ai ("the platform," "the Service") is operated by Single Case Informatics, PBC, a Delaware public benefit corporation ("Single Case Informatics," "SCI," "we," "us," "our"). Our principal office is in State College, Pennsylvania 16803, USA (Fact Register §A, D1).

• Contact for privacy questions, rights requests, and data-deletion requests: [email protected] (Fact Register §A, D7)
• Governing law: the Commonwealth of Pennsylvania, United States (Fact Register §A, D1)

"You" means any person who registers for or uses the Service. This policy governs the SingleCase.ai application. It supersedes any earlier privacy notice that covered only the SingleCase.ai landing page or waitlist.

Controller / processor role

For account and profile data you give us to create and run your account, SCI acts as the controller. For the research content you and your collaborators enter — protocols, research-participant data, IRB records, observation data, graphs, tables, and posters — SCI generally acts as a processor / service provider handling that data on your (or your institution's) instructions; you, and where applicable your institution, remain responsible as the controller of that research data and as the Principal Investigator of record.

2. Personal data we collect

We collect the following categories of personal data (Fact Register §E unless noted):

Account and registration data. When you sign up we collect your first name and last name (submitted together as your full name), your email address, and a password (Fact Register §E). During onboarding we also collect an organization name you supply (Fact Register §E). We authenticate you using email + password and a 6-digit one-time code sent to your email — these are the only sign-in methods; the Service does not currently offer OAuth, single sign-on (SSO), SAML, or multi-factor authentication (Fact Register §E).

Profile data. Your stored profile record contains your account identifier, email, full name, an optional avatar image, and your role on the platform (Fact Register §E).

Roles and membership data. We record your membership in organizations, workspaces, and studies, and your role in each (for example organization owner/admin/member; workspace admin/editor/viewer; and your resolved level of access to a given study) (Fact Register §E).

Research protocol content. Study designs and protocols you build on the platform — titles, descriptions, design type, phases and subphases (including dates), Principal-Investigator / author name, dependent- and independent-variable definitions, demographics and setting (including inclusion/exclusion criteria), analysis plans, and social-validity information (Fact Register §C, §D).

Research participant data. Data you enter about the human subjects of your research, including participant name, age, gender, relevant history, and notes, together with the behavioral observation session values you record (Fact Register §C, §D). This data is entered by you as the researcher; see §5 and §10.

IRB records. Institutional Review Board information you enter, including IRB protocol number, approval status, approval date, notes, and confidentiality procedures (Fact Register §C, §D).

Uploaded documents and images. Research files you upload — PDFs, Word documents, text/markdown, and datasheet or figure images (PNG/JPEG) — and their extracted contents (Fact Register §B.1, §C). We also store certain images you upload, such as organization logos and poster images (Fact Register §B.1).

Usage and activity data. Records of activity in the app (an activity feed of events such as study and membership changes), logs of your interactions with the AI features, and comments you post on studies (Fact Register §D). Standard technical request metadata (for example IP address and user-agent) is processed by our hosting provider in the ordinary course of serving the app (Fact Register §B.1). Note on the activity feed: it is a convenience/history feature, not a tamper-evident, 21 CFR Part 11-grade audit trail — see §11 and Fact Register §F (A6).

Communications. If you email us (for example at [email protected]), we receive your message and email address. Transactional email — such as sign-in codes and account notices — is delivered through our authentication provider's email service (Fact Register §B).

What we do not collect. We do not use analytics or advertising SDKs, error-tracking/telemetry SDKs, session-recording tools, or payment/billing SDKs, and we do not operate an advertising network or sell data to data brokers (Fact Register §B, "Negatives"). We do not knowingly collect Protected Health Information (PHI) — its submission is prohibited (see §8).

3. How we use personal data

We use personal data to:

• Create, authenticate, and administer your account, organizations, workspaces, and studies.
• Provide the core research features: building protocols, recording observation data, generating graphs, APA tables, and posters, and enabling collaboration and comments among people you share a study with.
• Provide the AI-assisted features you invoke (protocol drafting/validation, data extraction from uploaded documents and images, graph and table assistance, poster fill) — see §5 for exactly what is sent and to whom.
• Send transactional communications (sign-in codes, account and security notices, and notices about changes to this policy or our terms).
• Maintain the integrity, security, and reliability of the Service, and respond to your support requests.
• Comply with legal obligations and enforce our terms.

Legal bases (for users in jurisdictions that require one). Where applicable law requires a legal basis (for example, in the EU/UK), we rely on performance of our contract with you, our legitimate interests in operating and securing the Service, your consent where we ask for it, and compliance with legal obligations. This policy is written US-primary; the full GDPR legal-basis apparatus is deferred pending EU/institutional demand (Fact Register §A, D3).

We do not sell your personal information, and we do not "share" it for cross-context behavioral advertising, as those terms are used under the CCPA and comparable US state laws. We do not use your research content, protocols, participant data, or study designs to train or fine-tune AI models — see §5 for the important detail on how that commitment currently rests.

4. How research, participant, and IRB data is stored, secured, and isolated

Two data stores. Your research content is split across two systems (Fact Register §D):

• Supabase / Postgres holds identity and account data, organization/workspace/study membership and roles, study metadata, a document index, AI interaction logs, comments, and the activity feed.
• MongoDB Atlas holds the large research bodies themselves — protocols, observations, graph configurations, and APA tables — keyed to the index rows in Postgres.

Isolation is logical, not physical (Fact Register §D). Separation between users, organizations, and workspaces is enforced by Postgres Row-Level Security (approximately 240 active policies) together with application-layer access checks. MongoDB does not enforce tenant isolation of its own; the research bodies stored there are protected because every request first passes a Row-Level-Security check against the Postgres index rows before the corresponding MongoDB content is retrieved.

Encryption. Data is encrypted in transit and at rest at the infrastructure layer by our providers (Supabase, Vercel, MongoDB Atlas) under their platform defaults (Fact Register §D). SCI does not apply its own application-level field encryption, and the platform does not implement a data-classification or sensitivity-tiering scheme (Fact Register §D). We describe this plainly so you can make an informed decision about what you enter.

Access controls. Access to your data within the Service is governed by the role and membership model described in §2. Administrative access, including a support "view as user" capability, is restricted and itself operates within the same Row-Level-Security constraints (Fact Register §E).

5. Artificial-intelligence processing disclosure

SingleCase.ai includes AI-assisted features. When you use them, data from your study is sent to a third-party AI provider to generate the response. Please read this section carefully — it is the most important disclosure in this policy.

Who receives the data. The default, always-on AI provider is Google (Gemini) (Fact Register §B.1, §C). Uploaded research documents and datasheet/figure images are additionally sent to LlamaCloud / LlamaParse for parsing and text/figure extraction (Fact Register §B.1). Both providers process data in the United States. See the separate Subprocessor List for the current, complete list of production subprocessors and their roles; we maintain it there rather than duplicating it here.

What is sent to the AI provider (Fact Register §C). Depending on the feature you use, the data sent to the AI provider includes: study title, description, and institution; target population; protocol title, description, design type, and phases/subphases including dates; the Principal-Investigator / author name; participant name (sent verbatim), age, gender, relevant history, and notes; dependent- and independent-variable definitions; demographics and setting including inclusion/exclusion criteria; the analysis plan and visual-analysis anchors; social-validity information; IRB protocol number, approval status, approval date, notes, and confidentiality procedures; observation session values; graph-configuration snapshots; uploaded datasheet/graph images; and your free-text query together with prior-turn conversation history.

No redaction or pseudonymization (Fact Register §F, A5). We want to be direct: identifiable participant fields (including participant name) and IRB fields are transmitted to the AI provider (Google Gemini) as-is in order to deliver these features. There is currently no redaction, pseudonymization, or de-identification layer that removes this information before it is sent. Any pseudonym or de-identification guidance shown in the app is advisory to you as the researcher; it is not an automatic technical control. If you do not want a participant's identifiable information sent to the AI provider, do not enter it in identifiable form, or do not use the AI features for that study.

On training (Fact Register §F, A3). We do not use your research content to train or fine-tune AI models. Today, that commitment rests on the default API terms of our AI providers (Google's AI Studio / Generative Language API and LlamaCloud); we have not yet implemented an additional in-code no-training or zero-retention control on the provider calls. We disclose this so the commitment is not overstated.

AI outputs are assistive. AI-generated protocol suggestions, validations, extractions, and analyses are tools to assist you. You, as the researcher, are responsible for reviewing and verifying them; they do not substitute for your own judgment, IRB review, or professional/ethical obligations.

Development-only providers. Certain other AI providers are wired into the codebase for development but are disabled in production and receive no production data. Enabling any of them in production would require us to update this policy, the Subprocessor List, and our AI Use Notice first (Fact Register §B.2, §A D4).

For a fuller description of the AI features, see our AI Use / Transparency Notice (when published).

6. Subprocessors

We rely on a small number of third-party service providers ("subprocessors") to run the Service. In production these are Supabase, Vercel, MongoDB Atlas, Google (Gemini), and LlamaCloud (Fact Register §B.1). Each receives only the data needed for its role, and each processes data in the United States. The current, complete list — with each party's role and the data category it receives — is maintained on our separate Subprocessor List page, which also describes how we give notice of changes.

Some of these vendors publish their own SOC 2 and/or HIPAA attestations. Any such certification belongs to the vendor and is stated as the vendor's own; SCI does not hold SOC 2 or HIPAA certifications and does not present a vendor's attestation as its own (Fact Register §B.1 note, §G).

7. FERPA acknowledgment

When SingleCase.ai is used by an educational institution in connection with data drawn from student education records covered by the Family Educational Rights and Privacy Act (FERPA), SCI intends to act as a "school official" performing an institutional service, and such use is conditioned on a written Data Use Agreement (DUA) between the institution and SCI (Fact Register §G; §A D2). Under that arrangement, SCI would use education-record data only for the purposes authorized by the institution, would not re-disclose it except as permitted, and would remain under the institution's direct control with respect to that data.

To date SCI has not executed any institutional DUA or DPA and holds no HECVAT or similar certification (Fact Register §A, D2). Institutional and FERPA-governed use is therefore governed by a separate agreement that must be signed before such use; absent that agreement, users must not upload student education records covered by FERPA.

8. HIPAA limitation notice

SingleCase.ai is not a HIPAA Business Associate. SCI has no Business Associate Agreement (BAA) in place and is not authorized to receive, store, or process Protected Health Information (PHI) as defined by HIPAA (Fact Register §G). Do not upload or enter PHI, including data originating from a HIPAA-covered entity, into the Service. Research-participant data you enter must not constitute PHI. If PHI is submitted in error, contact us at [email protected] and we will work with you to remove it. (Vendor HIPAA capabilities, where they exist, belong to the vendor and require a separate BAA that SCI has not entered — see §6.)

9. Who can see your data (cross-user visibility)

Access to studies and research content follows the organization → workspace → study membership model, and to the sharing choices you and your collaborators make.

Please note this specific behavior (Fact Register §E): anyone who shares an organization or workspace with you can see your profile identity — your full name, email address, and avatar image. This is how collaborators identify one another in shared organizations and workspaces. If you do not want a particular name, email address, or image visible to co-members, take that into account in what you enter as your profile and which organizations/workspaces you join.

Beyond profile identity, other members' ability to see the research content of a given study depends on their role and their access to that study.

10. Children's data and COPPA

The SingleCase.ai application is a professional research tool and is not directed to children as account holders. You must be at least 18 years old to create or hold an account (Fact Register §A, D9; Terms of Service §3), and we do not knowingly collect account or registration data from anyone under 18. If we learn that an account belongs to someone under 18, we will close it and delete the associated account data.

Research on the platform may, however, involve data about minors as research participants (for example, a single-case study of a child). That participant data is entered by you, the researcher, and it is your responsibility — and your institution's and IRB's — to have the appropriate legal basis and parental/guardian consent for collecting and processing it, consistent with the Common Rule, COPPA where applicable, FERPA where applicable, and your IRB's determinations (Fact Register §G). SCI provides the tools; it does not obtain participant or parental consent on your behalf.

11. Data retention

We retain personal data for as long as needed for the purposes described in this policy, then delete or anonymize it. Our retention periods are (Fact Register §A, D6):

We would rather tell you that the activity feed is not yet time-limited than publish a period we do not currently enforce.

Activity feed is not a regulatory audit trail (Fact Register §F, A6). The activity feed is an operational history of events; it is user-immutable but is not append-only or tamper-evident, does not record before/after values, and does not capture every event. It should not be relied on as a 21 CFR Part 11-grade audit trail.

12. Your rights and how to exercise them

Depending on where you live (including under the CCPA and other US state privacy laws, and, for international users, laws such as the GDPR), you may have some or all of these rights in your personal data: the right to access/know, to correct, to delete/erase, to data portability, to opt out of sale or sharing (which does not meaningfully apply here because we do not sell or share your data for advertising), to object to or restrict certain processing, to withdraw consent, and to non-discrimination for exercising these rights. You also have the right to lodge a complaint with your local data-protection authority.

How to exercise them. Email [email protected]. We will respond within 30 days, or sooner where the law requires. We may need to verify your identity before acting — typically by confirming the request comes from the email address on your account.

Access and correction. You can view and update much of your profile within the app; for anything you cannot change yourself, contact us.

Deletion / erasure — current process (Fact Register §F, A1). There is currently no self-service account-deletion button in the app. To request deletion or erasure of your account and associated data, email [email protected]; we process erasure requests manually within 30 days. Because your data spans two stores and some records are linked to shared organizations, workspaces, and studies, some content you created in a shared context (for example, studies others still rely on, or comments in a shared study) may be anonymized or transferred rather than hard-deleted, and residual copies in backups are purged on the backup cycle described in §11. We will tell you what was done.

13. International data transfers

The Service is hosted in the United States, and all of our production subprocessors process data in the United States (Fact Register §B.1). If you access the Service from outside the United States, your personal data will be transferred to and processed in the United States, where data-protection laws may differ from those in your location.

This policy is written US-primary (Fact Register §A, D3). For users in the EU, UK, or similar jurisdictions, cross-border transfers currently rely on the standard data-transfer terms of our US-based providers. The full GDPR transfer apparatus — a customer-facing Data Processing Agreement, Standard Contractual Clauses, and an Article 27 EU/UK representative — is deferred until EU or institutional demand warrants it.

14. Security

We rely on established infrastructure providers (Supabase, Vercel, MongoDB Atlas) that encrypt data in transit and at rest at their layer, and we enforce access with Row-Level Security and role-based access controls as described in §4 (Fact Register §D). We limit access to your data to personnel who need it. As noted, isolation is logical (not physical), there is no application-level field encryption, and there is no data-classification tiering (Fact Register §D). No system is perfectly secure, and we cannot guarantee that data transmitted to us will never be accessed by an unauthorized party.

For our security-vulnerability reporting process, see our Vulnerability Disclosure Policy (when published).

15. Breach notification

If a security breach affects your personal data, we will notify affected users and, where required, the relevant authorities and/or your institution, without undue delay and as required by applicable law.

16. Changes to this policy

This policy carries a version number and effective date at the top. When we make a material change, we will update those and notify account holders by email before the change takes effect. Non-material changes (clarifications, typo fixes, formatting) may be made without separate notice. The current published version always governs. We will maintain a version history when this policy is published.

17. Contact

For privacy questions, rights requests, or to report a concern:

Single Case Informatics, PBC [email protected] State College, PA 16803, United States