Acceptable Use 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. About this Policy

This Acceptable Use Policy ("AUP") governs how you may use SingleCase.ai and the related services (the "Service") operated by Single Case Informatics, PBC, a Delaware public benefit corporation with its principal office in State College, PA 16803 ("SCI," "we," "us") (Fact Register §A/D1). The Service is a platform for designing, running, analyzing, and publishing single-case experimental design ("SCED") research.

This AUP is part of, and is incorporated by reference into, the SingleCase.ai Terms of Service ("ToS"). Capitalized terms not defined here have the meaning given in the ToS. If this AUP conflicts with an individually negotiated institutional agreement (for example, a signed Data Use Agreement), that institutional agreement controls for the institution's users to the extent of the conflict. Otherwise, the ToS controls (Fact Register §A/D2).

reference vs. free-standing), and confirm that a breach of this AUP is defined in the ToS as a material breach that supports suspension or termination.

This is a draft prepared for attorney review. It is not legal advice, and it does not itself establish that the Service meets any regulatory standard. You are responsible for determining which laws, institutional policies, grant conditions, and ethical rules apply to your research and your data, and for complying with them.

2. Who this applies to

This AUP applies to every person who accesses or uses the Service — including individual researchers, principal investigators, lab managers, students and lab members, and any user acting on behalf of an organization or institution. If you use the Service on behalf of an organization, you represent that you are authorized to bind that organization to this AUP, and "you" includes that organization.

You must be at least 18 years old to hold an account. The Service is a tool used by researchers about their human subjects; it is not directed to children as account holders. Research about minors is addressed in Section 7 (Fact Register §G — COPPA).

3. Key facts you must understand before you input data

Two facts about how the Service actually works drive most of the obligations in this AUP. Read them before you enter any data.

(a) AI features transmit your inputs to a third-party AI model. When you use an AI-assisted feature (protocol assistance, validation, graph/table/poster generation, datasheet or figure image extraction, and similar features), the content you provide is sent to a third-party AI provider — currently Google (Gemini) as the default, always-on provider — and, for uploaded documents, to LlamaCloud / LlamaParse for parsing (Fact Register §B.1, §C). What is transmitted includes, among other things, study title/description/institution, principal investigator/author name, participant name, age, gender, relevant history, and notes, dependent- and independent-variable definitions, inclusion/exclusion criteria, analysis plans, observation session values, uploaded datasheet/figure images, IRB protocol number, approval status, approval date, and confidentiality procedures, and your free-text queries (Fact Register §C). Use of an AI feature is your instruction to us to transmit that content to these providers to produce the feature's output.

(b) The Service does NOT classify, redact, de-identify, or tier your data for you. There is no enforced data-classification or sensitivity tiering in the Service, and no redaction, pseudonymization, or de-identification step runs before content is sent to an AI provider — participant and IRB fields are transmitted verbatim (Fact Register §C "A5", §D). Any classification, minimization, or de-identification is therefore your responsibility, performed before you enter data, not a control the Service applies. Do not assume the platform is filtering, masking, or withholding anything you type or upload.

For more detail on what is sent to which provider, see the AI Use / Transparency Notice and the Subprocessor List.

4. Your data-classification obligation at input

Because the Service does not tier data for you (Section 3(b)), you must classify the data you intend to enter before you enter it, and you must only enter data whose sensitivity is appropriate for a system with the characteristics described in this AUP and in the Privacy Policy and Security Overview. Use the following classification as your framework:

You must apply the minimization principle: enter the least identifiable form of data that still lets you do your research. Where your protocol and IRB allow de-identified or coded data, use it. Do not enter direct identifiers, or free-text that reveals them, into any field — including AI free-text queries — unless it is genuinely necessary and approved.

The classes above are your obligation, not a system feature. The Service does not verify, label, or enforce them (Fact Register §D). Note that the only field in the system named "classification" is an internal AI-moderation artifact and is not a data-sensitivity tier (Fact Register §D).

the minimization duty adequately allocate responsibility to the user given there is no technical enforcement, and confirm the wording does not imply a system control we do not have.

5. Prohibited inputs

You must not upload, enter, transmit, or otherwise process any of the following through the Service. These prohibitions apply regardless of whether you use an AI feature, because all such content is stored on our infrastructure and much of it may be transmitted to AI providers (Section 3).

