Our commitments to your students.

We are a school official, not a data broker.

OneTeam handles student data only on behalf of the school under FERPA's school-official exception. We do not sell, rent, share, or otherwise transfer student data to advertisers, data brokers, researchers, or any third party outside the school's instance.

Student data never trains AI.

Student records, check-ins, notes, and tier history are never used to train, fine-tune, or evaluate AI models — by us or by any sub-processor. This applies for the duration of the agreement and to any future product feature; any change requires written notice and the school's consent.

All student data lives in the United States.

Compute and storage are pinned to US data centers (Supabase us-west-2 for the database; Vercel iad1 for compute). No part of the request path or stored payload leaves the United States. We will only change this with written notice and the school's consent.

Parent access is built in.

Parents can see, download, correct, and delete their child's record directly in the app. Right-to-inspect and right-to-deletion are first-class product features, not a support workflow.

No public scoreboards. No classroom projection.

OneTeam is designed for private use on a teacher's phone and a parent's phone. We do not build leaderboards, classroom-projection screens, or any UI surface that displays one student's data to another student. We will not build these features in the future.

MTSS tier is admin-only — never on parent or teacher dashboards.

A student's MTSS tier is sensitive even within the school. OneTeam shows tier assignments only to authorized school administrators. Tier is never displayed on classroom-teacher dashboards, on parent screens, or anywhere a student or another student's family could see it. This is enforced in the iOS app and reinforced by Row-Level Security policies on the underlying tier history table.

Deletion on request, no questions asked.

A parent or school can request that we permanently delete a student's entire record at any time. We delete it within 7 days and provide written confirmation including row counts. Existing access is built into the product (server endpoint + admin UI) so requests do not depend on us writing custom scripts.

Right to inspect — built in, not promised.

Parents can download their child's complete record at any time as a CSV file (multi-section, opens directly in Excel, Numbers, or Google Sheets). The export is rendered live from the database, not a manually prepared report, so parents see exactly what we hold.

Change-of-control re-consent.

If OneTeam is ever acquired, sold, or transferred, the new owner must obtain fresh, affirmative consent from each parent within 60 days. Records belonging to parents who do not consent will be permanently deleted, not migrated to the new owner.

Sub-processors, named and limited.

Three sub-processors handle data on our behalf: Supabase (Postgres database, authentication, and transactional auth email — us-west-2), Vercel (serverless compute, iad1), and Microsoft Teams (parent notifications, only if a teacher opts in to a school-controlled webhook). We will publish written notice 30 days before adding or changing any sub-processor.

Audit log, not just promises.

Every read of a student's exported record, every change to roster or access, and every right-to-deletion event writes an immutable, admin-readable audit row. Schools can request the audit trail for any student, at any time.

Data minimization is the default.

OneTeam collects what's needed for MTSS decisions: check-ins, goals, attendance, intervention progress. We do not collect biometrics, geolocation, browsing history, social-graph information, or any data not directly required for the educational decision being supported.

Behavioral data has a half-life.

Behavioral check-ins, tier history, and cycle evaluations are eligible for automatic deletion after 2 academic years by default. Schools can configure shorter retention. Records do not follow students across schools or accumulate into a "permanent file."

These are commitments, not just hopes.

Where it’s technically possible, each promise above maps to a specific feature or piece of infrastructure (audit log, region-pinned compute, RLS-isolated webhooks, MFA-gated deletion, etc.). Where it requires legal language, the equivalent clauses appear in our Data Privacy Agreement (DPA). Schools can request the DPA at any time.