Current data handling

This page describes behavior visible in the current product repository. It is not a final privacy policy or a legal-compliance attestation. Do not submit real client information or other identifiable sensitive information to this development-stage product.

Information the prototype may collect

• Interest-list data. The public form stores the email address you submit and a creation time. An IP address may also be used by the rate limiter when that service is available.
• Account and sign-in data. Registration uses a name, email address, and password; the backend stores a password hash rather than the submitted password. Google sign-in can provide an account identifier, name, and email address. The account record may also store role, active or inactive account status, authentication provider, and account creation, update, last-sign-in, and tutorial-completion times.
• Practice and course data. The application may store session identifiers and timing, scenario and simulated-client context, transcript turns, state events, AI-generated feedback or evaluation output when produced, selected clips, student reflections, instructor comments, course membership, and notifications.
• LiveKit room and agent context. Starting live practice can send LiveKit a room name plus room or participant metadata derived from the session and account identifiers. Agent dispatch context can include scenario and difficulty data, the simulated-client and avatar profile, the assembled system prompt and behavior modifiers, and configured avatar, voice, display-name, render, or director identifiers and settings.
• Historical response-latency field; new writes disabled. The database schema can retain a field named response_latency_ms on conversation rows, and existing rows may contain values produced by earlier builds. The current application runtime no longer computes or writes this field during session ingestion. Its presence does not establish research consent or authorize research extraction or use.
• Historical session-pseudonym field; new generation disabled. The database schema can retain a field named anon_session_id, and existing rows may contain deterministic hashes produced by earlier runtime or backfill behavior. The current application runtime no longer generates or writes this field for new sessions. The field name and hash are not proof that an identifier or linked records are anonymous or de-identified, and they do not authorize research use or export.
• Instructor authoring data. The application may store instructor-linked module drafts and published modules, avatar drafts and published versions, avatar profile, appearance, and voice configuration, scenarios, briefings, rubrics, generation requests, results, logs, and errors, and creation, update, and publication times.
• Operational metadata. Authentication and audit paths may store IP address, user agent, account or resource identifiers, request path, status, timing, and token-session metadata.

Browser storage and sign-in cookies

The application uses cookies for access and refresh tokens, role and tutorial state, temporary Google OAuth state, and a separate temporary Google OAuth continuation-destination cookie that stores the requested post-sign-in path. Both temporary OAuth cookies are set for up to ten minutes. The current code does not read or write the retired research-prompt local-storage flag; a value from an earlier build may remain in an existing browser until it is cleared, but the current application ignores it. These mechanisms are product state, not evidence that a final cookie or consent policy has been approved.

AI-assisted authoring, previews, voice, providers, and media

AI-assisted module and avatar authoring and preview-script generation can send instructor-entered module or avatar context to external language-model providers. Configured avatar, render, and voice paths may send scripts, media, avatar or voice identifiers, and related context to external providers; the current standalone avatar preview path can return a script-only preview rather than rendered video. A live practice path can send the LiveKit room and agent context described above, microphone audio, text, and generated output through providers for real-time transport, language-model processing, avatar rendering, hosting, and databases. The repository also contains a local-development audio-recording path. Production capture scope, provider retention, object storage, backups, and deletion behavior have not been approved. This notice therefore does not promise that audio or video is never stored.

Site analytics and error telemetry

Vercel Analytics is mounted across the application for automatic page and route analytics. Sentry client code is present, but error and performance export and browser replay sampling are code-level disabled in the current browser, server, and edge configurations; deployment configuration alone cannot enable them. No custom Vercel event payload is configured in the root layout. Exact provider-collected fields, deployed state, retention, and contractual terms have not been established by this repository review.

Access is not yet production-attested

The intended product boundary gives students access to their own work, gives a System Admin an explicit global-read capability, and limits an instructor to the instructor's exact institution and assigned class. The current implementation has not passed the required instructor-scope or sensitive-read audit gates. Service operators and providers may also process data to operate the product. Do not rely on a narrower access or complete access-logging guarantee today.

Research use is not approved

Historical research-consent records may remain and can include a consent-record identifier, the linked account or user identifier, the selected tier and notice version, grant and revocation times, active or revoked status, a pseudonymous user identifier when present, and the request IP address and user agent captured by earlier behavior. The current application does not offer new research enrollment or consent grants. An authenticated grant request is rejected, while an existing active consent record can be read or revoked. Revocation updates its status and time and records the actor, resource, outcome, and whether a row changed; it does not newly collect IP-address or user-agent data for that action. The current runtime exposes no research extraction, export, anonymization, or derived-metric implementation. Existing records and fields do not authorize research use. This page makes no anonymity, de-identification, research-participation, or publication guarantee.

Retention, deletion, and contact are unresolved

No retention schedule, deletion service level, backup treatment, or end-to-end verified self-service erasure flow has been approved. The current product cannot promise that a Settings action erases every transcript, evaluation, clip, derived output, provider copy, or backup. A canonical legal entity and verified public privacy contact also remain owner- and counsel-gated, so this page does not publish a personal or unapproved address in their place.

No compliance claim

This engineering notice does not claim FERPA, HIPAA, GDPR, IRB, WCAG, or other legal or regulatory compliance. Counsel, institutional review, and behavior-specific validation remain separate external gates.