• Protected Health Information (PHI) / HIPAA-regulated data. SCI is not a HIPAA Business Associate, has no Business Associate Agreement (BAA) in place with any customer or with its own subprocessors, and the Service is not configured for HIPAA compliance (Fact Register §G, §B.1 note). Do not enter PHI or any data that would subject SCI to HIPAA as a Business Associate. If your research involves PHI, you may not use the Service for it until a BAA is executed and we notify you that HIPAA-covered use is supported.

• FERPA-protected student education records without a Data Use Agreement. Do not enter personally identifiable information from student education records governed by the Family Educational Rights and Privacy Act unless your institution and SCI have executed a Data Use Agreement ("DUA") designating SCI as a "school official" (or another lawful FERPA basis applies) and that agreement authorizes the specific use. No such institutional DUA is in place by default (Fact Register §A/D2, §G).

• Export-controlled data. Do not enter technical data, software, or information subject to the U.S. International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR), or any data whose transmission to our subprocessors (all currently U.S.-based) or their personnel would violate export-control law (Fact Register §G, §B.1).

• Government-classified data. Do not enter data classified by any government (e.g., U.S. Confidential/Secret/Top Secret or foreign equivalents) or controlled-unclassified information that you are not authorized to process on a commercial cloud service.

• Third-party material you have no right to use. Do not enter, upload, or process third-party copyrighted works, datasets, protocols, or other materials in a way that infringes the rights holder's rights or violates the terms under which you obtained them, and do not use the Service to misappropriate another researcher's designs or data.

• Unlawful, malicious, or infringing content, or content that violates a third party's privacy, contractual, or intellectual-property rights.

If you are unsure whether data falls into a prohibited category, do not enter it until you have resolved the question with your IRB, institutional compliance office, or counsel.

third-party-IP prohibitions are complete and correctly framed for a US-primary posture, and whether any additional categories (e.g., FISMA/CUI, state-specific sensitive-data categories) should be listed.

6. AI feature use boundaries

The Service's AI features are research-assistance tools, not authoritative scientific conclusions and not a co-investigator. You remain fully responsible for the validity, accuracy, ethics, and integrity of your research. When using AI features you must:

• Validate AI output before adopting it. AI-generated suggestions, analyses, protocol text, graphs, tables, and other outputs must be reviewed and validated by a qualified researcher before you rely on, publish, or act on them. AI output can be incomplete, biased, or wrong. Do not treat AI output as the sole basis for a protocol, an analytic conclusion, a phase-change decision, or any regulated determination.

• Not use AI features to fabricate, misrepresent, or manipulate research data. You must not use AI to invent observations or results, to alter data to reach a desired conclusion, to generate fictitious participants or sessions, or to otherwise produce a false or misleading research record. (See also Section 8, Research integrity.)

• Respect the transmission described in Section 3. Do not paste or upload prohibited inputs (Section 5) into AI features, and apply your classification and minimization obligations (Section 4) to everything you send to an AI feature — including free-text queries.

• Exercise added caution for regulated research. For FDA-regulated or other formally-regulated research, do not use AI output as the sole basis for a protocol or submission without independent qualified expert review; note also that the Service's activity logging is not a 21 CFR Part 11 audit trail (Section 9, Fact Register §F "A6", §G).

PI of record or institutional role) and whether an express no-warranty/assumption-of-risk statement for AI output belongs here or solely in the ToS / AI Use Notice.

7. Research-ethics and IRB obligations

You — and your institution where applicable — remain the Principal Investigator(s) of record and the responsible party for research-ethics compliance. The Service is infrastructure; it does not obtain approvals, does not provide ethical review, and does not assume any investigator responsibility. You must:

• Obtain all required approvals before collecting or entering human-subjects data. Secure IRB or equivalent ethics-committee approval (or documented exemption/determination) and any required informed consent before you use the Service to collect, enter, or process data about human subjects.

• Comply with the Common Rule and institutional policy. Conduct all research through the Service in compliance with the Common Rule (45 CFR 46), your institution's human-subjects and research-ethics policies, applicable funder requirements, and all other applicable law (Fact Register §G).

