Student and school privacy notice

Privacy at Charlotte AI

Effective and last updated: August 18, 2026

Charlotte AI is a school-directed literacy learning service provided as part of Charlotte Learning. This notice explains, in plain language, what information the service handles, why it is needed, who can access it, how artificial intelligence is used, and what schools and families can do about their information.

An important clarification about student identity information

The current service uses a student name and email address for enrollment, invitations, sign-in, and linking one student account to the correct classes. We therefore do not claim that Charlotte never processes names or email addresses. New classrooms use a school-held recovery key so those identity fields are stored as encrypted values rather than readable roster data. Older or specially configured standard classrooms may store names and email addresses in readable form. The sections below explain both modes.

No student AI chat

Students cannot message, prompt, or hold a conversation with an AI model.

No ads or data sale

Student data is not sold, rented, used for targeted advertising, or used to build commercial profiles.

School-held roster key

New-class names and emails are encrypted with a recovery key Charlotte does not retain.

School-directed use

Teachers choose the materials, assignments, classes, and instructional uses of the service.

Local safety flags

Written responses can be locally flagged for teacher review when they suggest urgent safety concerns.

A clear boundary

Students do not talk to the AI

Charlotte AI is not a student chatbot, companion, social network, or open-ended advice service. A student does not see a prompt box for an AI model and cannot send messages to an AI model. Students see only the reading material, questions, explanations, and practice activities made available through their class.

AI controls are available only in teacher-facing or server-side instructional workflows. Teachers decide what source material to use, what class and grade level the work is for, whether generated material should be edited, and whether an assignment should be published. Some teacher-enabled workflows can generate additional practice after student activity, but the student still does not provide an AI prompt or enter an AI conversation.

What AI may help teachers do

Create draft literacy questions from teacher-provided reading material.
Suggest age-appropriate vocabulary, comprehension, prediction, and written-response practice.
Create additional at-home practice using source text and skill-level performance patterns.
Organize a teacher-uploaded roster spreadsheet into name and email columns.
Summarize class performance and suggest possible follow-up or a mini-lesson.
Draft the narrative portion of an optional weekly teacher analytics email.

What AI is not allowed to do in Charlotte

Hold a conversation with a student or accept a student-authored AI prompt.
Provide counseling, medical advice, mental-health advice, or crisis support.
Diagnose a disability, learning disorder, medical condition, or behavioral condition.
Make enrollment, placement, disciplinary, special-education, or other high-stakes decisions.
Replace the teacher's professional review of generated instructional material.
Use student information for advertising or unrelated commercial profiling.

Information sent in AI-assisted workflows

The exact input depends on the tool. Assignment generation can send the teacher's uploaded reading text, title, grade level, instructional focus, and standards reference. Additional practice can send reading text, earlier question prompts, and skill areas that need practice; it does not need the student's name or email. The weekly email narrative uses anonymous labels such as “Class 1” and “Student 1” with aggregate participation, accuracy, and question-type statistics. The final email sent to the teacher can contain real student names, but those names are added after the AI narrative is generated.

Roster imports are parsed locally by default and the on-demand class summary uses anonymous student labels and generic assignment labels. Charlotte does not send student names, student emails, classroom names, assignment titles, or raw student answer text to the on-demand class summary prompt. The roster-import AI assistant remains disabled unless Charlotte has reviewed the school use case and confirmed the required OpenAI zero-data-retention controls for the project. Teachers should use only school-approved files and should never place medical, special-education, disciplinary, family, or other highly sensitive information in an upload, class title, assignment title, or roster file.

Charlotte currently uses the OpenAI API for these features. OpenAI states that API inputs and outputs are not used to train its models by default. API content may still be retained in abuse- monitoring logs for a limited period under OpenAI's applicable data controls. See OpenAI's API data-control documentation.

Teacher review remains essential. AI output can be incomplete, inaccurate, biased, or unsuitable. Teachers can review and edit generated material before publication. Multiple-choice responses are scored against the answer key in the assignment; open-ended responses remain available for teacher review and grading.

Safety response

Written-answer safety flags

