Student data, in plain language.

What we store depends entirely on how the student uses Potato Class. The three modes below cover every scenario.

For schools and districts on a license, this is the complete list of what we store. Every category corresponds to a specific Firestore collection in our backend; the same list is mirrored in the data inventory we share under DPA.

• Student identity: display name (first name or chosen handle), enrolled grade, classroom IDs, and an opaque Firebase user ID. Email and Google/Apple display name are mirrored from the sign-in service. For Clever/ClassLink districts, we also receive the Clever or ClassLink user ID, school ID, and district ID.
• Game progress:star total, items in the student's collection, accessory equip state, character customization, lesson progress, shelf decor, sequence progress.
• Math & reading practice: per-skill attempts, correctness, hint usage, time on task. Used to surface mastery and to drive adaptive practice.
• Math & reading assessment results (Grow): per-domain proficiency, per-question response with selected answer, correctness, item difficulty, response time (used solely for rapid-guess detection per Wise & Kong 2005 — never for behavioral profiling), reliability metrics (split-half, KR-21), testing-window history, and growth across windows.
• Help-request signals: when a student raises a hand during a class test, the request, timestamp, and resolved-by-teacher state are stored against the test.
• MTSS / intervention tracking (teacher-only): the tier (1/2/3), intervention flags (e.g., reading intervention, math small group), and teacher-authored notes (free-text). Visible to the assigning teacher only, not to other students or parents through the app.
• Accommodation flags: if a teacher records accommodations (TTS, simplified language, reduced choices), these flags travel with the student record. We do NOT import or store the underlying IEP or 504 document.
• Anonymized assessment analytics (no name, no email, no class reference): when a student finishes a Grow administration, an anonymized record is written to our research collection (`normData`) containing enrolled grade, item-level responses, item signatures, response times, and reliability. The Firestore security rule on this collection denies all client reads — no student, teacher, or visitor can pull it back. Used for psychometric calibration only.
• External benchmark imports (optional, teacher-uploaded): if a teacher chooses to upload iReady, MAP Growth, Star, or Virginia SOL scores for concurrent-validity comparison, those numeric scores plus the source label sit in a per-student collection. Names and emails are stripped at upload (any PII is rejected before write).
• Research opt-in (teacher / student): if a teacher opts in to the test-retest reliability study, paired theta scores are stored anonymously. If a teacher fills out the post-Grow alignment survey, their ≤200-character note plus an alignment rating is stored.
• Roster import staging (Clever/ClassLink): when a Clever or ClassLink district pushes a roster, the student names, grades, IDs, and emails land in a transient staging collection. After successful match into the classroom roster, the staging row is hard-deleted within 30 days; unmatched rows are hard-deleted within 180 days.
• Access audit log: every read of an identifiable student record by a teacher, admin, parent, or platform administrator writes one row containing the reader's UID and role, the data category, the affected student ID, and a timestamp. No scores, no answers, no free-text. Retained to make data-access history auditable in line with FERPA §99.32.
• Data-request queue: parent-initiated and teacher-initiated export and deletion requests are queued so the platform admin can fulfill them with an audit trail.

What we never collect, in any mode: home address, phone number, date of birth, Social Security number, biometric data (no face, voice, or fingerprint capture), photos, contacts, precise geolocation, browsing history outside the app, or device advertising identifiers. We do not use cookies or pixels for cross-site tracking. Local browser storage is used for app state only and is scoped to our domain.

