Data Handling & Privacy
Our Commitment
The platform authenticates no students and collects no verified student identity. Any name shown is a self-entered, unverified display name with no link to institutional identity, records, or grades. AI conversation content is processed through the institution's own AI provider account.
No student email, student ID, demographic data, or grade is stored in any sub-processor system. IP addresses are processed transiently for rate limiting and expire within 60 seconds. Conversation content is routed through each institution’s own AI provider relationship (bring-your-own-key).
Design Constraints
The following constraints are enforced by design and must hold true for this privacy posture to remain valid:
- No authentication of students. The student runtime never verifies identity. There is no roster, no SSO, no student account.
- Name is an unverified display name. The student types a free-text name used only to label their session and messages in the UI. It is not validated, matched, or linked to any institutional record.
- No student record fields. The system collects no email, student ID, demographic, or grade data for students. IP addresses are processed transiently to rate-limit the student endpoints and expire within 60 seconds.
- No grade/assessment linkage. Conversations are not tied to grades or institutional outcomes.
- BYO-key data flow. AI request/response content is sent to the institution's own provider account (their Claude/OpenAI/Gemini key), not a vendor-owned account.
What Is Stored
- Simulation definitions (company, personas, assignment) — authored by instructors, not student data.
- Student conversation transcripts — stored only under the self-entered display name, with no link to verified identity. Encrypted at rest (platform-level, via the database provider) and TLS in transit.
Sub-Processors
| Sub-Processor | Role | Data Categories | Location | Notes |
|---|---|---|---|---|
| Clerk | Authentication & organization management | Institution admin and instructor accounts only (no student accounts) | United States | Students are never authenticated; Clerk handles only institutional (admin/instructor) identity. |
| Neon | Database (PostgreSQL) | Simulation definitions + display-name-only conversation transcripts (no verified student identity) | United States | Data encrypted at rest (platform-level); TLS in transit. |
| Vercel | Hosting & edge delivery | Request/response data in transit (transient only, no persistence) | United States | TLS enforced; no student data at rest on Vercel. |
| Stripe | Billing & subscription management | Institution billing data (payment methods, invoices); no student billing data | United States | Only institution-level billing contact; no student billing data. |
| Upstash | Rate limiting (Redis) | Request counters keyed by IP address; no names, no message content, no account data | United States | Keys hold an IP address and a request count for the length of the rate-limit window (60 seconds), then expire automatically. Used to protect the student chat and report endpoints from abuse. |
| Configured AI Provider (Anthropic / OpenAI / Google) | AI conversation processing | Conversation content (student messages + AI responses), via institution's own API key | Per the institution's own provider account | Content is processed through the institution's own provider account and key — not a vendor-managed key. |
Scope Boundary
This posture is valid as long as students remain anonymous, which is the committed product direction: professors share a link, students self-identify with an unverified display name, and no LTI, roster, or grade integration is built. FERPA compliance (DPA, retention, audit, the "school official" exception) would only become necessary if a future decision reintroduced authenticated student identity — currently out of scope.
Last updated: 2026-09-09