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. A rostered student who signs in with a printed badge card or a secret number has no email on the path at all.
• 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.
• Small-group intervention records (teacher-only): when a teacher accepts a recommendation to pull a small group of students who share a common error pattern, we store which students were grouped, the error tag (a fixed label from a closed vocabulary, not free text), and any linked short pre/post checks. Visible to the assigning teacher and school/district administrators only, not to other students or parents through the app.
• Accommodation flags: if a teacher records accommodations (read-aloud text-to-speech; printed phonemic-awareness variant for deaf/hard-of-hearing students; MLL glossary language), these flags travel with the student record. We do NOT import or store the underlying IEP or 504 document.
• Pseudonymous assessment research records (no name, no email, no class reference): when a student finishes a Grow administration, a record is written to our research records containing enrolled grade, item-level responses, item signatures, response times, and reliability. Each record carries the student's opaque account identifier, so a deletion request reaches it and so the pre-registered research analyses can be run; it is pseudonymous, not anonymous. The Firestore security rule on this collection permits reads only by our platform administrators — no student, teacher, parent, 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 pseudonymously, keyed to the same opaque student identifier. (A post-Grow teacher alignment survey was retired in September 2026; ratings and notes collected before then are kept under the research window below.)
• Class roster: when a school imports a OneRoster CSV export, the student names, grades, IDs, and emails are stored as the class roster; a teacher who types a roster enters a first name and last initial only. A roster entry a student has signed in to is kept, with no automatic time limit, until the school or teacher removes the student from the roster. An entry no student has signed in to is hard-deleted 180 days after it was added or last re-imported. Each rostered student without a school email has a class sign-in card; its QR code and 6-digit secret number are stored in readable form so the teacher can reprint a lost card, readable only by the teacher, the school's administrators, the student whose card it is, and our platform administrators.
• Access audit log: when a teacher, admin, parent, or platform administrator opens a screen of the app that shows an identifiable student record, the app writes one row containing the reader's UID and role, the data category, the affected student ID, and a timestamp. Opening a whole class list writes one row for the class, not one per student. 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. Our public information pages (this Growing Standard website and the Potato Class privacy, terms, support, security, and school-notice pages) count page views in aggregate with Vercel Web Analytics: it sets no cookies, follows no one from page to page or site to site, and keeps no identifier longer than 24 hours. Each view records the page address (never its query string), the referring site, the browser, operating system, and device type, and an approximate location to the city level that Vercel derives from the connection. The Potato Class app that students use loads no page analytics, and no student data is ever sent to it. Local browser storage is used for app state only and is scoped to our domain. The iPad app keeps a device-local copy of the signed-in student's own progress data in its sandboxed private storage so practice keeps working offline; offline activity syncs to the student's record when the device reconnects.

