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. By default that means no student names and no recordings at all.
Choral Clarity does not collect student names. It does not record student voices. A class roster is a list of codes — ABC-001, ABC-002, ABC-003, using a short prefix the teacher chooses. There is no field anywhere in the product to type a name into.
Names and recordings are each available, but neither is a setting a teacher can switch on. Each requires separate signed authorization from the school or district, and we enable it for that one teacher's account only. No other account is affected.
What the product does hold is a number, a class, a PIN, and the student's scores. That list is complete.
From September 12, 2026, both permissions are held per teacher account and enforced in the database. Enabling either for one school has no effect on any other account.
In that default state nothing on COPPA's list of personal information is collected except a class-assigned number used solely to run the service — which the Rule permits without parental consent. Read the COPPA analysis → · How identification modes work →
No student email addresses. No usernames. No passwords for them to create or your IT team to provision. No app to install.
A student types the code their class assigned them — ABC-007 — and a PIN. That code and that PIN are the entire credential, and neither one says who the child is.
This page describes what the product does today. Anything not yet in place is marked Planned with its status and target. Everything unmarked is running now.
- ✓ Students are identified by a number, not a name — ABC-001, ABC-002
- ✓ No student email addresses
- ✓ No student-created usernames or passwords — sign-in is a class code and a teacher-issued PIN
- ✓ No voice recordings
- ✓ Names and recordings are each enabled only when a district authorizes them in writing, for one teacher account at a time
Enforced in the database, not by policy or configuration. The rest of this page is the complete technical explanation — nothing below contradicts the five points above.
Numbers by default. Name option available to schools by request.
An account runs in one identification mode, and one mode governs the whole account — every class the teacher creates uses it. The two modes cannot be mixed, and no class can be switched independently. Every exercise, score, and grading feature is identical in both.
Students are ABC-001, ABC-002, ABC-003 — a teacher-chosen prefix of three to six letters or numbers, unique to that teacher, followed by a sequential number. The roster is generated from a class size, so the teacher types nothing, and the interface offers no name field to type into. A student's record is that code, a class, a PIN, and their scores.
This is enforced in the database itself: a trigger rejects any student identifier that is not in code format on a numbers account, on creation and on edit alike. A teacher cannot type a name into the roster even if they try.
The key that matches a number to a child is never held in this platform. It stays in the teacher's own gradebook or the school's records, under the school's control and its existing retention rules.
Consequence for review: the platform holds no student name to inventory, disclose, or expose, and any record that leaked would identify no child without the key you hold. Some districts find this substantially narrows their review because no student name or direct identifier is disclosed to the platform — we will complete a data privacy agreement either way.
A school or district may choose to enable name-based rostering so the gradebook reads directly. It requires written confirmation from the school that name collection is authorized and that any required approvals are in place. A teacher cannot switch their own account to names — we enable it, and we record who approved it and when.
Where enabled, the platform stores a display name — a first name, or first and last, as the teacher enters it. It never stores an email address, date of birth, home address, or anything else about the student.
This is enforced on the server, not in the interface. Where names have not been authorized, a name cannot be submitted regardless of how any individual teacher configures their account.
Numbers-only is the default for accounts created since this policy took effect. A small number of teachers were already using names, or already had recordings, before it existed. We did not switch their classes off mid-year — that would have broken a working gradebook partway through a term.
As of September 12, 2026 that is six accounts using names and three using audio. Each is flagged approval outstanding and we are working through them with each school to either obtain written authorization or move the account to numbers. If you are a district reviewing an existing teacher's account, ask us for its current state and we will tell you exactly which mode it is in and whether approval is on file.
Enabling names does not enable audio, and enabling audio does not enable names. Each requires its own written administrator authorization, and each is enforced independently at the server level.
A school can therefore run recorded singing assignments while storing no student names at all — a submitted recording is attached to a number, and only the teacher's own records connect that number to a child.
What this app collects about your child.
Your child's choir teacher uses Choral Clarity for ear training and sight-reading exercises. Here is everything the app collects about your child, in plain language.
By default the app identifies your child only by a code their teacher assigns, such as ABC-007. In that mode the app holds no name for your child at all — only their teacher knows which number is theirs.
Schools can request name-based rostering instead, which requires written authorization from the school. Ask your child's choir director which mode their classes use.
The app records which of the teacher's classes your child belongs to, so their work goes to the right gradebook.
When your child submits an assignment, their score is recorded and sent to their teacher's gradebook. No other teacher can see their work.
When their teacher runs a Live Challenge in class, your child's place and score are saved by their student number, so the teacher can follow their progress. Games your child plays with friends are not saved. These results are deleted every July.
The app is capable of saving a recording when your child submits a singing assignment, but it is off, and no one at your child’s school can switch it on. It requires written authorization from the school or district, after which we enable it for that teacher’s account only. Only the take your child chooses to submit is saved; practice is never recorded. Recordings are accessible only to their teacher and are permanently deleted every July 1.
Not sure if recordings are enabled? On any assignment that saves a recording, the app tells your child before they sing — “Your teacher will hear this one.” If they have never seen that message, nothing has been recorded. You can also ask your child's choir director.
No username, no email, no password. Their teacher adds them to a class and the system creates a PIN. Your child signs in by typing their number — or their name, in schools that have enabled names — and entering that PIN. Nothing is installed on their device.
Their choir teacher sees their number or name, their class, and their scores. Your child sees their own work only. One person at Choral Clarity — the founder — has technical database access, which is not used to review student work. Student data is never sold or shared with advertisers.
Contact their choir teacher directly — teachers can remove a student at any time, which permanently deletes their number or name, their scores, and any recordings. If you cannot reach the school, contact us:
Adam Paltrowitz · Choral Clarity · 15 Bar Beach Road, Port Washington, NY 11050
The whole list. It's short.
For classroom use, the product may store:
- ✓ A student number assigned by the teacher — the default, and the only identifier in a standard account
- ✓ Class membership — which of the teacher's classes the student is in
- ✓ Assignment scores and results for work the student submits
- ✓ Live Challenge results: the student's number, place and score in each class game, saved by the teacher's own board at the end of the game. Head-to-Head games between students are not saved. Results are deleted automatically at the end of each school year (July 1).
- ✓ A display name — only where a school administrator has authorized name-based rostering in writing
- ✓ Audio recordings — only when a teacher assigns recording-based work and an administrator has authorized audio collection in writing
The last two items are separate opt-ins. In a default account neither exists, and the complete student record is a number, a class, a PIN hash, and scores.
A district that prefers pseudonymous identifiers does not have to configure anything or ask us for anything — that is simply how the product arrives. How identification modes work →
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
In a default numbers-only account, student names belong on this list too — the name field does not exist until a school authorizes it.
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 types their code — or their name, where a school has authorized names — and enters it. Nothing is displayed to choose from. 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. The hash cannot be reversed, and without that secret a copy of the database would not yield a PIN from it. One exception applies while our authentication upgrade completes — a separate plaintext copy of each PIN also remains stored, and is being removed. We set that out in full below rather than let this paragraph imply more than is true today.
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.
There is no list of students to pick from. A student types their own code in full, and the screen displays nothing about anyone — so a device left open reveals no classmate, no name, and no number.
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.
As of September 13, 2026 the stored copy is shrinking, not static. Two changes shipped that day: resetting a student’s PIN now clears the plaintext copy for that student rather than replacing it, and enrolling a student in a second class no longer copies one at all. Every reset from here permanently removes a value, and no new ones are created by either action. What remains are the copies created before that date, and the account-setup path, which is the last piece of the work.
It will be removed by December 31, 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 enrollment. 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 enrollment, 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.
- Names and audio are each gated per account, server-side. Without the permission for that specific teacher account, neither a name nor a recording can be stored — the upload is refused, the reference is stripped, and the database rejects the row.
Recordings of children get their own policy.
The Singer can save a recording when a student submits a singing assignment, so their teacher can hear it. This is off, and there is no way for a teacher to switch it on. It requires separate signed authorization from the school or district, and we enable it for that one account. The Decoder never uses the microphone at all.
Where audio is not authorized for an account, a recording is refused at three independent layers: the upload is never signed, any reference is stripped when the work is submitted, and the database rejects the row outright. None of the three depends on the browser behaving correctly.
Direct writes to audio storage from a browser are impossible: storage rules permit no client to write, and uploads are only ever signed by our server.
Practice is never recorded. Only the take a student chooses to submit is saved.
The student is told before they sing. On an assignment that will save a recording, the app shows the student a notice before they begin. It appears only where recording is actually authorized and switched on for that assignment, so a student who has not seen it has not been recorded.
Recordings are deleted every July 1 and never carried past the school year in which they were made — from both the database and file storage. Teachers and districts can request deletion earlier at any time. Audio is not included in database backups.
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. Teachers reach only recordings from their own classes.
Audio and names are independent. A school may enable recordings while remaining in numbers-only mode; a submitted take is then attached to a number, and nothing in the platform connects that number to a child.
We treat a recording as personal information in every configuration. An audio file containing a child's voice has always been personal information under COPPA, and the amended Rule expressly adds biometric identifiers — including voiceprints — to that definition.
Operational detail — how authorization is recorded, deletion procedures, and breach notification — is set out in the Data Privacy Agreement we execute with your district. The full platform works without audio: every solfège training and assignment feature is available whether it is enabled or not.
How long we keep things, exactly.
| What | How long |
|---|---|
| Audio recordings (if authorized) | Deleted July 1 each year — never carried past the school year |
| Scores and assignment results | Retained until you or your district deletes them |
| Student number and class enrollment | Retained until you or your district deletes them |
| Student display name (if authorized) | Retained until you or your district deletes it — not stored at all in numbers-only mode |
| 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 August 13, 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 associated 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 July 1 schedule regardless of subscription status, and deletion on request stays available.
Planned: deletion of rosters and performance records 90 days after a subscription lapses.
This is not yet implemented. Districts requiring a defined post-termination deletion period should raise it during contracting.
The amended COPPA Rule requires operators to maintain a written retention policy stating why children's personal information is collected, the business need for keeping it, and when it will be deleted — and to set that policy out within this notice rather than link to it elsewhere. This is that policy.
Student identifiers, class enrollment, and assignment results are collected for one purpose: to deliver aural training and music literacy exercises to a student and return the resulting scores to that student's own teacher. Audio, where authorized, is collected so a teacher can hear a submitted performance. No student information is collected for any commercial, advertising, profiling, model-training, or product-analytics purpose.
A student's identifier and enrollment must persist for as long as they are enrolled in the class, so their work continues to reach the right gradebook. Assignment results must persist across the grading period the school is running — a choral teacher assesses growth over a term or a school year, so a score from September has instructional value in May. Audio needs to persist only until the teacher has reviewed and graded the submission.
Audio recordings: deleted every July 1, never carried past the school year in which they were made. Sign-in session records: within one hour of expiry. Rate-limiting records: within 24 hours. Database backups age out at seven days; audio is not backed up.
Identifiers, enrollment, and assignment results: deleted when the teacher removes the student or closes the account, and on request at any time. We do not yet operate an automatic expiry for these records — see the open item below.
§ 312.10 also prohibits retaining children's personal information indefinitely. Today, identifiers and assignment results persist until a teacher or district deletes them, which does not by itself satisfy that standard. We are implementing a defined outer limit — deletion 90 days after a subscription lapses, and an age-based expiry for performance records — and will state the committed timeframe here once it is in force rather than describe it as current practice now.
In the meantime, a district that requires a defined retention limit should raise it during contracting and we will commit to one in the Data Privacy Agreement. Any district or teacher can also request deletion at any time, which we action immediately.
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.
In numbers-only mode those retained scores are attached to a number rather than a child, so what persists is not personally identifiable on its own.
What's in place today.
Not a roadmap — a list of controls currently operating.
Numbers-only by default
Accounts are created with no name field. Name collection requires a logged written administrator authorization and is enforced server-side.
Only one application can record
Solfège Decoder contains no microphone code at all. Tapped rhythms are screen presses, replayed to the teacher through a piano that ships inside the app itself — no sound leaves the device. Only Solfège Singer can record, and only where audio is authorized for that account.
Data minimization
No student email addresses, contact details, dates of birth, or demographic data — and no names at all unless authorized.
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.
Enrollment-scoped student access
Students reach only their own assignments and submissions.
Tested deletion procedures
Audio removal is verified before records are deleted.
Approval-gated audio collection
Audio recording is off unless a school has approved it in writing and we have enabled it for that one account, with the approval recorded. Refused at three independent layers: the upload is never signed, the reference is stripped on submission, and the database rejects the row.
Students are told before they are recorded
Where an assignment will save a recording, the student sees a notice before they sing. It is shown only when recording is authorized and switched on, so its absence is meaningful.
Ownership-scoped audio storage
Stored recordings are readable only through the owning teacher's own classes, resolved on every read. No client can write to audio storage directly.
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 COPPA, FERPA, and New York Education Law §2-d. We do not claim certification under any of them — no such certification exists to hold, and a vendor claiming one should be treated with caution.
Each framework below governs personally identifiable student information. In the default configuration we hold no direct identifier — a number, a class, and scores do not identify a child without the key the school keeps itself. For COPPA specifically, that means a default deployment does not reach the Rule's parental-consent requirement.
To be precise rather than flattering: the student number is a persistent identifier used solely to operate the service, and the data remains an education record belonging to the school. We do not claim that numbers-only mode places us outside these frameworks. It narrows what is disclosed to us, which is a different and more defensible claim. The obligations below apply in full where a school has authorized names or recordings — and we meet them either way.
COPPA requires verifiable parental consent before collecting personal information from children under 13. Middle school choir programs routinely include students under 13, so the question matters — but the Rule's definition of personal information is a closed list: name, address, email, telephone number, Social Security number, geolocation, government-issued identifier, biometric identifier, a photo/video/audio file containing the child's image or voice, and persistent identifiers.
A numbers-only account with recordings off holds a class-assigned student number, class enrollment, a PIN, and assignment scores. Scores and enrollment are not on the list at all. The only item that requires analysis is the student number and PIN, which function as persistent identifiers.
The Rule permits collecting a persistent identifier without parental consent where it is used solely to provide support for the internal operations of the service and no other personal information is collected. That is precisely this configuration — so a default deployment does not reach COPPA's consent requirement, rather than satisfying it by another means.
The student number and PIN are collected only to: authenticate a student at sign-in; maintain their session; attribute a submitted assignment to the correct student and class; and return the resulting score to that student's own teacher.
They are never used to contact an individual, never used for behavioural advertising, and never used to amass a profile for any purpose beyond the school's own instructional record. There is no advertising, analytics, or marketing system with a path to this data, and no cross-site or cross-service tracking of any kind — the identifier exists only inside this service.
Once a school enables names or recordings, COPPA applies in full. In that case the school acts as the consenting party on behalf of parents, through its own enrollment, notice, and consent processes. That path rests on FTC staff guidance rather than the text of the Rule — in its January 2025 amendments the Commission declined to codify a school-consent provision, stating it would continue to enforce COPPA in the ed-tech context consistent with existing guidance. We describe it that way rather than implying a codified exception. It is also why both features are gated behind written administrator authorization instead of being on by default.
The amended Rule took effect June 23, 2025 with a compliance date of April 22, 2026. It expanded "personal information" to include biometric identifiers, requires separate consent before disclosing children's information to third parties for targeted advertising or AI training — which we do not do in any configuration — and requires a written data retention policy, set out below.
FERPA protects the privacy of student education records and gives parents rights to access and correct them. Choral Clarity operates as a vendor acting on behalf of the school — what FERPA calls a "school official" with a legitimate educational interest.
Student data is used only to provide the product. It is not sold, not used for advertising, and not shared with any third party beyond the infrastructure providers listed on this page.
In numbers-only mode the records we hold carry no direct identifier, and the school alone holds the key linking a number to a student. Teachers access only their own students' records; students access only their own work. Both are enforced at the database level, not only in the application interface.
§2-d applies to third-party contractors who receive student data from New York schools. It requires a Data Privacy Agreement, limits on how data is used, security practices aligned with industry standards, and breach notification within the timeframe each district's agreement requires, and no later than seven calendar days.
We are prepared to execute a Data Privacy Agreement and to work through your district's vendor approval process — including where numbers-only mode means little or no personally identifiable information is disclosed to us in the first place.
§2-d also requires us to be listed in your district's annual report of third-party contractors. We'll provide whatever information your privacy officer needs for that filing.
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 — rather than asking you to sign our standard terms and move on.
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. One other delivers the application itself. Fonts, the notation engine and the audio samples are served from inside the applications, not from anyone else.
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.
No student application contacts any third party. As of September 13, 2026 the typefaces, the notation engine and the piano samples the Decoder plays are all served from within the applications themselves. Opening Solfège Singer or Solfège Decoder makes no request to any domain other than ours and our database provider — no font service, no code CDN, no sample host. A district checking with developer tools will see exactly two origins, and both are listed above.
That test applies to the applications themselves, at solfege-singer.choralclarity.com and solfege-decoder.choralclarity.com. Choral Clarity's marketing website is hosted separately on a standard website platform and uses ordinary fonts and website analytics; it holds no student records, and its Log In link opens the applications above.
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?
- Accounts are locked to numbers only. A default deployment stores no student names — there is no name field — so no direct student identifier is ever disclosed to us. The number-to-student key stays with the school.
- A default deployment does not reach COPPA's parental-consent requirement. The student number is a persistent identifier used solely to support internal operations, which the Rule permits without parental consent where nothing else on its list is collected. The full analysis is here.
- The platform is four applications: two that students use — Solfège Singer and Solfège Decoder — plus a teacher dashboard and an admin console. While Solfège Singer is capable of recording audio, that function can only be activated if a district has authorized it in writing. The Decoder never uses the microphone.
- Students have no accounts, email addresses, or passwords. Nothing for your directory or SSO to provision.
- We store a student number, class membership, and assignment results. Display names and submitted audio each require separate written administrator authorization. Nothing else, in any configuration.
- One identification mode governs an entire account — numbers or names, never a mix, and never switchable per class by a teacher. Numbers mode is enforced by the database itself, which rejects any non-code identifier.
- Names and audio are permissions held per teacher account, not one platform-wide switch. Granting either for one school has no effect on any other account.
- Where something is not yet in place, we say so on this page rather than describing our intended design as current fact.
- Audio is deleted automatically at the end of each school year, and on request at any time.
- Deleting a student, class, assignment, or account removes stored audio before removing records, and verifies removal first — if any file survives, no rows are deleted and the request can be retried.
- 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
- ✓ Confirm in writing that your accounts remain in numbers-only mode
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 reviewThe terms teachers agree to on account creation.
When a teacher creates a Choral Clarity account, they confirm that their school agrees to the following terms. This agreement establishes the school as the responsible party for parental consent under COPPA, and defines how student data is handled on the school's behalf.
The School is deploying Choral Clarity as an educational tool for use with students in a school context. Student data collected through the platform is used solely to provide the aural training and music literacy features of the product.
The Children's Online Privacy Protection Act (COPPA) requires verifiable parental consent before collecting personal information from children under 13. Under the COPPA Rule, a school may provide consent on behalf of parents for the collection of student information by an educational technology provider, where that collection is for the school's educational purpose.
By creating a Choral Clarity account, the teacher confirms on behalf of their school that:
- ✓ The School has the authority to consent on behalf of parents for this educational use
- ✓ The School has provided, or will provide, appropriate notice to parents consistent with its own policies and applicable law
- ✓ The School takes responsibility for parental notification and consent as required by COPPA for students under 13
Choral Clarity relies on this authority and does not independently seek or verify parental consent for individual students.
Every new account is created in numbers-only mode. In this mode the platform assigns each student a code within their class and provides no field for a student name; no student name is collected, transmitted, or stored. The key matching a code to an individual student is retained by the School and is not provided to Choral Clarity.
If the School wishes to identify students by name instead, an authorized representative of the School must confirm in writing that name-based rostering is permitted and that any required school, district, or parental approvals and consents have been obtained. Choral Clarity then enables the setting for that account and records the approval and its date. A teacher cannot enable it themselves.
- ✓ One identification mode applies to the entire account — the two modes cannot be combined
- ✓ A teacher cannot enable names without administrator authorization; the restriction is enforced server-side
- ✓ Name authorization and audio authorization are separate and independent decisions
Audio recording is off by default and is not enabled by account creation. If the School wishes to enable audio recording, an authorized representative of the School must confirm in writing that audio recording is permitted and that any required approvals and consents have been obtained. Choral Clarity then enables it for that account and records the approval and its date. Name authorization and audio authorization are separate decisions; neither implies the other.
The platform may collect and store: a student number assigned within the class, class enrollment, and assignment scores and results. It may additionally store a student display name only if name-based rostering has been separately authorized, and audio recordings of submitted work only if audio has been separately enabled. Choral Clarity does not collect student email addresses, dates of birth, home addresses, phone numbers, or any demographic, health, or disciplinary information.
Student data is used only to provide the Choral Clarity service. It is not sold, not used for advertising, and not shared with any party other than the infrastructure providers described on this page.
Student data belongs to the School and its students. Choral Clarity holds it on the School's behalf. The School may request deletion of any student data at any time by having the teacher remove the student from the system, or by contacting Choral Clarity directly.
- ✓ Student records are deleted when a teacher removes the student or the account is closed
- ✓ Audio recordings, if enabled, are permanently deleted every July 1
- ✓ Deletion on request is available at any time
In the event of a security incident involving student data, Choral Clarity will notify affected schools within the timeframe required by that school's or district's agreement — within 24 hours where required, and in no case later than 72 hours — and sooner where the facts are known. Where no agreement specifies a shorter period, notification is within seven calendar days, consistent with New York Education Law §2-d.
By creating a Choral Clarity teacher account or using the platform with students, the teacher confirms they are authorized to enter into this agreement on behalf of their school or district, and that the school agrees to the terms above.
This document does not constitute legal advice. Schools with specific compliance questions should consult their own counsel. Choral Clarity reserves the right to update this agreement — schools will be notified of material changes. Version 1.2 — September 2026.
Get in touch.
For questions about student data privacy, security practices, or district review processes:
Choral Clarity
15 Bar Beach Road
Port Washington, NY 11050
Parents who wish to request deletion of their child's data should contact their child's teacher or school directly. Teachers can remove a student from the system at any time, which permanently deletes their student number or display name, their class enrollment, and their scores. For schools that have enabled audio recording, any submitted recordings are deleted at the same time.
If you are unable to reach your school, contact us at [email protected] and we will assist.
Last updated: October 10, 2026