AI Use & Transparency Notice

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 notice is a draft prepared for attorney review. It is not legal advice, and it does not yet create any binding commitment. It describes, as accurately as we can state it, how SingleCase.ai ("the Service") uses artificial-intelligence features today — including what data those features send to third-party AI providers, what we do and do not currently do to protect that data, and how you should treat AI output. Where this notice describes a limitation of the current product, that description is deliberate: we would rather disclose a gap than imply a protection we do not yet provide.

The Service is operated by Single Case Informatics, PBC, a Delaware public benefit corporation. Questions about this notice: [email protected].

This notice sits alongside our Privacy Policy, Terms of Service, Acceptable Use Policy, and Subprocessor List. Where those documents and this notice overlap, read them together; where they conflict on an AI-specific point, this notice controls for that point until counsel reconciles them.

AI-specific matters, or should the ToS control?) and confirm this notice is incorporated by reference into the Terms of Service.

1. What counts as an "AI Service"

The following Service features use artificial intelligence — they send study-related data to a third-party AI provider, which generates a response we return to you. When this notice says "AI Services," it means these features:

• Protocol / study-design assistant — help defining and refining single-case study protocols, phases, variables, and design parameters.
• Automated validation — AI-assisted checks and suggestions on protocol and study content.
• Graph-configuration assistant — help configuring and interpreting single-case graphs.
• Poster content generation — drafting narrative text for research posters from your study data.
• APA table generation — drafting formatted results tables from your study data.
• Data-collection assistance / observation extraction — reading uploaded datasheet or graph images and PDFs to extract observation values.
• Document parsing — extracting text and structure from uploaded research documents (PDF, Word, text, and image files).

Features of the Service that do not call an AI provider (for example, ordinary data entry, graphing, storage, sharing, and export) are not "AI Services" and are governed by the Privacy Policy rather than this notice.

features at publish time; re-verify against the Fact Register (§C) before the effective date, since the code surface can drift.

2. What data an AI Service sends to the provider

This is the most important section of this notice. Read it before you use any AI feature with real participant data.

When you invoke an AI Service, the Service assembles a payload from your study and sends it, over the public internet, out of SingleCase.ai's own infrastructure, to a third-party AI provider (see Section 3) for processing. The payload is not de-identified or redacted before it leaves (see Section 5).

Depending on the feature you use, that payload can include any of the following (Fact Register §C):

• Study title, description, institution, and target population.
• Protocol title, description, design type, and phases/subphases including their dates.
• The principal investigator / author name.
• Participant name — sent verbatim — together with participant age, gender, relevant history, and notes.
• Dependent-variable and independent-variable definitions.
• Demographics and setting, including inclusion and exclusion criteria.
• Analysis plan, primary dependent variable, visual-analysis anchors, and effect-size metrics.
• Social-validity stakeholders and measurement.
• IRB protocol number, approval status, approval date, notes, and confidentiality procedures.
• Observation session values (for example, when generating poster content).
• Graph-configuration snapshots (for the graph assistant).
• Uploaded datasheet or graph images, and the full content of uploaded research documents (for observation extraction and document parsing).
• Your free-text query and the prior turns of your conversation with the feature.

In plain terms: if a field exists in your study, an AI feature that uses that field will transmit its actual contents — including directly identifying participant information and IRB record details — to a third-party AI provider. There is no separate "AI-safe" copy of your data.

fields with no redaction. Confirm the disclosure here is sufficient, and advise whether an explicit, per-feature affirmative consent (rather than notice-plus-use) is required before identifying data is transmitted — particularly for FERPA-covered institutional users and any user subject to GDPR.

3. Which AI providers we use, and where your data goes

AI processing for the Service is performed by third-party providers. In production, these are the only two (Fact Register §B.1):

These two providers are also listed on our public Subprocessor List. Your data leaves SingleCase.ai's infrastructure and is processed on these providers' systems under their terms.

Development-only providers are not used in production. Other AI providers (including OpenAI and the OpenRouter gateway, and the non-US downstream labs reachable through it) are wired into the codebase for development and testing only. They are server-enforced off in production and receive no production data (Fact Register §B.2). We do not list them on the public Subprocessor List because they are not production subprocessors.

3.1 Governance gate before any new provider goes live (D4)