Charlotte is not an emergency, counseling, or mental-health service. Because students can type written reading responses, Charlotte locally checks submitted answers for clear signals of self-harm, violence, or abuse/exploitation. This check is deterministic and happens inside the application; student crisis text is not sent to an AI provider for this safety screen.

If a response is flagged, Charlotte saves the answer with safety-flag metadata, records an audit event, shows the student a brief notice to tell a teacher or trusted adult, and surfaces the flag in teacher response views, progress views, and CSV exports. The flag is a routing signal for human review, not a diagnosis or a final determination. Automated checks can miss context or flag a classroom-literature response that is not actually a personal safety issue.

Schools remain responsible for their own student-safety, mandated-reporting, emergency-response, parent/guardian-notification, and record-handling procedures. Teachers and administrators should follow school policy promptly whenever a safety flag appears or when any student communication independently raises concern.

Data inventory

Information Charlotte stores or processes

Charlotte limits collection to information used to provide accounts, classroom access, instructional content, learning activity, security, teacher reporting, support, and service operations. Depending on the features a school uses, the following information may be handled.

Student account and roster information

Student display name, which may be a first name, first and last name, initials, or a school-selected identifier.
Student email address used for enrollment invitations, account registration, sign-in, and class matching.
A one-way email lookup hash used to match protected enrollments without storing a readable email in the roster record.
A password hash used to verify sign-in. Charlotte does not store the student's readable password.
Student account ID, class enrollment ID, active status, and account or enrollment creation time.
Encrypted copies of names and email addresses for recovery-key protected classrooms.
Pseudonymous labels such as “Student 1” where protected classroom records need a non-identifying database label.

Classroom and instructional information

Teacher name, teacher email, hashed password, and weekly-summary preference.
Classroom name, grade level, creation date, archive status, and teacher relationship.
Assignment titles, availability and due dates, estimated duration, teacher notes, and publication status.
Teacher-uploaded reading text, extracted text, source filename, source preview, content hash, and reading scope.
Generated or teacher-edited questions, choices, answer keys, rubrics, explanations, skill tags, standards, excerpts, and page references.
At-home resources and adaptive practice materials created for a class or student enrollment.

Student learning and activity records

Student answer text, including written responses entered by the student.
Safety-flag category and timestamp when a written answer clearly signals self-harm, violence, or abuse/exploitation.
Whether an answer was correct, attempt count, first-try result, points, and whether an answer was revealed.
Session start, last-active, sign-out, and completion timestamps.
Assignment status such as in progress, partial, or completed.
Learning-progress checklist events, including whether the student opened the book, found the chapter, answered a prompt, made a prediction, or completed the activity.
Focus-loss counts and related timestamps used when an activity is configured to track leaving the activity window.
Safety flag category and timestamp when a written response appears to mention self-harm, violence, abuse, or exploitation.
Class, skill, question-type, participation, completion, and accuracy analytics derived from the records above.

Security and operational records

Short-lived secure session cookies containing account role and identifiers needed to keep a user signed in.
Hashed network or account identifiers in rate-limit records used to prevent abuse; the application does not store the raw IP address in those database records.
Cloud hosting and security providers may process ordinary request information such as IP address, browser details, time, requested page, and error information.
Audit records for account, classroom, email, and destructive actions, including actor and target IDs and limited event metadata.
Email-delivery records containing a recipient hash, subject, delivery status, provider message ID, error code, and relevant class or account IDs.
Contact-form information: name, email, grade level, optional phone number or school name, follow-up status, and submission/update timestamps.
Teacher feedback: optional teacher email, school or class, rating, strengths, struggles, and requested improvements.

Data minimization

Information Charlotte does not request as student profile fields

Charlotte does not provide dedicated student-profile fields for the sensitive information below and does not need it to provide literacy practice. Schools, teachers, and students should not place this information in names, classroom titles, assignment titles, uploaded documents, roster spreadsheets, teacher notes, or written answers.

District or state student identification numbers.
Birth dates, ages, or birth-certificate information.
Home or mailing addresses.
Student telephone numbers.
Parent, guardian, sibling, or emergency-contact information.
Photographs, facial images, or profile pictures.
Audio recordings, voiceprints, or video recordings.
Precise geolocation or continuous location history.