• 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 pseudonymous research records 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 (region us-central1, Iowa). SOC 1, SOC 2, SOC 3 certified.
• Cloudflare Workers: server-side proxy for the roster and badge-card API (so no secret reaches the browser), plus a text-to-speech proxy that forwards pre-scripted AiPa phrases to OpenAI for synthesis and caches the resulting audio. It also sends the emails listed under Resend below. Student records are stored in Firebase, not at Cloudflare; Cloudflare keeps operational request logs. 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 student account identifiers. A greeting may include a student's first name or, for a signed-in adult account-holder (teacher or parent), their display name; a student's surname is never synthesized. 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: narrow uses only. (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, plus any individual greeting names (student first names / adult account-holder display names) synthesized once on first use. No answer, response, or performance data is in the cache. (2) An instructional-artwork cache for the digital library (book art — no user data). (3) Anonymous crash diagnostics from the iPad app (Apple MetricKit payloads: call-stack data, app/OS version, device model — never profile, account, or answer state). (4) Quote requests: the quote form on this site sends what you enter (organization, name, role, email address, country and state, student count, plan, start date, rostering system, and notes) to our server, which stores it here together with the sender's network address and browser type, and emails it to us through Resend. No student data is involved.
• Vercel: static web app hosting for potatoclass.com and growingstandard.com. Requests are TLS in transit; no persistent student storage. Vercel Web Analytics counts page views on our public information pages only, in aggregate and without cookies (described above); it never runs in the student app.
• OpenAI — used only for AiPa text-to-speech phrase synthesis (OpenAI's gpt-4o-mini-tts speech model). 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. A greeting may interpolate a student's first name or, for a signed-in adult account-holder (teacher or parent), their display name; a student's surname is never synthesized. For the top ~2,300 US first names these renderings are pre-baked into cache and never trigger a runtime API call. Any other greeting name renders via the OpenAI API on first encounter and then caches. Audio is cached on Cloudflare R2 by content hash, so most phrases are served from cache rather than re-synthesized. If synthesized audio is unavailable for a phrase, the device's built-in synthesizer serves as the structural fallback, so the product functions fully without a live call.
• Sentry: error monitoring for the web app and for our server code, hosted in the United States. Before a browser error report is sent, an on-device filter rebuilds it from a short list of permitted fields. It replaces email addresses, phone numbers, Social Security numbers, street addresses, long runs of digits, record identifiers, anything in double quotation marks, and any other quoted text of more than one word, inside the error message with placeholders, and it leaves out user identity (email, username, IP address), request cookies, the address of the page that linked to ours, and console output. The filter works by pattern: it cannot recognize a name that stands alone, or as a single quoted word, inside an error message. Session Replay is off. The browser and our server send error reports only, no performance timings. Before our server sends a report, it removes the request's contents, headers, cookies and query string, and replaces identifiers and email addresses in the error text. Reports from the browser and from our server may carry a school or district identifier. The iPad app does not use Sentry (its crash diagnostics are item 3 under Cloudflare R2).
• Resend: email delivery. Resend receives the recipient's email address and the message. The messages are: a welcome message to a new adult account-holder, invitations to teachers and school administrators, the signed copy of a school's agreement, license and billing notices, and, for family accounts, the confirmation a parent receives after giving consent for a child, which states the child's name. We do not email students.
• Stripe: hosts checkout and holds payment details for family and individual-teacher subscriptions and for a school's card or ACH payment of a renewal. No student data is shared with Stripe.

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.
• Classmates in the same class: the app shows them each other's display name, grade, star count, and potato character. In a group activity, the members of a group see each other's responses.
• 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. Reads made through the admin screens are 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:

• Pseudonymous assessment research records, external benchmark imports, retest pairs: 3 years after the record's timestamp, then tombstoned to a non-identifying stub.
• Classroom memberships, per-question assessment responses, help requests, small-group intervention records, 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 entries: an entry a student has signed in to is kept, with no automatic time limit, until the school or teacher removes the student from the roster; an entry no student has signed in to is hard-deleted 180 days after it was added or last re-imported.
• 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.
• Parental consent and teacher agreement records (consent evidence): retained for the life of the account they document, because the COPPA Rule requires us to be able to prove verifiable parental consent was obtained (16 CFR §312.5). When the account is deleted — or a child's data is deleted on request — the child's name is redacted from the consent record when we carry out that deletion, in line with the amended COPPA Rule's data-retention and minimization requirements (16 CFR §312.10). The redacted record (parent contact, consent text and version, timestamp) is kept for 7 years after that deletion event as evidence the consent existed, then permanently deleted. Consent evidence is never retained indefinitely.
• 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 spans every per-student collection enumerated in our data inventory — the child's profile and progress, practice and assessment results, class and intervention records, help requests, usage records, the log of who viewed the record, and the parental-consent records; 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 age out of every lane within 30 days after the production hard-delete completes — in the worst case about 65 days after the deletion request (up to 5 business days to soft-delete, up to 30 days to hard-delete, up to 30 days of backup-lane retention). 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 and review education records and to request amendment; deletion requests are honored under COPPA and our agreements with schools. 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.

See the DPA details below 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.