Student privacy, in plain language.
Choral Clarity builds classroom tools for middle and high school choir programs. Student privacy shaped how these applications were built — not just how they're described.
The design goal was simple: collect the least that makes the product work, and delete it on a schedule.
No student email addresses. No passwords for them to create or your IT team to provision. No app to install. A teacher adds a student to a class, the system issues a PIN, and that's the whole of it.
This page describes what the product does today. Where something is planned rather than in place, we say so.
The whole list. It's short.
For classroom use, the product may store:
- ✓ A display name, as the teacher enters it
- ✓ Class membership — which of the teacher's classes the student is in
- ✓ Assignment scores and results for work the student submits
- ✓ Audio recordings, only when a teacher assigns recording-based work
Teachers decide how students are identified — a first and last name, a first name only, or another identifier such as a student number. The application never requires a legal name, so a district that prefers pseudonymous identifiers loses nothing by using them.
There is nowhere in the application to enter any of these.
- — Student email addresses
- — Home addresses
- — Dates of birth
- — Phone numbers
- — Parent or guardian contact details
- — Government identification numbers
- — Demographic, health or disciplinary data
Alongside this, the applications keep the ordinary technical records any web application needs to run securely — short-lived sign-in session records, and counters that limit repeated failed sign-in attempts. Both are described below, including what they contain and how quickly they're deleted.
No accounts. No passwords to lose.
Teachers create and manage student access. A teacher adds a student to a class and the system generates a PIN. The student selects their name and enters it. There is nothing for a district to provision, sync, or reset centrally.
Verification happens on the server against a bcrypt hash computed with a secret that is not stored in the database. A complete copy of the database would not yield a student's PIN.
Eight-hour absolute maximum, with no sliding extension. The server holds only a one-way hash of the session token, never a usable copy.
Session records contain the hashed token, the student it belongs to, and two timestamps. No IP address, no user agent, no device fingerprint.
Repeated failed sign-ins are rate-limited. The supporting records are one-way cryptographic digests holding no readable identifiers, and they're deleted within 24 hours.
When a teacher resets a student's PIN, every active session for that student is terminated immediately.
We recently moved student sign-in to the protected-hash design above. During this transition, a copy of each student's PIN also remains stored in plaintext in the database, supporting the existing teacher workflow for issuing and re-issuing PINs, and allowing the change to be reversed if needed.
We treat that copy as authentication information. No student-facing or teacher-facing interface retrieves it, and teacher access is limited to that teacher's own students.
It will be removed by 31 December 2026, once the replacement workflow for issuing and resetting PINs is complete. After that, PINs will exist only as protected hashes and will not be readable by anyone — including us. We'd rather state this plainly than describe our PIN storage in a way that isn't yet accurate.
Everyone sees only their own.
- Teachers see only their own classes and students. A teacher cannot view, modify, or delete another teacher's roster or student work.
- Students reach only their own enrolment. A student can access their own assignments and their own submitted work, and nothing else.
- Assignment access is checked every time against the student's authorized class enrolment, rather than assumed from a link.
- A student in more than one class is handled server-side, so work is attributed to the correct class without the student choosing where their submissions land.
- Authorization decisions are made on the server. The application does not trust identity or permissions supplied by the browser.
Recordings of children get their own policy.
Audio is the most distinctive information this product handles, so it's treated separately from everything else. Recordings are created only when a teacher assigns recording-based work. Practice is never uploaded — only what a student chooses to submit reaches the teacher.
Recordings are retained for the school year in which they're created and permanently deleted on the following 1 July — from both the database and file storage.
This is a school-year boundary rather than a fixed length of time. A recording made in September and one made in May are both deleted on the same 1 July. So the honest description is nothing carries past the end of the school year — not "recordings are kept for a year."
The deletion process is built and has been tested in a rehearsal mode that reports exactly what would be removed, without removing it. Its first scheduled production run under this policy is 1 July 2027. Teachers and districts can request deletion earlier at any time.
Teachers listen to their own students' submitted work — that's what the product is for, and a teacher can only reach recordings from their own classes.
Choral Clarity does not listen to student recordings. We do not review, sample, transcribe, or analyze them, and they are never used to train or improve any software.
As the operator of the service we hold administrative access to the systems where recordings are stored, as any hosted service provider must. We do not use it to access student audio — not for support requests, not for troubleshooting, not for any other reason.
How long we keep things, exactly.
| What | How long |
|---|---|
| Audio recordings | Deleted 1 July each year — never carried past the school year |
| Scores and assignment results | Retained until you or your district deletes them |
| Student name and class enrolment | Retained until you or your district deletes them |
| Sign-in session records | Deleted within one hour of expiry |
| Rate-limiting records | Deleted within 24 hours |
| Database backups | Seven days |
| Audio backups | None — audio is not backed up |
The two ephemeral cleanup jobs run hourly and have been running continuously since 13 August 2026. The annual audio deletion is scheduled and has been tested in rehearsal mode.
Deleting a student, class, or assignment removes the records and the audio files. That sounds obvious. It's the part that most often goes wrong in software, so it's built to fail safely.
Files are removed first, then re-checked to confirm they're gone. Database records are deleted only once nothing remains. If any file can't be confirmed removed, the deletion stops and reports an error rather than reporting success. Nothing is left orphaned, and the request can simply be retried.
Closing an account removes every class, student, and recording associated with it.
Deletion removes data from the active system immediately. Short-term backups exist for disaster recovery, with a recovery window of approximately seven days. A deleted record may remain in backup for that period before ageing out.
Student audio recordings are not included in database backups. When a recording is deleted, it's gone from the active system with no backup copy remaining. We'd rather say that than let a district discover it in a questionnaire.
Today: rosters and performance records remain until the teacher or district deletes them. Audio is still deleted on the normal 1 July schedule regardless of subscription status, and deletion on request stays available.
Planned: deletion of rosters and performance records 90 days after a subscription lapses. Ninety rather than thirty is deliberate — a subscription lapsing in June may be renewed in August, and a shorter window would delete a teacher's roster over the summer.
This is not yet implemented, and we won't describe it as current practice until it is. Districts requiring a defined post-termination deletion period should raise it during contracting.
Assignment scores are currently retained until deleted by the teacher or district — there's no automatic expiry for performance records today. We're evaluating an age-based schedule. It isn't implemented and isn't in effect, and we won't present it as current practice until it is.
What's in place today.
Not a roadmap — a list of controls currently operating.
Data minimization
No student email addresses, contact details, dates of birth, or demographic data.
Server-side authorization
Every access decision is made on the server, never trusted from the browser.
Protected PIN verification
Bcrypt hashes with a server-side secret held outside the database.
Expiring session tokens
Stored only as hashes, eight-hour maximum, no indefinite renewal.
Session revocation
A PIN reset immediately ends every active session for that student.
Authentication throttling
Repeated failed sign-ins are rate-limited to deter automated guessing.
Teacher-scoped access
Teachers reach only their own classes and students.
Enrolment-scoped student access
Students reach only their own assignments and submissions.
Tested deletion procedures
Audio removal is verified before records are deleted.
Defined audio retention
An automated annual schedule, tested in rehearsal mode.
Database-enforced access rules
Access to student data is restricted by rules enforced in the database itself, not only in the application.
Change logging
Changes to systems handling student data are recorded in an internal log.
We deliberately avoid claims like "military-grade," "unhackable," or "100% secure." No software is any of those things, and a vendor who says otherwise is telling you something about their claims rather than their security.
Built to support your obligations.
Choral Clarity maintains privacy and security practices designed to support schools in meeting their obligations under the Family Educational Rights and Privacy Act (FERPA) and New York Education Law §2-d.
We do not claim certification under either. No such certification exists to hold, and a vendor claiming one should be treated with caution.
We're a small company and we read what we sign. We'll review your district's agreement and work with your privacy and technology staff through your approval process.
We expect to work through all of these:
- ✓ Data Privacy Agreements and contract riders
- ✓ Vendor security questionnaires
- ✓ Technology approval and product review processes
- ✓ Supplemental information for your Parents' Bill of Rights
- ✓ Additional requirements specific to your district or BOCES
A separate product, not part of the classroom.
Separately from the classroom product, we offer an individual practice license for adults — parents, private teachers, and singers working on their own.
That product is practice-only. It creates no student records, no assignments, and no recordings, and stores nothing from a practice session. The only data retained is the license itself and a device identifier captured at redemption, which is not linked to any student, class, or teacher. It is sold to adults and is not part of the classroom product a district would license.
Where the data lives.
Student data lives with one provider. Others deliver the application itself and the fonts and code libraries a browser loads. The difference matters, so here it is in full.
Stores student data
Supabase — database, backend services, and storage of student audio. The only provider that holds student records. Hosted in the United States, in AWS's Oregon region (us-west-2), encrypted in transit and at rest.
Stores no student data
Netlify — application hosting. Serves the code that runs in your browser; no student records are stored there.
Google Fonts, jsDelivr and unpkg — typefaces and standard code libraries. When a page loads, the browser fetches these files directly from those services. No student information is sent to them. As with any resource a browser loads from another domain, they receive ordinary connection information such as an IP address. We list them because a district checking with developer tools will see them, and we'd rather they read it here first.
These providers host data on our behalf under their own terms. Using them does not transfer ownership of school or student data. Student data remains the property of the school or district and is used only to provide the product.
One person at Choral Clarity has database access: the founder, Adam Paltrowitz. There is no support team, no analytics vendor, and no marketing tool with a path to student data. Our website, email list, and payment processing run on separate systems that never receive it.
Does your district require a vendor review?
- Students have no accounts, email addresses, or passwords. Nothing for your directory or SSO to provision.
- We store a teacher-chosen display name, class membership, assignment results, and — only when assigned — submitted audio. Nothing else.
- Audio is deleted automatically at the end of each school year, and on request at any time.
- Deletion removes stored audio before removing records, and verifies removal first.
- Nothing is installed on district devices. The applications run in a modern browser.
- ✓ Complete your privacy and security questionnaire
- ✓ Provide additional detail beyond this page
- ✓ Review your district's Data Privacy Agreement
- ✓ Supply supplemental information for your Parents' Bill of Rights
- ✓ Work directly with your technology and privacy staff
We review each district agreement rather than signing every one as presented — some contain terms a product of our size can't honestly commit to, and we'd rather have that conversation up front.
Contact us about a district reviewGet in touch.
For questions about student data privacy, security practices, or district review processes:
Choral Clarity
15 Bar Beach Road
Port Washington, NY 11050
Last updated: August 17, 2026