Medical, health, counseling, or medication information.
Disability status, IEPs, 504 plans, or special-education records.
Disciplinary, suspension, law-enforcement, or juvenile-justice records.
Biometric identifiers, fingerprints, or retina scans.
Social Security, passport, driver's-license, or government-issued ID numbers.
Financial, payment-card, benefits, or family-income information.
Religious beliefs, immigration status, or citizenship information.
Passwords or credentials used for any other school, district, family, or online system.

Free text and uploads require care. A system cannot promise that information will never be stored if a user voluntarily types it into an open response or if a teacher uploads a file containing it. If sensitive information is entered accidentally, contact the school and Charlotte promptly so the relevant record can be reviewed and, where appropriate, corrected or deleted.

Identity protection

Recovery-key protected rosters

New classrooms are created in school-key mode. The service generates a classroom recovery key for the teacher or school to save securely. The key is used to derive an encryption key; the raw recovery key is not retained by Charlotte. Student names and email addresses are encrypted with AES-256-GCM before they are written to protected roster records. The database keeps encrypted identity values, pseudonymous labels, a salt and verifier, and one-way lookup hashes needed to match an email to the correct enrollment.

A teacher signed in to the correct teacher account must also enter the matching classroom recovery key to reveal protected roster names and emails. The key is checked for that request and is not saved as part of the classroom record. Charlotte personnel and application administrators cannot recover the readable protected roster from the stored ciphertext alone. If the school loses the recovery key, Charlotte may be unable to restore those identities.

Encryption does not make a record nonexistent. Charlotte still stores ciphertext, lookup hashes, account and enrollment identifiers, activity records, and learning records. A school that exports or reveals a roster is responsible for protecting the resulting readable copy. Older standard classrooms can store readable names and email addresses and should be treated as education records subject to the school's access controls.

Sessions and diagnostics

Cookies, network data, and automated collection

Charlotte uses necessary session cookies to keep teachers, students, and administrators signed in and to remember limited activity state. Authentication cookies are HTTP-only, use same-site protections, and are marked secure in production. Teacher and administrator sessions expire after approximately eight hours; student sessions expire after approximately six hours.

Requests to the service necessarily carry technical information such as an IP address, browser type, requested route, and time. Charlotte hashes network or account identifiers before storing application rate-limit keys. Hosting, network, and bot-protection providers can separately process request metadata and, when Turnstile is enabled, a security token and IP address to distinguish legitimate use from automated abuse. Charlotte does not use advertising cookies or third-party ad trackers in the student experience.

The activity window can record a count when a student leaves the focused activity and can end an activity after repeated focus loss. This feature does not turn on a camera or microphone, record the screen, read other tabs, capture the content of another application, or track the student outside the Charlotte activity. It records only the focus-loss event and related time.

Safeguards

How information is protected

HTTPS is required for production traffic so information is encrypted while traveling between a browser and the service.
Passwords are transformed with a one-way bcrypt hash and are not stored or emailed in readable form.
Protected roster identity fields use classroom-key encryption, and the raw classroom recovery key is not stored.
Managed hosting, database, and backup providers supply infrastructure encryption and access controls.
Teacher, student, and administrator routes perform role and ownership checks before protected data is returned.
Secure, HTTP-only session cookies reduce exposure of authentication tokens to browser scripts.
Rate limits, same-origin checks, bot protection, restricted outbound hosts, input limits, and security headers reduce common abuse paths.
Audit events and email-delivery records help investigate important account, classroom, deletion, and communication activity.
Application secrets and provider API keys are stored server-side and are not intentionally included in browser code.
Backups are maintained to support continuity and recovery, and restoration procedures are tested outside production.

No website, database, encryption method, or transmission is guaranteed to be completely secure. Schools should protect teacher accounts, use unique passwords, limit account sharing, retain classroom recovery keys in an approved secure location, remove access that is no longer needed, and report suspected misuse promptly. Charlotte reviews credible security concerns and will coordinate legally required incident notices with affected schools and users as appropriate.

Information lifecycle

Retention, archival, and deletion

RecordCurrent retention approach

Classrooms and learning recordsRemain available while needed by the teacher or school. Archiving hides a class from active views but does not delete it. Deleting a class removes its roster rows, assignments, questions, sessions, answers, and answer-level safety flags through related-record deletion.