We will not quietly add or switch on a new production AI provider. Enabling any additional model or provider in production — including OpenAI, OpenRouter, any non-US downstream lab, or a live-collaboration backend — requires us to first update the Subprocessor List, the Privacy Policy, and this AI Use & Transparency Notice. Publishing those updates is a precondition to the provider processing any production data, not a follow-up to it (Fact Register §D4).

being held to, and confirm whether material provider changes should also trigger advance notice to users/institutions (and, for institutional contracts, a contractual right to object).

4. Training on your data (no-training commitment — stated honestly)

We do not want your research data used to train or improve AI models, and we do not do so ourselves. We want to be precise about the basis for that today, because being accurate here matters more than sounding strong (Fact Register §F / A3):

• What is true today: The commitment that your inputs are not used to train or fine-tune AI models currently rests on the default API terms of the providers we use — Google's AI Studio (generative-language) API and LlamaCloud. Under those default terms as we understand them, inputs sent through the API are not used to train the providers' models.
• What is not yet true: SingleCase.ai has not yet implemented an additional in-code control (such as a zero-retention flag, a no-train / no-log data-policy header, or an equivalent setting) on top of the providers' default terms. There is currently no such control set on any provider call. We treat adding one as planned work.
• What this means for you: Our no-training position is only as strong as the providers' API terms. It is a real commitment, but it is provider-terms-based, not SingleCase-code-enforced, and this notice will be updated if either the providers' terms or our own controls change.

We reach Google via the AI Studio (generative-language) API, not Vertex AI. This is worth naming because AI Studio and Vertex AI can carry different default data-use terms; our statement above is specific to the AI Studio API path we actually use.

data-use / no-training / retention terms as of the effective date, and confirm this section accurately characterizes them — do not let it drift into a guarantee stronger than the providers actually give. (2) Advise whether a "no training without opt-in consent" contractual commitment in the Terms of Service is appropriate given that no in-code control currently backs it, and whether we should commit to a target date for implementing the zero-retention / no-train control.

5. There is no redaction layer — your responsibility to minimize inputs (A5)

SingleCase.ai does not de-identify, pseudonymize, redact, or otherwise minimize your data before sending it to an AI provider. Participant names and other identifying fields are transmitted verbatim exactly as you entered them (Fact Register §C / A5). The pseudonym-related fields and guidance in the product are suggestions to you, not an automatic redaction step — the Service does not enforce them before an AI call.

Because of this, you are responsible for minimizing the identifiability of the data you put into fields that AI Services use. Practical guidance:

• Prefer participant codes or initials over full names in study and participant fields, consistent with your IRB protocol and Common Rule / NIH minimization practice.
• Keep directly identifying details (names, contact information, unique histories) out of free-text notes and queries when an AI feature will read them.
• Do not upload documents or datasheet/graph images that contain identifiers you are not authorized to transmit to a third-party US AI provider.
• If your IRB protocol, institution's Data Use Agreement, or FERPA obligations restrict disclosing identifiable data to third-party processors, treat the AI Services as out of bounds for identifiable data until those obligations are satisfied.

We plan to add a redaction / minimization layer; until this notice says otherwise, assume none exists and act accordingly.

here given FERPA and Common Rule expectations, or whether the product must implement a technical minimization control before identifiable data may lawfully be sent. This is a product-gating question, not only a drafting one.

6. The nature of AI output — assistance, not authority

AI Services provide research assistance, not authoritative scientific conclusions. Treat every AI output as a draft to be reviewed, verified, and — where you disagree — corrected or discarded.

• You retain full responsibility for the validity of your protocol, the correctness of your data and analysis, your ethical and regulatory compliance, and your scientific conclusions. The Service is infrastructure that assists you; it is not a co-investigator and does not assume any part of the principal investigator's responsibility.
• No accuracy warranty. We provide no warranty that AI output is accurate, complete, current, unbiased, or fit for any particular purpose. AI output may be wrong, incomplete, internally inconsistent, or fabricated (a "hallucination"), including in ways that look confident and plausible.
• Verify before you rely. Independently check any figure, extracted observation value, statistical statement, citation, or methodological claim an AI Service produces before you act on it or include it in research records, publications, or submissions.