• To place students at the right instructional level.
• To show teachers progress reports and class dashboards.
• To run the game itself (track practice progress, save the student's collection and customization, persist work across sessions).
• To diagnose bugs and improve the product in aggregate.
• To calibrate the adaptive assessment using the anonymized analytics stream described above.

• Google Firebase (Firestore + Auth): primary data store for everything described above. Authentication identity provider (Google, Apple, anonymous, custom token). Hosted in the United States multi-region (us-central1). SOC 1, SOC 2, SOC 3 certified.
• Cloudflare Workers:server-side proxy for Clever and ClassLink OAuth token exchange (so the API secret never reaches the browser), plus a text-to-speech proxy that forwards pre-scripted AiPa phrases to OpenAI for synthesis and caches the resulting audio. No persistent student storage. TTS requests contain only pre-scripted phrases authored by us (greetings, questions, hints, feedback) and never contain answers, responses, performance data, free-form student input, or account identifiers. Greeting templates may include a student's first name; the top ~2,300 US first names are pre-baked into cache and never trigger a runtime API call. The device's built-in speech synthesizer is used as a fallback when the OpenAI path is unavailable or disabled by configuration.
• Cloudflare R2: two narrow uses. (1) A pre-scripted-phrase TTS audio cache, keyed by content hash of the synthesized text. Most entries are questions, hints, and feedback; a subset covers the top ~2,300 US first names × greeting templates so a common-name greeting serves from cache without an API call. No answer, response, or performance data is in the cache. (2) Quote-form submissions from the marketing site (your school/district contact info — name, email, organization, role, message, IP, user-agent). No student PII.
• Vercel: static web app hosting for potatoclass.com and growingstandard.com. Requests are TLS in transit; no persistent student storage.
• Clever / ClassLink: optional SSO and roster providers. They send us student names, IDs, grade, and email from the district's roster when a district elects to integrate. Used as identity + roster sources only.
• OpenAI— used only for AiPa text-to-speech phrase synthesis (the tts-1model). Requests are issued by our server-side Cloudflare Worker, never by the student device; the student device makes no calls to any generative AI API. Requests contain pre-scripted phrases authored by us (greetings, questions, hints, feedback) plus a voice ID; never answers, responses, performance data, free-form student input, or any identifier tied to a student account. Greeting templates may interpolate a student's first name; for the top ~2,300 US first names these renderings are pre-baked into cache and never trigger a runtime API call. Less-common first names may render via the OpenAI API on first encounter and then cache. Audio is cached on Cloudflare R2 by content hash, so most phrases are served from cache rather than re-synthesized. A configuration flag can force fallback to the device's built-in synthesizer when an organization's data policy requires it; district deployments that prohibit third-party AI services run in fallback-only mode and are documented in the applicable DPA.

All at-rest data resides in US data centers. No data leaves the United States in normal operation.

• The student themselves.
• The student's teacher(s) and any teacher who shares the same classroom.
• School and district administrators on the licensing organization (read access only on student data; write access on roster and accommodation fields).
• The student's parent or guardian, when the student is on an active school or district license, via Settings → Data in the app.
• Growing Standard platform administrators — for support, bug investigation, or roster reconciliation. Every such read is recorded to the access audit log.

Aggregate rollups (school / district / state / national averages) are visible inside the educator portal and to platform admins. They contain no per-student data.

Our retention windows match what schools already expect from peer screening tools (iReady, MAP Growth, Star, DIBELS). The full collection-by-collection table is in our internal Data Retention Policy and is shared with districts under DPA; the high-level shape is:

• Anonymized assessment analytics, external benchmark imports, retest pairs, teacher-judgment ratings: 3 years after the record's timestamp, then tombstoned to a non-identifying stub.
• Classroom roster, per-question assessment responses, help requests, MTSS notes, lesson sequences: end of school year + 3 years, so teachers keep multi-year growth context.
• Student profiles: retained while enrolled (inferred from a sign-in within the last 18 months or an active classroom attachment), tombstoned 3 years after the last sign-in, and hard-destroyed within 60 days of contract termination.
• Roster import staging rows: hard-deleted 30 days after a successful SSO match, or 180 days if unmatched.
• Multiplayer game session state: 30 days after the game ends, then hard-deleted.
• FERPA access logs: 3 years.
• Parent / teacher data-request records: 3 years after fulfillment, to prove the request was honored.
• Soft-delete restore window: 30 days, then hard-purge.
• Aggregate (no per-student data): retained indefinitely.
• Legacy individual purchase records: 7 years for tax and accounting compliance. Individual in-app purchases were retired April 2026; no new records are written, and these do not influence runtime entitlements.

A monthly retention sweep enforces these windows and writes a per-collection report. Tombstones preserve the document ID for aggregate-counter stability but carry no PII or score data.

The school or district owns its students' data. On a written request from the school, district, or a verified parent we will:

• Provide a machine-readable JSON export of the student's complete record across all our collections within 30 days (DPA §5.5). The export bundle covers fourteen Firestore collections; the platform admin runs the scripted exporter and attaches the resulting bundle to the request log.
• Hard-destroy the student's per-student data on contract termination within 60 days. Aggregate, depersonalized analytics survive (they contain no PII).
• Fulfill individual deletion requests through the queued data-request workflow described under "Parent rights" below.

Students with school-managed accounts cannot self-delete data while the school license is active — deletion is routed through the school administrator so district records stay coherent. After enrollment ends, normal self-service deletion is available.

Backups and deletion requests. We operate three independent backup lanes for disaster recovery (described in DPA §7A.6): Firestore Point-in-Time Recovery (7-day window), Firebase-managed daily snapshots (14-day retention), and a project-isolated daily export to a separately-owned Google Cloud Storage destination (30-day retention with a bucket-level retention lock). When a deletion request is fulfilled, the data is removed from production within the timelines above. Backups taken before the deletion request retain a snapshot of the data for the duration of each lane's retention window — up to 30 days — and then age out automatically. Backups taken after the deletion request reflect the post-deletion state. We do not restore deleted data from a backup absent a specific written request from the school or district. The 30-day retention lock on the project-isolated lane is a load-bearing security control: it structurally prevents an attacker who gains administrative credentials from destroying our recovery surface, but it also means we cannot expedite removal from that lane below 30 days. All backup copies of deleted student data are gone within 30 days of the deletion request — this is an industry-standard backup- persistence carve-out and is documented in DPA §5.3.1.

• Self-serve, when the student is on a license: a verified parent or guardian can visit Settings → Data in the app to review the categories of data we store for each child, queue an export request, or queue a deletion request. Verified requests are fulfilled within 30 days.
• Without a license: parents may make the same requests by emailing privacy@potatoclass.com.
• FERPA inspection rights: parents retain the right to inspect, request correction of, and request deletion of educational records. Schools and districts contracting with Growing Standard assert school-official consent under FERPA; parental consent for educational use is handled via the school's or district's existing consent process.

• Student Data Privacy Consortium (SDPC) Universal DPA — ready to sign on request, typical turnaround 3 business days.
• State-specific DPAs (CA, NY, CO, IL, TX, MA, NJ, WA, CT) — ready to sign on request, typical turnaround 5 business days.
• District-specific DPAs — we redline and counter-propose, typical turnaround 10 business days.
• Clever Universal Data Sharing Agreement — signed upon Clever Library certification (currently in progress; ClassLink SSO + Google + Apple sign-in available today).

See the DPA details page for SLAs and standard redlines, or email privacy@potatoclass.com to start a review.

• TLS 1.2+ for all data in transit (TLS 1.3 negotiated by default with modern clients via Google Cloud and Cloudflare).
• AES-256-GCM encryption at rest (Firebase + Cloudflare).
• Hosted on SOC 2 Type II certified infrastructure (Google Cloud, Vercel, Cloudflare). Growing Standard LLC has not pursued SOC 2 Type II certification of its own application layer; we will engage an auditor when a customer contract requires it or when revenue justifies the engagement. Our interim compliance posture is demonstrated through the DPA, a HECVAT-Lite self-assessment (available on request), quarterly admin-access reviews, a documented incident-response runbook, and a multi-state privacy addendum aligned with CA SOPIPA, NY Ed Law 2-D, IL SOPPA, TX, CO, CT, NJ, MD, and WA statutes.
• Role-based access control for admin operations.
• No payment card or financial data is collected, processed, or stored by us.
• Published vulnerability disclosure policy. Full policy on the Security & Vulnerability Disclosure page, plus a machine-readable security.txt contact file (RFC 9116). Good-faith security research is welcomed under our safe-harbor statement.
• Commercial insurance:tech E&O, cyber liability, and general liability through Vouch Insurance. Certificate of insurance and coverage details available to districts under DPA.

Security researchers: report vulnerabilities to security@growingstandard.com. Full scope, safe-harbor language, and response SLAs on the Security & Vulnerability Disclosure page.