Privacy Policy

Single Case Informatics, PBC · Effective date: 2026-08-25 · Version 2026-08-25

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.

• Contact for privacy questions, rights requests, and data-deletion requests: [email protected]
• Governing law: the Commonwealth of Pennsylvania, United States

"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:

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. During onboarding we also collect an organization name you supply. 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.

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

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).

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.

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. 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.

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

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. 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. Note on the activity feed: it is a convenience/history feature, not a tamper-evident, 21 CFR Part 11-grade audit trail — see §11.

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; Contact-Sales submissions are delivered to our sales inbox through Resend.

Billing and payment data. If you purchase a paid plan, our payment processor Stripe collects your name, email, billing address, tax status, and payment-card details on its own hosted checkout page. SCI does not receive or store your full card number — only a Stripe customer identifier linked to your organization, together with records of your plan, invoices, and payments. If you submit the Contact-Sales form, we collect the name, work email, organization, and message you provide, which are emailed to our sales inbox via Resend.

What we do not collect. We do not use analytics or advertising SDKs, error-tracking/telemetry SDKs, or session-recording tools, and we do not operate an advertising network or sell data to data brokers. Payment-card numbers are entered directly on our payment processor's hosted page and are not received or stored by SCI (see "Billing and payment data" above). 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).
• Process payments, manage subscriptions and invoices, meter AI usage, and provide billing support, through our payment processor (Stripe).
• 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.

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:

• 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. 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. SCI does not apply its own application-level field encryption, and the platform does not implement a data-classification or sensitivity-tiering scheme. 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.

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). Uploaded research documents and datasheet/figure images are additionally sent to LlamaCloud / LlamaParse for parsing and text/figure extraction. 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. 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. 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. 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.

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), LlamaCloud, Stripe (payments and billing), and Resend (Contact-Sales email). 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.

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 (§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. 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. 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: 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 (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. 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:

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. 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. 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. Billing and payment records required for tax, accounting, and legal compliance are retained for the applicable legal period even after account deletion (§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. 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. 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. 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. 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