is consistent with the Terms of Service limitation-of-liability and warranty-disclaimer clauses (D5 risk posture), and that it does not inadvertently create an exculpatory representation.

7. Bias and limitations

AI models have known limitations you should assume are present:

• Bias. Models reflect biases in their training data. Output may reflect skewed assumptions about populations, behaviors, settings, or clinical/educational norms.
• Error and fabrication. Models can produce confident, well-formatted output that is simply incorrect, and can invent data, sources, or values that were never in your inputs.
• Extraction errors. When reading datasheet or graph images and documents, models can misread numbers, transpose values, mis-associate data with the wrong phase or participant, or omit data. Always verify extracted values against the source.
• Not a domain authority. Models are not a substitute for single-case-design methodological expertise, statistical judgment, IRB review, or clinical/professional judgment.
• Non-determinism. The same input can produce different output on different runs.

Evaluate AI output critically. If an output would change a research decision, verify it against primary sources and your own expertise before relying on it.

8. Ownership of AI output

As between you and Single Case Informatics, you own the protocols, study designs, tables, posters, analyses, and other work product you create with the assistance of AI Services and choose to adopt into your study. Single Case Informatics does not claim ownership of your research work product.

Single Case Informatics (and its providers, as applicable) retain all rights in the underlying AI models, inference infrastructure, and the Service itself. Adopting an AI output into your study does not transfer to you any rights in the models or infrastructure that produced it.

clause; advise on any copyrightability caveats for AI-generated content and on third-party-provider terms that may affect output ownership or licensing.

9. Do not rely on AI output as the sole basis for regulated or IRB-critical decisions

Do not use AI output as the sole basis for any FDA-regulated or IRB-critical decision. Specifically:

• For FDA-regulated research (including anything intended to support a regulatory submission), AI output must not be the sole basis for a study protocol, an analysis, or a reported result without independent expert review. The Service's activity records are not a 21 CFR Part 11 audit trail (see the IRB Data Management Policy), and nothing in the AI Services should be treated as Part 11-qualified.
• For IRB-critical decisions — protocol design, eligibility/inclusion-exclusion criteria, consent, safety monitoring, adverse-event handling, and the accuracy of IRB record fields — AI output is a starting point for your professional judgment and your IRB's review, not a substitute for either.
• Meeting IRB, FERPA, Common Rule, and any FDA obligations remains the responsibility of you and your institution.

"not for clinical/diagnostic use" or "not a medical device" statement is warranted given the single-case-research context.

10. EU AI Act transparency note (brief)

SingleCase.ai is US-primary and does not target the EU market (Fact Register §D3). Where the EU AI Act transparency obligations apply, we note, consistent with this notice: the Service uses general-purpose AI systems provided by third parties to generate text, tables, and extracted data; content and analysis produced by these features are AI-generated and are presented as assistance requiring human review; and the providers and models used are disclosed in Section 3 and on the Subprocessor List. This is a transparency framing only; the full EU data-protection and AI-Act apparatus is deferred until EU or institutional demand arises.

AI-generated content) applies given the US-primary posture, and whether AI-generated outputs require machine-readable marking or additional labeling.

11. In-app transparency at each AI feature

Wherever you can start an AI Service in the product, we aim to show a short, plain-language disclosure before or at the point you invoke it. At every AI entry point, the in-app disclosure should tell you:

1. What is being sent — the specific categories of your study data this feature will transmit for this action (see Section 2).
2. That it leaves the platform — that the data is sent to a third-party AI provider (Section 3) outside SingleCase.ai's own infrastructure.
3. That the output needs review — that the response is AI-generated, may be wrong, and requires your verification before you rely on it (Sections 6–7).
4. A link to this notice — a direct link to this AI Use & Transparency Notice for the full picture.

This in-app touchpoint is a summary and does not replace this notice; where the in-app text is shorter, this notice governs.

just-in-time notice, and whether any feature that transmits identifying participant data requires an affirmative acknowledgment (checkbox) rather than passive notice at the entry point. Also confirm that the in-app text is treated as consistent with, and subordinate to, this notice.

12. Changes to this notice

We will update this notice when our AI features, providers, models, or data practices change — and, per Section 3.1, before any new production provider processes data. Material changes will be reflected in the version header above and, where appropriate, surfaced in the product.