Student accountsCan remain after one class is deleted because one student account may be linked to multiple classes. A verified school or family request is needed to review deletion of the separate account.

Teacher accountsRemain while the account and associated school use are active or until deletion is requested and verified, subject to legal or security preservation needs.

Contact requestsAutomatically deleted after the configured contact-retention period. The application defaults to 180 days and constrains the operational setting to a 30-to-730-day range.

Rate-limit recordsExpire after their security window and are removed by periodic cleanup. The scheduled privacy cleanup removes stale buckets whose reset time is more than about 24 hours old.

Email and audit recordsRetained as operational and security history while reasonably needed. Delivery logs use a recipient hash rather than a readable recipient address, although the email provider processes the address to deliver the message.

Provider copies and backupsDeletion from the live application may not immediately remove copies in provider logs, email systems, disaster-recovery snapshots, or backups. Those copies are isolated from ordinary use and roll off under provider or contractual retention schedules unless preservation is legally required.

Charlotte retains student personal information only while it has an educational, account, security, support, contractual, or legal reason to do so. Verified deletion requests are evaluated against the school's control of the education record, the student's use across multiple classes, active security investigations, legal holds, and backup limitations. Charlotte does not keep deleted information in active systems merely to build a commercial profile or to advertise to a student.

Questions and requests

School, parent, guardian, and eligible-student choices

The school generally controls school-created education records and is usually the best first contact for a parent, guardian, or eligible student who wants to understand the school's use of Charlotte. Depending on applicable law and the school's policies, a parent, guardian, or eligible student may ask the school to inspect, obtain, correct, or delete relevant records or to explain the school's authorization for use of the service. Charlotte will assist the school with a verified request as required by the applicable agreement and law.

A direct request to Charlotte should identify the school, teacher, classroom, student account email, and type of request, but should not include a password, classroom recovery key, medical record, identity document, or unnecessary student information. Charlotte may need to verify the requester and coordinate with the school before disclosing or changing a school-controlled record. That verification protects the student from an unauthorized person requesting access.

School authorization and children under 13

Charlotte is intended for educational use authorized and directed by a school, district, or teacher acting within school policy. Schools are responsible for determining whether they can authorize the service, providing any notices, obtaining any consent that their circumstances require, and ensuring that teachers use only approved student information. School authorization for a child under 13 must be limited to the educational context and cannot authorize an unrelated commercial use of the child's information. If a school cannot provide the required authorization, it should not enroll the student until the appropriate permission is obtained.

This product notice does not replace a school's FERPA annual notice, acceptable-use policy, parental consent form, student-data privacy agreement, records-request process, or any notice required by state or local law. FERPA rights are administered through the educational agency or institution. Families can learn more from the U.S. Department of Education's FERPA overview and the Federal Trade Commission's COPPA guidance.

Shared responsibility

What schools and teachers should do

Obtain district or school approval before enrolling students or uploading school records.
Provide families with the notices and choices required by school policy and applicable law.
Enter only the minimum student name and email information needed for enrollment.
Do not upload district IDs, medical details, IEPs, disciplinary information, family information, or passwords from another system.
Review roster spreadsheets before using AI-assisted import and remove columns Charlotte does not need.
Use non-identifying classroom and assignment titles where practical.
Review AI-generated questions, answers, explanations, rubrics, and summaries before relying on them.
Review student safety flags promptly and follow school escalation, mandated-reporting, and emergency procedures.
Store each classroom recovery key in a school-approved password manager or similarly secure location.
Do not email, post publicly, or place a classroom recovery key in an assignment or student message.
Delete obsolete classes and materials rather than leaving them archived indefinitely.
Promptly notify Charlotte of an unauthorized disclosure, lost account, or suspected security incident.

Contact

Privacy questions, requests, and concerns

For a privacy question, a verified access/correction/deletion request, or a suspected privacy or security issue, contact the school first when the matter concerns a school-controlled student record. Charlotte can also be reached at hello@charlottelearning.ai.

Charlotte may update this notice when the product, providers, legal requirements, or data practices change. Material changes will be reflected by a new effective date and, where appropriate, communicated to schools so they can provide any additional notice or choice that applies to their community.