School DPA — summary

This page is a plain-language summary for administrators. It is not legal advice; your counsel should review and execute a formal DPA if required. We do not assert that the product is “COPPA compliant.”

Subprocessors

Core hosting (e.g. Vercel), database (e.g. Neon/Postgres), optional KV for rate limits (opaque salted client keys), email (e.g. Resend), and AI inference (Anthropic) may process data according to their terms. Platform edge/CDN logging of request metadata (including IP) can occur before application code runs; treat it as bounded operational logging disclosed here, not as student tracking joined to roster records. Restrict environment variables and access to production systems to school-authorized staff.

Student data

Student accounts avoid email, legal-name requirements, and date of birth. Identity is class-scoped display nickname + PIN hash. Teachers attest a school-responsibility statement before enrollments open. Schools remain responsible for roster policies and parental notice/consent as their counsel requires. Retention of inactive student projects is teacher-configurable (new classes default to a finite inactivity window); enrollments are retained after project purge.

Controls and residual risk

Write-path redaction and teacher name-signal review reduce volume of personal information in free text; they do not eliminate it. Simulated persona discovery replaces real interview transcript storage. A determined student can still type identifying text into free-text fields — say that honestly in your district agreement rather than overclaiming.

Privacy Policy · Terms of Service