Architecture & Policies

This page is a plain-language technical and data-practices overview for school IT staff, security reviewers, and procurement teams evaluating NutriLearn for district or school adoption. It complements, but does not replace, our Privacy Policy and Terms of Service, which are the governing legal documents. Where this page and either of those documents differ, the Privacy Policy and Terms of Service control.

NutriLearn is built on a small set of established, widely-used commercial infrastructure providers rather than custom-built or self-hosted systems:

• Application: Next.js (React), deployed on Vercel.
• Database, authentication, and real-time messaging: Supabase, built on PostgreSQL.
• Both providers operate their own SOC 2 / infrastructure-security programs as commercial cloud vendors; [Add: links to Vercel's and Supabase's current compliance documentation, and confirm which data region(s) our project uses].

We do not operate our own servers or data centers. This means NutriLearn inherits the operational security practices (patching, physical security, network protections) of these providers rather than requiring a district to trust custom infrastructure.

NutriLearn is used by many schools at once, so keeping one school's data from being visible to another — and one teacher's classes from being visible to another teacher — is a core design requirement, not an afterthought.

We enforce this using Row-Level Security (RLS), a feature of our PostgreSQL database. In plain terms: access rules (“a teacher can only see classes they created,” “a student can only see and read their own game sessions”) are checked by the database itself on every query, not only by application code. Even if a bug existed somewhere in our application's UI or API layer, a student or teacher's own database session is still restricted to the rows they're allowed to see — there is no way to query around that restriction from a normal user session.

Consistent with this, students never have write access to their own score or session records — those are computed and written only by trusted, server-side code (see “Server-side scoring integrity” below), and the database itself denies any direct write attempt from a student session. We periodically review and tighten these access rules as the product evolves; access control is treated as a database-level guarantee, not just an application-level convention.

There are no cross-school data joins, comparisons, or exports anywhere in the product — every student's data stays scoped to their own school and class.

Game and challenge scores are calculated and verified on our servers from the underlying food selections, not accepted as-is from a student's browser. This prevents a student from tampering with their own score, currency earned, or leaderboard standing by modifying client-side requests.

Student accounts are created only by a teacher, from the class roster tool — students never self-register. A student logs in with a class code, a username, and a password:

• No student email address is collected or required.
• No student real name is required (teachers are advised to use a nickname or first-name-only display name).
• No date of birth, home address, or government identifier is collected anywhere in the product.
• Student-to-student communication in the game is limited to a fixed list of pre-approved phrases — there is no free-text field anywhere a student can type into.

This design reflects our approach to COPPA (the Children's Online Privacy Protection Act): because NutriLearn is sold to and deployed by schools — which review our Privacy Policy and Terms, create student accounts themselves, and control what limited information (if any) is entered — we rely on the “school official” exception recognized under FERPA and by FTC COPPA guidance for education technology vendors, rather than collecting per-student parental consent directly. See our Privacy Policy for the full legal basis and details of what is and isn't collected.

We retain a class's student data for as long as that class is active, so teachers can track ongoing progress. When a teacher archives a class, that data is not deleted immediately — this gives a school a window to export or reference records — but it is not kept indefinitely. Our policy is to permanently delete a class's student data no later than 90 days after the class is archived. [Add: current implementation status of the automated retention/deletion process, once verified and tested — do not describe automated deletion as already running unless it has actually been confirmed in this codebase]. A school can also request earlier deletion of a class or specific student records at any time — see “Questions for your district” below, or our Privacy Policy.

We take a small number of concrete, verifiable measures, and we'd rather state plainly what we do than imply more than is true:

• All traffic to and from the Service is encrypted in transit (HTTPS/TLS), standard for our Vercel and Supabase hosting.
• Database access is governed by row-level security policies enforced at the database layer, as described above.
• Administrative/service-level database credentials are restricted to server-side code and are never exposed to the browser or to students/teachers directly.
• We do not load any third-party analytics, advertising, or user-tracking scripts anywhere in the product — we've reviewed the source code to confirm no Google Analytics, Mixpanel, or comparable tracking script is present, for either teachers or students.
• All input to our API routes is validated before it touches the database, and user input is never interpolated directly into database queries.

[Add: current status of any third-party security audit, penetration test, or compliance certification (e.g. SOC 2, ISO 27001) — do not claim a certification or audit that has not actually been completed. If none has been completed yet, state that plainly here rather than omitting the topic.]

No online service can guarantee perfect security, and we do not claim NutriLearn is immune to all possible security incidents. See our Privacy Policy for our breach-notification commitment.

This page is a general architecture overview, not a substitute for a completed security questionnaire, a signed data-processing agreement, or legal review of our Privacy Policy and Terms of Service. Districts with a formal vendor-review process are welcome to send us their standard questionnaire directly.

IT, security, or procurement questions about NutriLearn can be sent to [Contact Email — e.g. security@[yourdomain].com].

[Company Name] — [Company Address — placeholder, fill in before publishing]