• Keep IRB records accurate. IRB fields you enter (protocol number, approval status, approval date, confidentiality procedures, and notes) are your representations; keep them accurate and current. Be aware these fields are transmitted to the AI provider when AI features are used (Section 3, Fact Register §C).

• Research about minors. If your research involves data about minors, comply with all applicable requirements for research with children, including parental/guardian permission and assent as required by your IRB and the Common Rule, and any applicable privacy law. The Service treats minor data only as participant/research data entered by an adult researcher; it is not designed to collect data directly from children (Fact Register §G — COPPA).

consistent with the ToS's IRB-responsibility clause, and confirm the COPPA framing (research about minors, not children as users) is adequate and whether any COPPA-specific notice is required.

8. Research integrity

You must not use the Service to compromise the integrity of the research record. Specifically, you must not:

• fabricate, falsify, or manipulate data, observations, sessions, or results;
• create false, backdated, or misleading study records, protocols, or IRB entries;
• circumvent, evade, or misrepresent IRB oversight or approval status;
• misattribute authorship or contributions, or misappropriate another researcher's data or designs; or
• use the Service to facilitate research misconduct as defined by your institution or your funder.

Suspected research misconduct may be reported to your institution's research-integrity or compliance office where we determine reporting is appropriate or legally required (Section 10).

9. Account security and accurate attribution

• Safeguard your credentials. You are responsible for keeping your account credentials confidential and for all activity under your account. Authentication is by email and password or a 6-digit email one-time code; the Service does not currently offer single sign-on (SSO) or multi-factor authentication (MFA) (Fact Register §E). Choose a strong, unique password and protect access to your email account. Notify us promptly at [email protected] if you suspect unauthorized access.

• One account per researcher; do not share accounts. Each researcher must use their own unique account. Do not share, transfer, or use a shared/generic login. This is required so that activity in the Service is attributed to the individual who performed it, which supports the integrity of the research record and accountability among collaborators.

• Understand the limits of the activity record. The Service maintains an internal activity feed that attributes certain actions to accounts. Be aware — and do not overclaim to your IRB, institution, or a journal — that this activity feed is not a tamper-evident, append-only, 21 CFR Part 11-grade audit trail: it is user-immutable but can be updated/coalesced and backfilled by service processes, does not record old/new field values, and does not capture all event types (for example, it omits certain authentication, access, and export events and some activity in personal studies) (Fact Register §F "A6"). If your research requires a formal, regulator-grade audit trail, you must maintain your own records; do not rely on the Service's activity feed as one.

feed's limits are correctly positioned in the AUP (vs. the IRB Data Management Policy / Security Overview), and that describing these limits here does not create a warranty of what the feed does capture.

10. Enforcement

We may investigate suspected violations of this AUP and may take any action we consider appropriate, including:

• issuing a warning or requesting that you remediate;
• removing, disabling, or restricting access to content that violates this AUP;
• suspending or terminating your access to the Service or your account; and
• where we determine it is appropriate or legally required, reporting the violation to your institution's compliance, research-integrity, or IRB office, to a funder, or to law enforcement or a regulator.

Where practicable we will give notice before suspending or terminating access, but we may act without prior notice where we reasonably believe a violation poses a risk of harm, legal exposure, security compromise, or a breach of a prohibition in Section 5. Enforcement is at our discretion and our decision not to enforce a provision is not a waiver of it. Enforcement under this AUP is subject to, and does not expand, the limitation-of-liability, dispute-resolution, and governing-law terms of the ToS (Pennsylvania governing law) (Fact Register §A/D1, §A/D5).

regulators — when reporting is permitted vs. required, what disclosures are appropriate, and whether any notice-to-user obligation should attach — and confirm suspension-without-notice and the reservation of remedies are consistent with the ToS and applicable consumer-protection law.

11. Changes to this Policy

We may update this AUP from time to time. When we make material changes we will update the version and effective date above and provide notice as described in the ToS. Your continued use of the Service after an update takes effect constitutes acceptance of the updated AUP.

note that consent capture at signup and re-consent on material change are not yet implemented in the product (Fact Register §F "A4") — the notice mechanism should not assume they exist.

12. Contact

Questions about this AUP, or reports of suspected violations, may be sent to [email protected] (Fact Register §A/D7).